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

On Fri, Mar 22, 2013 at 7:19 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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.
>
>
That requires shared state because you're assuming we do something in terms
of levels which isn't really how layout works. If two blocks are positioned
and not nested we'll lay them out entirely in parallel.

I don't want the spec requiring us to share style state between the layout
threads.

- E