The Current State of Element Queries

Basic queries (or "container queries" if you must) continue to make their way into conversations between responsive web designers, but their inclusion in any specification and the current landscape is not clear. In this article, we will discuss issues related to elements and community consensus between developers and standards working groups.

What are the queries for items?

Element queries allow elements to "react" to their own constraints, regardless of screen size constraints. This is the most important detail that one has to understand. Media queries as we know them are 100% responsive for layout, but the responsive layout is not 100% @media queries. Modules, components, interface elements will always grow and shrink with the screen, but never react alone, that is why @media is not not the complete solution to our problems.

Take a look at this raw demo item queries using eqcss :

The Frontline

Many people seeking solutions for item-based breakpoints have begun to implement CSS-in-JS using frameworks such as React. Although progress has been made in other areas, it has fractured the solutions that developers created from general CSS or JavaScript solutions in several framework-specific libraries. Although the results vary, the main features of these tools are often very similar. In the future, a standardization of these matching techniques could solidify an approach of this type of sensitive design to apply to any web site, or any tool.

During my discussions on this topic with Tommy Hodgins (a petitioner for element and creator queries from eqcss ) it seems that people are always aware of both "queries "elements" and the separate concept of "container requests". The consensus seems to be divided into a few different areas:

So, what's on the wish list for developers?

  1. Create a Resize Observer and study the benefit of giving developers a better primitive for building break points based on width. This is the fundamental piece we need by using JavaScript to query elements efficiently. The unfortunate news is that Resize Observer is not ready, but the community of its creators is working hard to make it a reality. You can read the public facing spec if you want to dive further.
  2. Develop Houdini in a working model and present it as a perfect case of use towards our needs. At the present time, the CSS working group is focusing on Houdini
  3. Providing more power to developers using the APIs defined by the CSS Object Model (a collection of 39; API that allows JavaScript to speak and manipulate CSS). The developers of CSS OM intend to expose a newer and deeper access to the way a browser processes and thinks about CSS. These aspects will allow developers to write CSS plugins more closely; something we have not yet been able to achieve. If the CSS Object Model arouses your interest I encourage you to read also this specification

Houdini Who?

Imagine that you could write a plugin that acted more like a browser fix than a JavaScript plugin. What if you had access to inject your own logic into how a browser parses, paints and renders pages? What things could you "learn" from the browser instead of relying on logic at the top of the page to calculate it?

Currently, we are stuck with the way a browser deals with CSS, but with Houdini the hope is that we will have the opportunity to rearrange and prioritize so that we can calculate values ​​using smart approaches, or control rendering to hide flaws. The JavaScript and CSS object template APIs give CSS the same kind of access, control, and power that JavaScript and DOM APIs bring to HTML. According to Tab Atkins, Houdini also uses the logic Typed OM and Parser API and these are the underlying technologies of the custom rules that allow you to specify the query rules of the application. element in your style sheet.

There is a site entirely dedicated to tracking its progress to ishoudinireadyyet.com but in the meantime, consider other potential solutions.

Use an iframe; Problem solved

Using iframes to wrap elements is certainly a smart approach, but unfortunately it is still not a real solution to the problem; plus a creative hack. Read more about this trick from Tab Atkins's blog .

CSS Container

Although not stabilized as a specification, this property is meant to be useful on pages containing many independent widgets. The documents claim that it can be used to prevent the CSS rules of a widget from changing to others on the page. A property value of strict suggests that it may avoid many problems of container queries, but this is not the complete solution;

A major problem with container queries is that children and their contents may have an effect on the size of the container. This can be avoided in theory using CSS containment, but let's look at the real problem that causes this dependency between elements.

Cyclic Dependencies: The Nemesis of the Container Query

Take a look at the following interview by Dan Tocchini (you might want to start the video from 10:00 because Vimeo does not allow it to time stamp).


Why can not an item be sensitive to its size? Cyclic dependencies. Here is a graphic recreated from the video above to clarify:

Each box depends on the constraints of its box containing ( width in this case ) And it is there that the cyclic dependencies appear. There is a constant relationship between these related elements that occurs naturally. This type of behavior also exists with : hover events like Tommy Hodgins explains in this video.


Cyclical dependencies are where much of the people who use the term "query container" get stuck because:

  • This is a legitimate problem because CSS is already suffering. ]
  • There is nothing that developers can do to work around this problem because it requires a major rewrite of the CSS language itself.
  • This would require some browser-level tweaks.

The good news is that browsers are starting to show evidence of working around these issues as previously discussed with Houdini.

Prospects for the future

It turns out that there is a CSS Element Queries (dream) spec by Tommy Hodgins; and while only a dream specification, it is very impressive the lengths taken to actually put words and suggestions to the conversation. He also compiled a site that correctly lists developers working on container queries entitled " Who Works on Container Queries ".

After all my research, I still wonder why the majority of our community does not build this way when we can? We had the opportunity to build this way before CSS @media was supported in the browser, but it seems that we have become sidetracked. We went from having no idea about "best practices", to discover how to get various results using @media ; and that spreads like wildfire. Articles dealing with "adaptive media-free layout" using smarter display models such as Flexbox and Grid illustrate the fact that we have a hard time divorcing the responsive layout of media queries.

Discover this presentation by Eric Portis ( contain your excitement ) in which he discusses this same point; With so many roadblocks, how can we advance the web platform as a whole?

Here are some common sounds you will hear regarding item queries:

  • I'll take a look once it's an approved CSS specification (maybe it will never be …)
  • I will only support it once a browser will support it natively, but there is no sugar for item queries specifically.)
  • I do not want to use JavaScript for style because "That's Bad®"

As I've experienced it during my career, developers have rarely voiced problems using JavaScript to add support for @media with IE8 because we needed JavaScript to add style where browsers were missing. However, already using JavaScript in the browser to enhance CSS? It's a heresy for many; even some of those who are totally happy to use JavaScript to assemble HTML.

The ideas mentioned in the previous sections certainly allow developers to work on their own ideas, but we need to start meeting more frequently, compare notes, find a standard approach and lock it. Personally, we will not be able to separate JavaScript from CSS for item queries, so we need to adopt it. Anyone expecting a purely CSS approach may be at the train depot for many years to come.

Separation Thoughts

Do you use elemental queries in your own work? Are basic queries a lost cause because of the very stubborn views? I hope this discussion will help spark thinking that will allow JavaScript to sit at the table so that we can create exceptionally flexible components for the ever-changing web. As always, please post your comments in the comments and coding section.

Special Thanks

Many thanks to Tommy Hodgins for his time and valuable knowledge on this subject and for all his work. keep abreast of this community-sensitive topic.

Related Links

Advertisements

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.