Re: The :min-width/:max-width pseudo-classes

On 3/30/13 8:49 AM, François REMY wrote:
> already requires that you compute the layout of the parent div before you can compute the layout of the inner one, right?

Yes.

> In my mental model, I don't see how this is so different in the case of :min-width.

:min-width requires you to compute the layout of the parent div before 
you can compute the set of rules matching the child.  Note that rule 
matching currently happens in a separate entire pass before layout right 
now in many engines, and is an embarrassingly parallel problem which any 
sane engine would like to fully parallelize going forward.  But that 
can't happen if it starts being gated on the much more serial layout 
behavior.

> While I'm asking layout questions, can I also ask how browsers are able to get min-content and percentages working properly inside each other?

"Badly"?  ;)

What Gecko does is that non-replaced elements with a specified width 
that depends on their parent are treated as having an auto width for 
purposes of the parent's min-width calculation.  Or perhaps even more 
precisely, treated as if their specified width were "min-content".

> Does it imply two successive relayouts

Just to be clear, at least in Gecko (and iirc WebKit) there is only one 
layout pass.  Intrinsic width computation is done separately from 
layout, and in Gecko's case cached across layouts.

So for the specific case of Gecko the full "layout pipeline" looks 
conceptually somewhat like this:

1)  Do selector matching on all elements in the tree.
2)  Do style computation on all elements in the tree.
3)  Do intrinsic width computations on all elements in the tree.
4)  Do layout.

In practice, of course, in Gecko's current implementation we can do 
steps 1 and 2 on subtrees, right now steps 1 and 2 are somewhat 
intertwined, step 2 is actually done very lazily, intrinsic width 
computations are only done as needed.

But going forward, I should point out that as things stand right this 
second in terms of specifications step 1 is conceptually embarrassingly 
parallel (you can do it on all nodes in the tree in parallel at once), 
step 2 is tree-parallel (you can do it on subtrees in parallel, but have 
to do parents before kids) and step 3 is also tree-parallel (you can do 
it on subtrees in parallel, but have to do kids before parents).  How 
parallel layout itself can be given current CSS specs is an interesting 
research problem, which has several research groups working on it.  ;)

> Does it means I can get <iframe seamless>-like 2^n relayouts where n is the number of nested min-content elements?

I can assure you that browsers try very hard to avoid behavior that's 
exponential in tree depth.  Read that as "probably a formal objection if 
that gets introduced as a specification requirement." ;) Gecko in fact 
used to have such behavior for shrink-wrapping situations due precisely 
to having to relayout, which is why we moved to our current model in 
which both the intrinsic widths and the layout can be done in separate 
passes, each of which is linear in tree depth.

-Boris

Received on Sunday, 31 March 2013 03:59:15 UTC