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

On Fri, Mar 22, 2013 at 5:45 AM, Boris Zbarsky <bzbarsky@mit.edu> 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?

Correct, some rules can't be determined to apply or not until you do
enough layout to resolve their :max-width()/etc pseudoclasses.

> This seems like it might be a significant deoptimization...

I wonder how detectable this is, such that the browser can still take
the faster path when possible.  Due to inheritance, I guess that
anything that's a child of something that one of these rules applies
to is potentially tainted.  One could potentially resolve the
selectors while ignoring the :max-width() pseudos, and taint the tree
accordingly.  Or one could just say that anything below a viewport
element is automatically in the slow path if there are any
viewport-element-relative pseudoclasses used in the document. That
kinda sucks, though - part of the reasoning behind viewport elements
is to enhance performance.

> (On the other hand, maybe UAs can just return incorrect answers for this
> stuff?  I seem to recall that's what some UAs do already with <iframe>...)

I assume this is because viewport MQs in the iframe depend on styling
in the outer document?  I'd love to hear more details about this.  It
would be kinda weird, I think, but possible.  I wonder if we could add
an options object to getComputedStyle that would let us opt into the
slower-but-more-truthful answer...

~TJ

Received on Friday, 22 March 2013 16:16:27 UTC