W3C home > Mailing lists > Public > www-style@w3.org > March 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 22 Mar 2013 10:25:29 -0700
Message-ID: <CAAWBYDDETgLUv54C6BcE7GwviqSE5QoOB81gSxXkKZzQMRthAg@mail.gmail.com>
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.

Received on Friday, 22 March 2013 17:26:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:27 UTC