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

> 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.

The question is: why would you want an up-to-date style? I may obviously not see all the cases myself, but my wild guess is that you only want that to prepare things like the composition layers or to create a preliminary box tree. If you consider the local viewport independent of the rest of the page, I guess that you end up with two layout trees for which you can start wondering about those things when the parent layout tree has already been computed only, since neither the composition layers or the box trees need to cross the local viewport boundaries.

As I said, it doesn't matter if in some cases the :min-width matching isn't perfectly consistent, I'm almost sure that, right now, if you use <iframe>s, @keyframes and @media queries together you can end up in situations where what is shown on the screen isn't quite exact but is exact enough for you not to see anything of the wrongness (ie: mismatch-time <= time-between-frames).

Received on Friday, 22 March 2013 17:38:20 UTC