- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 16 Sep 2014 13:21:09 -0700
- To: Peter Salas <psalas@microsoft.com>
- Cc: François REMY <francois.remy.dev@outlook.com>, CSS WG <www-style@w3.org>
On Mon, Aug 18, 2014 at 11:14 AM, Peter Salas <psalas@microsoft.com> wrote: > François REMY wrote: >> >> - If the track has a ‘max-content’ max track sizing function, set its >> growth limit to the maximum of the items’ max-content contributions. >> This is undefined, there is no such item (so I leave limit=infinity) >> -- I guess the difference between IE and me is here, it probably >> sets the limit to 0 at this step, why? > > Not quite; this is done after accommodating spanning items. In the earlier version of the algorithm, this was the purpose of Step 4 in ResolveContentBasedTrackSizingFunctions[1]. I don't see a place in the latest editor's draft algorithm where this happens though. Oh, *that's* what that algo step was for! We couldn't figure out what it possibly accomplished, as it looked like everything was fixed by the previous steps, but we didn't consider the case of an empty track. Fixed. >> If yes, then we set the growth limit to 0 instead of keeping >> it equal to the infinity when there's no span-of-one item in a column. >> Therefore, how can we possibly get a limit of infinity in the following >> steps, which seem to take care of this possibility in multiple places? > > By "the following steps" were you referring to the "accommodate spanning items" step? If not, I don't think there should be any infinite values after resolving the content-based keywords; I think this is confirmed by the note at the bottom of the "Resolve Content-Based Track Sizing Functions" in the editor's draft[2]. Right. (This is precisely why we put in "intention" notes for complex algorithms, so that if we get something wrong, it's easier to see that it *is* wrong, not just a weird-but-expected consequence of the algorithm.) ~TJ
Received on Tuesday, 16 September 2014 20:21:56 UTC