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

On 3/29/13 2:07 PM, Tab Atkins Jr. wrote:
> On Fri, Mar 29, 2013 at 10:40 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> OK.  So this definitely requires that in my example above I have to do
>> layout on V2 before I do it on V3, yes?
>
> Yes.

That's not great, really...

>> This also requires that all incremental layout always start at the root of
>> the tree and touch everything in it, as far as I can tell, so that these
>> global ordering invariants on when things are marked as "resolved" are
>> maintained.  Which, honestly, half-defeats the purpose of viewports; the
>> idea is that you can do layout inside a viewport WITHOUT having to worry
>> about touching anything outside it.
>
> Yes.

Again, not great.

> Yes, that's a problem if you want to have selectors based on sizing.
> It's in fact an *inherent* property of having selectors based on
> sizing.  The fact that viewports are involved is irrelevant, except
> that it happens to be a necessary property for any sane definition of
> selectors based on sizing.

What's inherent if you have sizing-based selectors is that you have to 
break apart work on selector matching and layout such that you do sizing 
and layout of the viewport before you do selector matching inside the 
viewport.  That much we agree on, I hope?

However if whether something is a viewport is a matter of computed 
style, that means that you _also_ have to compute style on an element 
before you can even decide whether to do selector matching inside it. 
That's not a problem that a viewport declared in markup suffers from: 
you know without having done any style computation on the element that 
it's a viewport and that you just shouldn't do any selector matching on 
anything inside it.

Put another way, imagine that you're implementing a UA that wants to do 
selector-matching in parallel on elements (this is not hypothetical; 
Servo and Gecko both want to do this).  It seems like having viewport be 
a style property very much constrains the ordering of the selector 
matching, and requires that it be interspersed with style computation. 
But style computation may well not parallelize nearly as well, which 
requires that you then serialize your selector matching on critical 
sections that do style computation....

>> It's equivalent to only allowing size queries on the immediate ancestor
>> viewport.  That _may_ be equivalent to the other, but I'd have to think a
>> bit to figure out whether it is.
>
> You can chain sizing selection with selectors/MQs at each level, so
> transitivity gives you the full result.

Not quite.  Say a document in window A contains a subframe which holds 
window B, which itself contains a subframe which holds window C.

Obviously a change in the width of A can trigger MQs that change the 
width of B which in turn can trigger MQs that change the width of C.

However, if the width of B doesn't change you do not in fact have to do 
anything at all with C.

Whereas if things in C could directly depend on the width of A, when the 
width of A changes you have to go groveling through C for things that 
might have changed.

Now maybe in practice this doesn't matter, but a priori the ability to 
make C directly depend on the width of A requires more effort to avoid 
doing unnecessary work when the width of A changes but the width of B 
does not.

-Boris

Received on Friday, 29 March 2013 18:34:15 UTC