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

On 3/29/13 1:15 PM, Tab Atkins Jr. wrote:
> 1. Initially mark every element as not being laid out.
> 2. All instances of the :max-width() pseudoclass evaluate as false initially.
> 3. As you lay out the page, mark elements as being laid out.  Skip
> over the contents of viewport elements.
> 4. When the page has been laid out, check all the :max-width()
> selectors.  If any of them now depend on elements that have been
> resolved, *and* their subjects are elements that have *not* resolved,
> check their truth values and apply the contained rules accordingly.
 > 5. Return to step 3, resolving layout for the children of viewport
 > elements that were skipped over before.  Stop when every element in
 > the page has been laid out.

Ok, so let's say I have two elements A and B.

Each one has a viewport inside, call these V1 and V2.  There is another 
viewport V3 inside V1.

In your algorithm, is V1 "resolved" first or is V2?  Does it matter? 
What if a rule depends on the min-width of V1 and has a subject inside 
V2?  What if it depends on the min-width of V3 and has a subject inside V2?

> WLOG, let's assume that the two viewports are siblings, and don't have
> any viewport ancestors, just to keep it in the simplest case.

Ah, but the nesting bits do matter....

> Then, check any selectors that contain a :max-width() selector.  If
> the :max-width() applies to an element that's already been laid out,
> and the subject of the selector is an element that hasn't been laid
> out, you can now resolve that selector appropriately.  Otherwise, the
> selectors are false and match nothing.

OK.  So this definitely requires that in my example above I have to do 
layout on V2 before I do it on V3, yes?

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.

> I'm not sure why it's important to have them declared in markup, given
> that the only real effect is that they no longer look at their
> contents for sizing information.  That seems completely appropriate
> for a CSS property to control.

You did see 
<http://lists.w3.org/Archives/Public/www-style/2013Mar/0442.html>?

>> I'm a
>> little more cautious about selecting on the size of the viewports if it can
>> do anything more than what viewport-size media queries for subframes can do
>> right now.
>
> If I'm understanding you correctly, that's equivalent to only allowing
> size queries on ancestors (that are on the other side of a viewport
> barrier).

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.

-Boris

Received on Friday, 29 March 2013 17:40:34 UTC