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

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

Doesn't matter.

> What if
> a rule depends on the min-width of V1 and has a subject inside V2?

That's fine, since V1 is a viewport element itself, and has its size
resolved *before* the contents are touched.

> What if
> it depends on the min-width of V3 and has a subject inside V2?

Won't work - while you're resolving V2 styles, V3 is still not laid
out, and so the selector will fail.  By the time V3 is laid out, the
subject is already laid out, and so the selector will fail.


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

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.

Yes.

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

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.

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

You can chain sizing selection with selectors/MQs at each level, so
transitivity gives you the full result.

~TJ

Received on Friday, 29 March 2013 18:08:11 UTC