Element Queries


#1

Element queries

We need media queries at the component level in order to target specific element sizes in CSS. Element queries allow us respond to changes in an element’s size even when the viewport size does not change.

Media queries are not sufficient, and they become frighteningly verbose when we have to style elements that may exist in a range of wide and narrow containers.

Many of us have pitched our own solutions to query the media features of an element, including new CSS pseudo classes, classless queries, or a new display type that scopes media queries to an element.

Pseudo class solution

.component .child {
	padding: 16px;
}

.component:query(min-width: 960px) > .child {
	padding: 32px;
}

In the above solution, a pseudo class like :query is used to query multiple features. This solution conforms with existing CSS features like :not and :contains.

Pseudo class-less solution

.component .child {
	padding: 16px;
}

.component (min-width: 960px) > .child {
	padding: 32px;
}

In the above solution, parentheses assume the presence of a media query. This solution is a unique pattern, and requires the least additional markup.

Multiple pseudo classes solution

.component .child {
	padding: 16px;
}

.component:min-width(960px) > .child {
	padding: 32px;
}

In the above solution, multiple pseudo classes like min-width and max-width are used to query individual features. Several other pseudo classes are mapped to supported features, like max-aspect-ratio, min-device-width and max-resolution.

Viewport display solution

.component-frame {
	display: viewport;
}

.component .child {
	padding: 16px;
}

@media (min-width: 960px) {
	.component > .child {
		padding: 32px;
	}
}
<viewport>

In the above solution, elements may assume viewport-like status, much like an <iframe> element, only without being an actual embedded frame. Additionally, a new element might be added that semantically represent uniquely framed sections of content.


I wish I could have cited my sources of information, but this service limits new users.

Anyway, I hope this provokes some thought and consideration. We need element queries because the responsive web is not limited to the width and height of a screen or window.


A pseudo-class for when an element is stickily (spec term) positioned
CSS Conditions with Variables
[Proposal] media(), like var() but for responsive values
#2

And of course, the canonical rebuttal for why element queries aren’t happening.


#3

You’ll note that Tab doesn’t close the door entirely though. If there were ways for elements to be declared as viewports in the markup, there could be a way forward.

There are several viewport elements already (SVG alone has a bunch). It isn’t clear to me that being a viewport is strictly a styling affair, it typically maps to a notion of rooting a subcomponent. With that in mind, I could live with a “viewport” boolean attribute (or anything like that). It doesn’t hurt that it exposes a primitive that iframes have, too (making it possible to build one’s own iframes that only do the necessary subset would be pretty sweet)


#4

A relevant discussion with Tab


#5

A bunch of us RICG folks have been interested in this topic for a while now. A couple of us are thinking about putting together a “use cases” document (a la usecases.responsiveimages.org), with the expectation that nobody is married to any kind of syntax and this may not prove completely feasible in the end anyway. Couldn’t hurt to get a clear and documented sense of the problems being solved, though, I figure.

Anyone hugely opposed?


#6

A use case document sounds like a good way to go. I think many of the use cases are quite obvious but perhaps by working through them we can find some that we had not previously considered or, better yet, a way to further constrain the problem to make it easier to solve.

Also, Tab did write a second blog post that is slightly more positive than the original.


#7

Since I’ve been involved in the discussion about EMQ in the CSSWG, I thought it may be worth I share my opinion here. From all the options which have been discussed to date, I believe the <viewport> element is still the only viable one which could be added to HTML/CSS and solve the Element Queries problem, at least rather easily (display: viewport is a technically similar solution, but is harder for browsers to implement because the creation of new layout contexts happens after the style resolution phase, which could mean some work may have to be restarted again).

I believe the question at this time is not anymore whether we can solve the :min-width use-cases or whether a solution can be implemented in browsers but more whether browser vendors are interested in solving this problem, and how much.

