Change name of repo/solution from “container queries” to “element queries”?

[ZeeCoder]

I would like us to start the discussion this year by deciding on a "name" everyone could get behind.

Now I know that even the repo is called "container-queries", but I think there are some people out there that would rather call it "element query", or something else altogether.

Why is this important? We need to be on the same page on this from the beginning, otherwise when it comes to talking about the exact syntax, I can already see ourselves get sidetracked by the fact that someone used "container" while another example has "element" and a third some version of "media".

In my opinion this could lead to discussions that are ultimately pointless, very much like the semicolon vs no semicolon in javascript.

Let's just pick a name, and stick with it. That will also make syntax examples more consistent.

Now, My Opinion

I would keep the "container" name. 😂

I saw some people proposing syntaxes with "media", but I think we should make it obvious from the very beginning that this is something different from media queries to avoid confusion.

Historically to me it seems that we first started with "element" query, which was only about changing an element's styling based on some conditions on that very element.

Then, "container" queries started to pop up, which could also affect child elements inside the main "containing" element, hence the naming.

Example on how different the two might feel with a made-up syntax:

@element .SomeClass (width > 200px) {
  /* Only rules are allowed here */
  font-size: 16px;
}

@container .SomeClass (width > 200px) {
  :self {
    font-size: 14px;
  }

  .Child {
    font-size: 16px;
  }
}

In the case of the latter, instances of the ".SomeClass" element individually influence child nodes' styles, based on their own conditions. (They are scoped in this sense.)

From experience, I think the latter is way more powerful than only applying styles to the element itself.

Now all that being said, I'm not totally against calling it @element query either, so long as the same concept of containment / scoping applies.

[tylersticka]

As a designer, I find @container slightly more understandable... though I'm struggling to explain why. It could be that folks I admire in the community are already using that phrase. I've heard a few folks use the phrase "element queries," but it always takes my brain a half-step longer to grok what they're talking about.

But my opinion would likely sway given a compelling enough argument. 🤷‍♂️

[ZeeCoder]

Yeah that's probably due to popularity. 🤔 I think I saw more "container" mentions back when I first started researching the topic, that's why I felt that that was the direction things were going in.

On 16 Jan 2018 18:35, "Tyler Sticka" notifications@github.com wrote:

As a designer, I find @container slightly more understandable... though I'm struggling to explain why. It could be that folks I admire in the community are already using that phrase https://ethanmarcotte.com/wrote/on-container-queries/. I've heard a few folks use the phrase "element queries," but it always takes my brain a half-step longer to grok what they're talking about.

But my opinion would likely sway given a compelling enough argument. 🤷‍♂️

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/WICG/container-queries/issues/8#issuecomment-358061081, or mute the thread https://github.com/notifications/unsubscribe-auth/ADglEsKxJz2jYPJkhPKVQG94PPeIpscjks5tLOvcgaJpZM4RgN_5 .

[tomhodgins]

Element Queries …or… Container Queries?

I've written a few plugins using both terms, and been immersed in the discussion and use of this concept for a couple years and I think the overall functionality should be called “element queries”, rather than “container queries”, simply because I see “container queries” comprising one small part of all possible “element queries” we may want to support.

Most of the time when people refer to “container queries” they mean width-based breakpoints on elements and their children. That's fine, and we should keep using the term when that's specifically what we are talking about for clarity, but outside of “container queries” here are the other “element queries” I can envision being useful:

• width
• height
• number of characters of text content
• number of child elements
• scroll position
• aspect ratio (width/height)
• orientation (keywords like 'portrait', 'square', 'landscape')

Here is an image that highlights the feature that makes up “container queries”

And this is an image that highlights the features that make up “element queries”, compared to “container queries”:

Right now, “container queries” mostly refers to width, when “element queries” refers to all of these conditions, including width. Even if we only start by speccing out the part of “element queries” that make up “container queries”, I think it's a lot better to have the correct frame of mind for future expansion in case we extend the functionality to support more features.

Other reasons

HTML doesn't have “containers” but it does have “elements”

Nowhere in the HTML spec does it define what an HTML container is. It talks about 'containing elements', and flex containers, and uses the word 'container' in a number of different places to mean a number of different things…if we were to use 'container' for this feature we couldn't be clarifying the HTML spec, but would be confusing it further by defining yet another 'container' concept.

