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

On Thu, Mar 21, 2013 at 6:34 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Thu, Mar 21, 2013 at 8:35 PM, François REMY
> <francois.remy.dev@outlook.com> wrote:
>> > Oh! So your idea is that a :max-width() pseudo would, regardless of
>> > where in the selector it appears, match based on the nearest viewport
>> > element of the selector's subject?
>>
>> Not exactly. I'm just saying that if the layout of the element hasn't been
>> calculated in a previous pass, the pseudo-class doesn't match. And the
>> condition to which the layout of the target element has been computed in a
>> previous pass is that it should be the nearest parent viewport of the
>> element to be matched, or an ancestor.
>>
>> So :min-width() consider the width of the element it's applied on, but
>> only if the width of the element is known. If it's not, the pseudo-class do
>> not match.
>
> I'm not sure I follow what you're talking about.

>From what I can tell, François' idea is this:

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.

This appears to be similar in complexity/difficulty to your idea of
scoping, but it's slightly more flexible, allowing the reference
combinator and such as long as the selector is built appropriately.
It's also easy to teach the simple cases - the :max-width() must apply
to an ancestor viewport element, or something above the viewport
element.

Pretty sure it's guaranteed not to be cyclic, due to the way step 4
works - you get a DAG of dependencies from it. Your idea forces a
dependency tree instead, and requires learning how to use a new
at-rule rather than a new pseudoclass.

> This would probably be okay. I think there's a high implementation cost for
> this kind of thing, at least in WebKit, since it breaks from the two step
> model and fancy features like :first-letter/regions/etc. need to be moved to
> a separate phase since their state depends on the style of the inside of the
> viewports being known. It certainly could be done given enough time and
> someone very motivated...
>
> I'd love to hear thoughts from other implementors. :)

Me too!

~TJ

Received on Friday, 22 March 2013 03:34:57 UTC