W3C home > Mailing lists > Public > www-style@w3.org > March 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 21 Mar 2013 13:24:07 -0700
Message-ID: <CAAWBYDBiqOPuNx2+SD4CH=BTiJX4zzpjhZv=R+cEi=1-D1Lhmw@mail.gmail.com>
To: Elliott Sprehn <esprehn@gmail.com>
Cc: Fran├žois REMY <francois.remy.dev@outlook.com>, "www-style@w3.org" <www-style@w3.org>
On Thu, Mar 21, 2013 at 1:07 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Thu, Mar 21, 2013 at 3:24 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> The nice quality of it, though, is that by the very nature of the
>> "viewport element", you can defer the layout of the children until
>> you've gotten all the information necessary to evaluate those pseudos.
>>  I suspect this might map to something like preventing the children
>> from generating renderers until the parent is laid out, sorta like if
>> the children were all display:none and then switch to display:non-none
>> at the end of the first layout pass.
> As described, it doesn't work that way:
> #selector .list:max-width(480px) + div { display: inline; }
> We need to do layout on the .list before we can figure out the correct style
> for it's siblings. This generalizes to all kinds of madness where you can't
> create the renderers for an element because another selector might match
> later during layout requiring you to rebuild the render tree.
> Maybe if this was scoped downwards:
> @viewport #selector .list (max-width: 480px) {
>   div { .. }
> }

It *is* scoped downwards.  You missed the part where the pseudoclass
refers to the width of the nearest ancestor "viewport element".  It
doesn't work on arbitrary elements.

(I just realized, though, that this won't help us once we get the
reference combinator. Hmm.)

Received on Thursday, 21 March 2013 20:24:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:27 UTC