What HTML does have a lot of are 'elements', and those are easy to look up, they're even the very things we would be querying here. What should a query on an HTML element be called?

“Container” is a misnomer when used with void tags

Not all HTML elements you might want to query can even contain content, such as void tags like <input>. So calling a query you make on a tag that, by definition, can never contain content seems like a bit of a misnomer!

“Element Queries” predates “Container Queries” as a term

The term “element queries” is a few years older, and has been popular longer than “container queries”, so it has more recognition, more plugins, and more content written about it at this point. Considering the more focused scope of “container queries” compared to all “element queries”, I expect this will always remain the case.

“Element Queries” is a more popular term already than “Container Queries”

If you look at Google search trends the usage of “element queries” is currently, and has always been greater than the popularity of “container queries”

[tylersticka]

Right now, “container queries” mostly refers to width, when “element queries” refers to all of these conditions, including width.

When I've used the phrase "container queries" my focus has not been this narrow, but I appreciate the rest of your explanations (especially the "other reasons" section).

[eeeps]

“Element” queries became “container” queries when folks began to think that setting elements’ state based on their own state was unworkable.

@tomhodgins I don't know anyone who wants to limit [EC]Qs to only querying width (though I think that’s the most obvious place to start). The circularity problem applies to any/all size-related attributes being queried, and the name change was about the circularity problem.

I know that your plugins propose/implement a way out of the circularity problem, but I think it remains to be seen if that strategy is workable within native CSS (browser/spec folks, please review Tommy’s plugins, and chime in!).

The name should hinge on the type of thing that’s being queried. [EC]Qs don’t query the entire browsing context (“media”), they query specific “element”s within the page.

But if (and only if) there ends up being a further restriction, such that we’re only able to query ancestors (aka “containers”) and set the styles of descendants, “container queries” is a clearer, better name.

[tomhodgins]

Are we thinking of renaming the idea entirely like this:

If we think about it that way, I think we would lose something if we chose to use “container queries” to replace what “element queries” currently means. Or are we thinking of naming things like this:

Where we can clarify that “container queries” with a containing element (if we decide to implement those) are a type of element query, and that other types of element query might exist (from the outset, or to come later).

It doesn't really make sense to me to implement an idea called “container queries” without also first implementing whatever “element queries” are, since element queries seem like a prerequisite to having a type of element queries that are restricted to a new idea of a “container”.

This makes me wonder if when media queries were being specced if people had discussions about whether to call them @screen vs @print queries, instead of thinking of them as different media types for one @media query 🤔

What if there was something like @element for all element query types just as there is @media for all media types, and we can spec out as many different element types as we need, just like how media queries have screen, print, and more.

If a container-type element query is something we define, we could use a syntax similar to media query types like @element container div and (min-width: 500px) to show the type. This could be a good way to allow for future expansion.

[eeeps]

<aside>

This makes me wonder if when media queries were being specced if people had discussions about whether to call them @screen vs @print queries, instead of thinking of them as different media types for one @media query 🤔

@tantek might know a thing or two about that ☺️ I, for one, was fascinated to find the MQ idea startlingly well-formed in this proposal from 1993!

</aside>

[ausi]

+1 for keeping “Container Queries”

As we currently don’t know if or how it would look like in CSS finally, I think the name is not that important. If this feature ends up being something that doesn’t fit “Container Queries” we should rename it when that happens.

@tomhodgins I don’t think your distinction between Element and Container Queries matches how most people see this topic. The main difference as I see it is that Element Queries change styles of elements based on their own properties and Container Queries change styles of elements based on the properties of their ancestors.

[ZeeCoder]

Yeah I have the same definition for element / container queries as @ausi and @eeeps

