- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 22 Mar 2013 16:19:24 -0700
- 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. ~TJ
Received on Friday, 22 March 2013 23:20:11 UTC