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

On Fri, Mar 29, 2013 at 10:01 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/29/13 12:56 PM, Tab Atkins Jr. wrote:
>> Unless I'm thinking incorrectly, it doesn't preclude parallel layout,
>> as long as the two viewport elements are at the same level of
>> "nesting".  Any selectors relying on viewport sizes can only rely on
>> already-resolved ones, which is a set shared between the two, so they
>> don't need to interact directly.
>
> So a min-width selector for one of the viewports can't affect the size of an
> element in the other one?  If so, that's non-obvious from your
> description....

It should be inherent in the pseudo-algo I gave:

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.

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.

You first lay out the entire rest of the page, skipping the contents
of the two viewport elements.  (The viewport elements themselves can
be laid out, because their size is not determined by their contents at
all - it's either explicitly given, based on their surroundings, or
defaults to replaced-element sizing.)

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.

So, if the first viewport element's content have a selector which
checks the max-width of an element in the contents of the second
viewport element (perhaps using a reference combinator to jump
subtrees), then it simply won't work - the :max-width() selector will
be depending on an element that hasn't yet been laid out.  Thus, you
can layout the two independently, since they can't depend on each
other's layout.

However, if they both contain viewport element children, then when
you're doing your third pass to lay out *their* contents, they can use
selectors jumping subtrees to the other parent viewport element.

So, if that's the thing you were referring to when you said they
couldn't be laid out in parallel, you're right.  We could, of course,
restrict it to only allow :max-width() based on ancestors of the
subject element, which would make it fully parallel in this sense.
This could be done either with an explicit at-rule-based syntax, like
Elliot has given, or by just implying it as a condition of the
selector.  Additionally, if you do it this way, you don't have to do
separate layout passes - you can go ahead and layout in one pass like
normal, and optionally lay out the contents of viewport elements
lazily or in parallel if you wish.

> That's the problem I'm having, yes.  I'm all in favor of something like
> viewports, I think (as long as they're declared in markup, not CSS);

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.

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

~TJ

Received on Friday, 29 March 2013 17:16:44 UTC