I also don't agree with @tomhodgins 's distinction on element / container queries, that venn diagram should be reversed for me: All EQ is CQ but not all CQ is EQ. (Maybe we can talk about this later more on Skype? @tomhodgins As I've stated this before, I think based on these definitions even your plugin fits the container query description more than the element query one, since it has child selectors, which allows you to style elements based on conditions on their ancestors, as @ausi described it.)

Those images you used to list container / element query features is just plain wrong too. @tomhodgins If you just think of my plugin, that handles width / height / orientation / aspect ratio, and you can use container-relative units called rh, rw, rmin and rmax, so obviously container queries are not limited to width, and I don't understand where you got that impression.

What I did agree with is using "container" to style the element itself instead of it's children might be a bit weird at first, since there are no contained children to talk about. 🤔

For the record though, as you can see on my container query syntax sketch above, I think a container should still be able to change its own styles, not just children's.

I guess we could just roll with container query for now, and see if a change will make sense later down the line? 🤔

/cc @ausi @tomhodgins @eeeps @tylersticka

[ZeeCoder]

Ah, and we should probably keep in mind media types when it comes to the syntax. (Good point @tomhodgins )

I should probably be able to define different queries for the screen and print too, for example.

[tomhodgins]

The terminology for describing these ideas, as well as clarifying the distinctions between them is something I've been working on over the past year as I've built dozens of these plugins. When you start to map out and compare the features between different plugins doing similar-but-different things, new terms are required to describe new functionality and separations become clear where they weren't obvious in the past.

I've made a big master chart of my plugins, but it's quite a few plugins behind where I'm working at right now. Here are the plugins I've categorized so far:

And some of the columns in this chart separate what is capable of 'element queries', what has 'container queries', and what is limited to self + children (kind of like XPath's descendant-or-self axe):

Perhaps in this repo we should create a 'terminology' document that defines these new terms so we can have the discussion with more clarity. Concepts that need to have agreed-on terms and definitions so we can talk about what to implement include:

---

Scoped Styles

Element Queries and Container Queries would both expand on the style scoping CSS currently has. Currently this includes CSS variables and media queries, in the past it included things like expression() as well. By adding new abilities to target styles that apply to some elements, sometimes, we need to figure out what level that happens at (scoped selectors, scoped stylesheets) and figure out how things like element queries will interact with media queries.

---

Scoping Level

I have identified 3 different 'levels': scoped at the level of a stylesheet, selector, value. Examples in CSS of a scoped stylesheet include @media queries, examples of a scoped selector include pseudo-classes like :hover which responds to the mouse, and :checked which usually responds to events in the browser. Examples of scoped values are CSS variables which can be set from CSS, HTML, or JS to apply to individual elements in different ways.

---

Element Query

The generic ability to query an element's conditions for the purpose of styling

---

Container Query

The ability to query an element's conditions for the purpose of styling it and its children, like XPath's descendant-or-self axe)

---

"Self" or "This" Selector

A meta-selector to target only those element(s) matching the selector and query conditions (in the case of a scoped stylesheet being used for element queries, rather than a scoped selector)

---

Query Conditions

The individual features you can use to query an element for the purpose of styling

---

In the case of "element-based units" that behave like viewport-percentage units but are based on an element's own offsetWidth / 100 and offsetHeight / 100 I would consider the prerequisite for those to be any kind of element querying ability, I don't see why it's a necessary distinction that a 'container' concept must also exist before the idea is usable, and that only the measurements of a 'container' element can be used, rather than any element if you were using an element's own width or height as a unit.

Here's some simple code for implementing element-based units:

// Element-based units
function eunit(selector, rule) {

  let styles = ''
  let count = 0

  document.querySelectorAll(selector).forEach(tag => {

    const attr = selector.replace(/\W/g, '')

    rule = rule.replace(/(\d*\.?\d+)(?:\s*)(ew|eh|emin|emax)/gi,
      (match, number, unit) => {

        switch(unit) {

          case 'ew':
            return tag.offsetWidth / 100 * number + 'px'

          case 'eh':
            return tag.offsetHeight / 100 * number + 'px'

          case 'emin':
            return Math.min(tag.offsetWidth, tag.offsetHeight) / 100 * number + 'px'

          case 'emax':
            return Math.max(tag.offsetWidth, tag.offsetHeight) / 100 * number + 'px'

        }

      })

    tag.setAttribute(`data-eunit-${attr}`, count)
    styles += `[data-eunit-${attr}="${count}"] { ${rule} }\n`
    count++

  })

  return styles

}

And here's a demo page showing what that plugin can do, just drag the corner of the boxes to resize the elements. This is a basic feature of element queries, but it stands alone from other features (like container queries) quite nicely.

Lastly, we do know where the term 'container queries' first originated, it's from this Github package: https://github.com/joecritch/container-queries

This library will toggle DOM classes on modules based on their container's breakpointed widths. In theory, this should replace a workflow of using CSS media queries, which can only currently query the overall viewport dimensions, and focus on providing breakpoints for every one of your 'module' instances.

And the first item on the project's to-do list:

Add support for height queries

So a lot of us have written plugins we say do 'container queries', and I'm sure they all do…but we have to admit we're stretching the definition of 'container queries' broader than it is. If we also support other features beyond and outside of what container queries do (like height and aspect-ratio) that's totally fine, but then maybe we should consider that there's a larger set of all possible "something queries" outside of the limited definition of 'container queries' …and come up with a name for that larger set of all possible queries :D

[JackUK]

Big up the element queries!

[ausi]

I think @wilto described it quite well in his article “Container Queries: Once More Unto the Breach”:

Since a solution can’t allow an element to restyle itself, we can build that constraint into the specification: queries attached to an element can only influence the styling of that element’s child elements.

Armed with our new knowledge of the impossible, the search for element queries has been reframed as container queries.

So I think “Element” vs. “Container” is more about if the element itself can be styled based on its own properties or if only the child elements can be styled based on the properties of their container.

I think it would be great if we can put the name discussion aside for now and focus on what this feature should be capable of, so that we can get browser and spec people onboard to find out what is possible. Long discussions about the naming don’t help us (at the moment).

[tomhodgins]

I think we can decide what we name these concepts later, but the important thing is that we are thinking and speaking about the same named concepts so we can discuss ideas with clarity. I don't see how we can accomplish anything if we're not on the same page with our terminology.

Below I have listed examples of terms I know won't be the final terms, but lets associate some totally new identifiers to these same concepts to enable us to have this discussion without using the specific terms 'element queries' or 'container queries':

---

Queries on Elements = QOE

Queries limited to Containers and Children = QLTC

Element-based units = EBU

---

With that said, here are some statements I hope we can all agree on:

1. QOE don't exist today.
2. QLTC don't exist today.
3. QLTC are a type of QOE
4. All QLTC are QOE
5. Not all QOE are QLTC. (There may be types of QOE that are not QLTC)
6. If we implement QOE, we can implement QLTC very naturally
7. If we implement QLTC as a standalone thing, it's unlikely we can easily expand to more QOE in the future without a lot of fragmentation
8. It may be that the result of this effort ends up with QOE but not QLTC
9. It may be that the result of this effort ends up with both QLCT and QOE
10. It would be a missed opportunity if the result of this effort specced QLTC as a standalone thing without first defining QOE.
11. There are other ideas things inside QOE, like EBU, that are outside of QLTC

^ These distinctions are what I'm worried are at risk of being lost in the element/container naming confusion. Whatever terms are used, it's important to preserve the understanding we have so far on these concepts and how they fit together.

[dennisgaebel]

@tomhodgins element queries is my vote regarding this naming convention. container queries are too vague. elements could, and will be be single isolated pieces not necessarily residing in a container and why I choose element queries.

inputs, logos, nav links, buttons etc. etc.

[tylersticka]

Earlier I mentioned that I preferred "container queries" because it was more intuitive to my designerly brain.

But that same designerly brain finds it difficult to ignore the arguments for "element queries" based on existing usage. If a convention is already emerging, if developers are already adopting "element queries" (via plugins or simply written usage of the term) at a faster rate than "container queries," then that's very likely the term that will present the least friction moving forward.

[joshmanders]

I echo @tomhodgins and @dennisgaebel's sentiments.

[avantegarde]

I'm going to have to agree with @tomhodgins and @dennisgaebel. "element queries" seems to be a more logical name as not all elements may end up being a "container". Whereas there is no confusion around what an "element" is.

[tomhodgins]

I've created a wiki page here in this repository for terminology that we can all define and expand together as we discuss these features.

https://github.com/WICG/container-queries/wiki/Terminology

Let's all go add the concepts we need to talk about there, and list all terms that can be used to refer to those concepts, so when we discuss ideas we can link people directly to the specific meaning of the ideas we're talking about!

[ZeeCoder]

@tomhodgins I think it's still too early to create a wiki page.

We should only put there facts / agreed upon information. I definitely don't think everyone agrees with the Terminology outlined there, so until we do, we should take it down instead. Otherwise it will never become a reliable source of information.

On another note I realise now that this topic is more controversial and harder to decide than I thought. After giving it some thought I agree with @ausi in that we should postpone this discussion when we actually know we imagine this feature to behave.

What about opening a new issue to start discussing that instead everyone? Then I'll close this one down, as I don't see it going anywhere right now. 😅

[tomhodgins]

I don't think we should take it down, that's some of what's out there in other places so if it doesn't capture everything we want, I'd much rather people add to the wiki to include their ideas as well.

I'm not sure where we can write things down or being collaborative work, but taking down the first page we put up seems like backtracking to me.

Where can things like a list of terms we're working with (both in the process of coining and defining) live in the meantime?

[ZeeCoder]

Okay, how about this: First we need to clarify what goes where exactly at what stage of this process. Then we can start actual discussions. :D

I'm not against using the wiki for notes, so long as others agree and are aware what those are.

Actually having a very well defined process would probably be the most important thing, because we all have a great amount of ideas, so I think we'll need to be very organised.

Which is where @marcoscaceres and @tantek could come into the picture.

[eeeps]

@tomhodgins @dennisgaebel —

Above, when I heartily thumbs'd-up a comment from @ausi, I was mostly thumbsing-upping this:

I think it would be great if we can put the name discussion aside for now and focus on what this feature should be capable of.

As much as that notion appeals to me, the troublesome fact remains that we have a use cases doc in a repo titled cq-usecases, that uses the term “element query” throughout.

So first, regretfully: we need one name. Second, whatever we pick now, we should be totally open – eager even – to trade it in for a better one, once the mechanics of what we’re querying/styling are a little more sorted. Name changes are big deals, and opportunities to explain what occasioned them.

For me – in my head – this thing already went from EQs to CQs. To go back requires a good reason (like, “we figured out the circularity thing! it's not a problem anymore!” which is not the case). But I care a lot (I mean a lot) less about that than I do settling on one name now, and everybody understanding that it's in no way etched in stone and that we should change it going forward, as things get sorted, and if we find a better one.

This naming decision does not carry the weight of figuring out query mechanics with it. It's about branding and reducing confusion, right now.

So – the Google Trends link shows the race exactly tied in January of 2018:

That's no help.

Changing the repo/Slack names/urls seems harder and like it'll break more, than doing a find & replace in the documents, maybe?

Thoughts? We should decide soon.

[dennisgaebel]

I think there are already quite a bit of thoughts already in prior comments above?

[beep]

[removes co-chair hat]

Changing the repo/Slack names/urls seems harder and like it'll break more, than doing a find & replace in the documents, maybe?

This sounds right to me. The shift from element queries to container queries happened for a very specific reason—@eeeps recently tweeted the most succinct summary of why that I’ve seen—and the name of this repo reflects that.

Now, I recognize there’s disagreement about that shift, and the name in general. And to be clear, that’s excellent. But as @eeeps mentioned, changing the name requires work; and to me, the payoff of that work seems minimal at best right now. Especially since—and this is the key bit— the name might change to something else entirely as we finalize the use cases/requirements.

I like that @eeeps described this as “branding”. Which isn’t to devalue this discussion at all: branding is impossibly important. But we need to know what we’re branding before we can brand it. And as we chatted on the kickoff call (notes are here, if they’re of interest), a documented set of use cases / requirements is what’ll help us do that. And right now, we don’t have those.

Given that, I would vote we keep the name as-is for now, and put this issue on hold until a better candidate emerges through our work on https://github.com/WICG/cq-usecases/issues/60 and https://github.com/WICG/cq-usecases/issues/36.

[re-dons co-chair hat]

Two quick issue tracking points from me:

1. I’m going to rename this issue to better reflect the aim of the discussion.
2. Additionally, if someone has a compelling argument demonstrating that the current name is actively blocking work on the use cases and requirements, please let me know by, say, EOD today. Otherwise, I’ll de-prioritize this issue, and we can revisit it once we’re further along on https://github.com/WICG/cq-usecases/milestone/1.

Thanks, all!

[beep]

Closing for now, and we can revisit/reopen as needed. Thanks, all!