- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 29 Mar 2013 09:56:57 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Elliott Sprehn <esprehn@gmail.com>, François REMY <francois.remy.dev@outlook.com>, "www-style@w3.org" <www-style@w3.org>
On Thu, Mar 28, 2013 at 7:45 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 3/23/13 5:36 PM, Tab Atkins Jr. wrote: >> On Sat, Mar 23, 2013 at 7:17 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >>> On 3/23/13 4:18 AM, Tab Atkins Jr. wrote: >>>> I thought I'd explained the proposal sufficiently in my earlier email >>>> that gave the steps as a numbered list. ^_^ >>> >>> This is http://lists.w3.org/Archives/Public/www-style/2013Mar/0422.html ? >> >> Yes. > > That algorithm, as written, sure seems to preclude parallel layout of two > viewport elements, in many cases, unless I'm just completely missing > something. Unless I'm thinking incorrectly, it doesn't preclude parallel layout, as long as the two viewport elements are at the same level of "nesting". Any selectors relying on viewport sizes can only rely on already-resolved ones, which is a set shared between the two, so they don't need to interact directly. > (It's also not entirely clear to me how well it plays with interruptible > layout that does not always run to completion and various other things, > honestly.) Right, I'm less and less sure that this works, unfortunately. :/ Viewport elements themselves can give nice benefits, but this seems like it might erase a lot of other speed benefits we'd like to have. ~TJ
Received on Friday, 29 March 2013 16:57:46 UTC