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

On Fri, Mar 22, 2013 at 1:41 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 3/22/13 1:30 PM, Tab Atkins Jr. wrote:
>
>> It would be a property that switches it into "viewport mode", where
>> its intrinsic size is no longer dependent on its children.  (No cyclic
>> dependencies, because the viewport-element-relative pseudos can't
>> apply to the subject of the selector.)
>>
>
> That's still really bad.
>
> In particular, it means that you have to serialize style computation on a
> parent and CSS selector matching on its kids, because you can't do the
> latter until you've done the former and determined whether the parent has a
> magic property.
>
> And that means that any hope of parallelizing selector matching across the
> tree is pretty much dead....
>
>
I was thinking about this today and came to the same conclusion. This
prevents doing block layout in parallel as well which is really bad.

ex. Given two positioned viewports we now we need to force document order
layout computation on them.

Currently we can do block layout in parallel in many cases, but since you
want to allow .viewport1 to have rules that later affect .viewport2 even
though it's not a descendant we couldn't do that. We couldn't even
pre-compute the text sizes or min/max logical widths since doing layout on
one of the blocks could change the font size of a later one.

The assertion that this is somehow faster because the current script
approach causes the "browser to perform multiple successive relayouts" ends
up falling down as well since we're doing selector matching repeatedly as
we do layout.

- E