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

On Wed, Mar 20, 2013 at 2:41 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
> In the light of a recent blog post [1] of Daniel Buchner, contributor of the Web Components specification, I would like to resurrect a thread I think is really important: element-based media queries.
>
>
> CONTEXT
> ========
>
> Web components provide DOM Tree isolation, but no Layout Tree isolation: there’s no strong way to guarantee that a layout change inside a web component will not affect the layout outside the web component. This means that the performance of rendering operations when the DOM Tree is modified can be disappointing [3].
>
> But there’s more: since the layout of most elements may depend on the layout of their children, it’s impossible to support in an efficient way local media queries (applying a different layout on the descendants of an element depending on its size).
>
> Web developers already have found solutions to emulate those local media queries, but none of them are efficient enough to be used in performance-critical contexts, even if I’m sure they will [1][2].
>
> Browsers already do support layout-based events (whether it is the ‘onresize’ event in Internet Explorer or the ‘overflow’ and ‘underflow’ events in Firefox and Webkit) and will continue toward this path with the inclusion of the 'regionlayoutupdate' event, but using those events requires ugly hacks and can force the browser to perform multiple successive relayouts, and this issue only gets worse as the number of web components increases.
>
>
> PROPOSAL
> =========
>
> In the context of local viewports (sub-trees of the layout tree whose layout can be computed independently of the primary layout tree) it would be possible to define local media queries for elements *outside* the currently layouted sub-tree, whose layout have already been computed as part of a parent layout tree.
>
> Here's an hypothetical sample using this proposal to create a phone-like layout:
>
>   #selector .list { display-outside: viewport; display-inside: grid; … }
>   #selector .list:max-width(480px) { background: white; color: black; … }
>   #selector .list:max-width(480px) > .item { … }
>
> Main take-overs:
>
> • The local viewport media queries pseudo-class may only match the nearest ancestor local viewport and its ancestors (i.e. elements whose size will not be affected by the current layout sub-tree).
>
> • The selectors whose last section contains a local media query pseudo-class cannot affect the outside layout of the element (display-outside, width, height, position…), even if they are nested in a ‘:any-of(…)’ or a ‘:not(…)’ pseudo-class.
>
> • The selectors containing a local media query pseudo-class anywhere else (ie: parent elements) have no specific additional restriction (the first rule still apply).
>
>
> I'm thinking about adding this proposal in my Local Viewport proposal draft in the near future, but I would love to get further feedback on the feasibility and the timeframe in which we can hope to get the feature implemented. I'm pretty sure that, depending on that, the importance of optimizing the 'on layout updated' event loop will prove more or less important.
>
> In the mean time, I propose to standardize the ‘resize’ event of Internet Explorer (making it asynchronous and working in a similar fashion to the regionlayoutupdate event). Failing to standardize this event will only result in a dummy elements used as event trigger, something that is probably even worse from the performance point of view.
>
> Any comment on this?

"viewport" isn't a 'display-outside' value, it's something separate.
It just controls whether its intrinsic size is based on its contents
or not; you still need to know whether it's block-level or
inline-level.

Otherwise, yeah, I think this probably works, where the pseudoclass
measures the width of the nearest ancestor viewport-like element, or
the viewport itself if there is no such thing.

Related, you'll want a similar query for whether the element is "tall"
or "wide" (whether the height is larger than the width or not).  This
is requested in another thread from this morning, regarding range
inputs.

~TJ

Received on Wednesday, 20 March 2013 22:43:58 UTC