- From: François REMY <francois.remy.dev@outlook.com>
- Date: Fri, 22 Mar 2013 17:46:02 +0100
- To: Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
> 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? Do not forget that a local viewport will be clipped to its margin or border box and can be considered as a texture source from the parent layout manager. When you have an IFRAME now, I don't think you have to actually compute the layout of the parent document to know how to pre-compute the IFRAME layout, even if MQ could affect the layout types quite a lot. In my mind, the content of a local viewport is quite independent of the content of the normal page and it would even be possible for the layouts not to be recomputed at the same pace (and have one viewport element missing some keyframes while the rest of the document is updated at 60fps). This is one of the benefits of local viewports, I think. At the same time, I understand that this utopic vision may be a more long-term goal and that first implementations of local viewports will likely be more pragmatic and face the kind of problems you speak about. However, I wouldn't be afraid by specific situations where the :min-width(...) pseudo-class matching may end up lagging one keyframe behind the time they should be triggered (ie: using last-time results to compute if the :min-width(...) pseudo-class apply or not). At the rate of one keyframe every 60th of second, almost nobody would care.
Received on Friday, 22 March 2013 16:46:32 UTC