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: Fri, 22 Mar 2013 16:19:24 -0700
Message-ID: <CAAWBYDD68VDOfF_W+pLpsthbTp0UCghkPtM-E5eakShFRx2Bog@mail.gmail.com>
To: Elliott Sprehn <esprehn@gmail.com>
Cc: Fran├žois REMY <francois.remy.dev@outlook.com>, Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
On Fri, Mar 22, 2013 at 4:09 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Fri, Mar 22, 2013 at 6:52 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Fri, Mar 22, 2013 at 12:39 PM, Elliott Sprehn <esprehn@gmail.com>
>> wrote:
>> > I'd oppose this feature unless we could figure out how to make it scoped
>> > such that you can layout all non-nested viewports in parallel (just like
>> > iframes).
>> This should be the case in the current proposal - you can lay out all
>> the elements at a given nesting level in parallel.
> There are no nesting levels, it doesn't work that way. If you have two
> absolutely positioned viewports and each has 10 levels of nested viewports
> inside you need to be able to have two threads that lay them both out in
> parallel without ever stopping or talking to each other. No shared state at
> all.
> My proposal only has style resolution going downward, but you said it's not
> as flexible, so I'll need more explanation of what's different about yours
> since I'm not quite following.

Francois' proposal allows selectors that use, say, the reference
combinator to still work appropriately.  This means that you could
potentially have an element in viewport A depend on the size of
sibling viewport B.  No cycles, but it doesn't give you *fully*
parallel layout.  Like I said, it still lets you resolve all the
layouts of a given nesting level in parallel.

Received on Friday, 22 March 2013 23:20:11 UTC

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