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

On Fri, Mar 29, 2013 at 11:19 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

Sure.

>> 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....

Ah, sure, I see the distinction you're making.  That's still only
relevant in the face of sizing selectors, though, which is what I was
trying to say.

>>> 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.

Okay, I can see how it would be easier to optimize the chained version
over the transitively-closed version.

~TJ

Received on Friday, 29 March 2013 19:34:54 UTC