For reference, here is the blog post in which I discuss the EMQ problem from a technical perspective: http://fremycompany.com/BG/2013/Element-Media-Queries-min-width-883/ (it also features a bunch of pointers to relevant CSSWG threads)


#8

Just a quick question: does it have to be an element, or could a viewport boolean attribute suffice?

Either way, I’m happy to bang out a spec on this; want to get started?


#9

An attribute would be okay, the point was that it (the fact a new CSS context had to be created) had to be known before the CSS Matching happened, in order to make things simpler.


#10

I’m fine with starting a spec on this (in fact I already did at some point), but I think we may want to wait until this spec reaches some level of maturity. It would be easier to rely on the concepts defined there to get started.

A good thing to do would be to ping the Tab or the CSSWG about that spec, to be sure it continues to be proactively discussed. What do you think?

(To contextualize things, the CSS Containment spec resulted from the Viewport discussion; it is roughly based on the subset of a CSS Viewport that could be expressed using CSS only)


#11

The now-somewhat-inappropriately-named Responsive Images Community Group has been thinking this over a bit lately (Tab included). There are a lot of moving parts to keep an eye on before anyone barges ahead with any specific syntax or… plans, or anything, but we did get started on a use cases doc—that way we have a central thing to point to when we’re discussing the problem to be solved. Help on this is welcomed, for sure.

Repo: https://github.com/ResponsiveImagesCG/eq-usecases
Doc: http://responsiveimagescg.github.io/eq-usecases/


#12

Sorry to dredge this back up; however has there been any further progress with this?

I know it has been fraught with issues and reasons why it is very hard. However I do think however this comes closer to making completely modular web components. Such that a template author can nest as many grid/cell elements as they see fit.


#13

This has now moved to a talk about “container queries”:

Syntax discussion here:

Thanks @Wilto for keeping this going


#14

Pulling this up, yet again, but I really think we should still fight for element queries.

Their approach matches a responsive web a lot better than media queries. Especially if we want web components to grow we should add element queries in the spec. They’re context agnostic which is a must if we want our components to be reusable.

As a web standards guys I hate specifying style in markup. But a <viewport> element doesn’t sound too bad, or at least an attribute could work as well. It would indicate behaviour, not style. Much like checked does on a checkbox. (<input type="checkbox" checked>) Both an element and an attribute could work with render engines. Heck even a mozilla engineer thought it would be OK if it could be inferred from HTML, right?

As I’m late to the party, can someone update me on why this would be particularly bad? Circular reference has been around since :hover, right?

By the way, element queries, container queries, I’m fine with both. The approach is far better, sure. But it’s just a name for an implementation. As long as we get closer to the actual scope of the component.


#15

Circular references with :hover are not great, but they generally happen on user interaction and can be stopped by the user (by moving the pointer away). Circular references with “element queries” would happen without user interaction, as soon as the styles are first applied, and would only stop with the browser or tab crashing or maybe some kind of browser mechanism that kills styles partly or completely.


#16

I proposed a slightly different syntax and function in ResponsiveImagesCG/container-queries#3 which would eventually solve the circular reference issue.

The idea behind it is to let the browser (instead of the stylesheet author) select the “right” container for the query.

There is also a prolyfill which implements this idea: https://github.com/ausi/cq-prolyfill


#17

Well, actually, the browser stops rendering a circular reference after the first loop. When you move your mouse it re-renders one loop each time. Something similar could be done.

But I understand we’ve moved to container queries. Which is a good thing as well.


#18

I’ve got an element query plugin that uses the ‘container query’ syntax, and works in all browsers including IE8 and up.

We also have scoped CSS with $this which can let you quarantine styles, as well as a working $parent selector for CSS and much more.

Check out the website elementqueries.com

Or grab the plugin from Github and start using it today: github.com/eqcss/eqcss

You can do some pretty crazy stuff:


#19

(Element Query demos continued…)


#20

The Discourse engine allows editing existing comments.