- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 22 Mar 2013 10:25:29 -0700
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
On Fri, Mar 22, 2013 at 9:46 AM, François REMY <francois.remy.dev@outlook.com> wrote: >> It's very common for parts of the browser of the web platform to ask for >> updated style information but not updated layout information. This >> happens a lot for things that want up-to-date render object _types_ but >> not their layout, as well as for getComputedStyle in various cases. >> >> But with this proposal, that sort of thing becomes impossible to some >> extent: asking for up-to-date style information either always requires >> layout or requires explicitly specifying which set of elements you need >> it for, so that the UA can determine that they're inside one of these >> viewport things and perform layout accordingly, right? > > This is a really interesting insight, but I guess the problem only exist because you stick to the point of view that only one layout manager take care of the whole page. If you divide the work layout manager by layout manager, and make sure the layout manager of local viewport subtrees are never considered until their parent layout tree has been resolved, you don't have this problem, right? No, the problem is that a layout manager needs to be invoked at all to resolve selectors. If an internal API wants up-to-date styles but doesn't actually care about layout, right now it can do that by just resolving all the selectors and running the cascade. With the introduction of viewport-element-relative pseudoclasses, it needs to resolve layout, at least partially. ~TJ
Received on Friday, 22 March 2013 17:26:16 UTC