Pick one noun: module, component, container, or something else?

The “things” that are changing in response to what we’ve settled on (for now) calling “container queries” need one name.

The existing use case uses “module” throughout. In keeping with the term “container query”, @andykirk’s recent limitations section uses “container” consistently, which seems sensible. In a couple of use cases that I’ve been writing up, I’ve found myself using “component” (oops), which I like – but I'd rather everything be consistent.

I like “module” and “component” because they avoid hinting at any technical solution (whereas “container” is a bit DOM-y).

I especially like “component” because it aligns with what I think people mean when they talk about Web/React/Vue/Angular “components”: portable, reusable, logical, cohesive things on a webpage.

Of course there are also BEM “blocks” and OOCSS “objects”, which refer to similar (identical?) concepts. For me, “block” has some specific connotations in CSS that I’m not sure we want, and “object” is, well, overloaded.

Those are my loosely held thoughts. It’s more important to pick one name than pick the perfect name; we’ve got two in the document now and I caught myself adding a third. Any thoughts?

Hmm. Good call, Eric. Glad you caught this!

I wonder if it’s valuable to have language to address both the thing—be it a “module” or a “component”—and the thing it sits in (the “container”)? Feels like we’d need to address both, no?

I’m pretty agnostic on module vs. container, myself. Though I assume this is something we’ll want to pattern after other parts of the spec.

On Mar 30, 2018, at 6:39 PM, Eric Portis notifications@github.com wrote:

The “things” that are changing in response to what we’ve settled on (for now) calling “container queries” need one name.

The existing use case uses “module” throughout. In keeping with the term “container query”, @andykirk’s recent limitations section uses “container,” consistently, which seems sensible. In a couple of use cases that I’ve been writing up, I’ve found myself using “component” (oops), which I like – but I'd rather everything be consistent.

I like “module” and “component” because they avoid hinting at any technical solution (whereas “container” is a bit DOM-y).

I especially like “component” because it aligns with what I think people mean when they talk about Web/React/Vue/Angular “components:” portable, reusable, logical, cohesive “things” on a webpage.

Of course there are also BEM “blocks” and OOCSS “objects”, which refer to similar (identical?) concepts. For me, “block” has some specific connotations in CSS that I’m not sure we want, and “object” is, well, overloaded.

Those are my loosely held thoughts. It’s more important to pick one name than pick the perfect name; we’ve got two in the document now and I caught myself adding a third. Any thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

My vote is for either container or component.

Both of those express the - for me - most important aspect of the idea: handle styles in a scoped, reusable way.

container

pros

been around a while,
arguably being more DOM-y helps, as we're dealing with HTML, CSS and the DOM in general

cons

There's a constant battle between element v container
I feel "container" doesn't express what it's about as well as "component" would

component

pros

People using UI libs will immediately know what it's about,
Not weighed down by any historical baggage
cons
If you haven't used any of these UI libs, it might not be as intuitive as element- or container-query. (probably worth doing some research in this area)

To address your thoughts too Ethan, I don't really feel the need to separate those concepts. I think calling whatever you're styling inside a container/component using these queries just "descendants" is fine.

Worked for me so far anyway. 🤔

I think I still come down in favor of 'container' - it feels more semantically correct. The problem I have with 'component' (even as someone who works with pattern libraries a lot) is that it doesn't have any inherent meaning. And since the notion of a 'container query' is that the rules apply to the container, and impact the contents (er, 'descendants' :) ) this feels more accurate/understandable/native. In that way I don't feel like it's a historical baggage issue, but just focusing on plain meaning in the context of the 'page'/DOM.

I understand the desire to keep the terms solution agnostic, but at the same time, these words do imply different things.

I wonder if it’s valuable to have language to address both the thing—be it a “module” or a “component”—and the thing it sits in (the “container”)? Feels like we’d need to address both, no?

This is what resonates with me most. When I read "component", I think of "the thing we're trying to change" and when I see "container" I think "the thing around the thing we're trying to change".

So if the technical solution allows us to check the conditions on an element and change that element, "component queries" is fine. But if we're checking the conditions on a parent and changing the children as a result, that's "container queries"

(And I vote that stay away from "module". "Module queries" is a harder phrase to say. Go ahead, open your mouth and try it. Now imagine the number of times this is going to be said in offices and on stages around the world.)

how (often) are we going to explain to people that by 'component' we actually aren't referring to web components in any way at all: https://www.webcomponents.org/specs
how (often) are we going to explain to people that by 'module' we actually aren't referring to ES modules in any way at all: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import

I think re-using the names of other nascent technologies could be as confusing as explaining why "JavaScript" never had anything to do with "Java". Let's not create confusion where there doesn't need to be.

The term I used most referring to this concept when working with EQCSS and other plugins like it was 'scope' (which can also be confusing). I would use it in the following ways:

"This query will open a new scope on each div element in our document"
"Using $this div limits the selector to targeting only those div elements inside our scoped style"

So maybe instead of trying to come up with a synonym for "widget/container/component/module/box/block" we can come up with a fresh term related to the "scope/barrier/border/partition/fence/enclosure" instead. Not a term for the "thing contained", but a word for the idea of the "containment of things"?

Woah, a whole lot of good points and ideas here.

Re-reading the limitations section (a little more closely this time!), @andykirk does use “module” once, and whenever he uses the word “container” he is actually discussing a “module’s” immediate context.

In a world of cheap and easy wrapper divs, the distinction will often be invisible, but @beep I agree that the module/container distinction is a useful one to make, and one that @andykirk has already brought to the spec.

@zeecoder, does the above make sense? It’s just as easy to talk about “styling the container’s descendants” as it is to talk about “querying a module’s container” - looking at what I’ve written and what Andy and the previous contributors have written, I think in different situations, we’ll want to do both.

@jpamental - when we start discussing a technical solution it will be a lot easier to speak clearly and without ambiguity, but I think we’re in the exact same fuzzy situation that pattern library people are in, when we’re discussing use cases. We need a word general enough to describe many different sorts of designy things (product cards, carousels, date pickers, etc), and should, in the use cases section, avoid the clarity of technical specifics (DOM node).

@alanmoo agree! So, I’m leaning towards talking about “container queries” that conditionally style “modules”... keeping both terms, to mean the two different things that they imply. I agree that “module” feels awful in your mouth, but as I stated earlier, I’m more interested in consistency than perfection, and it’s already all over the document.

@tomhodgins I am intrigued by this suggestion, but I’m having a hard time trying it out. How would you re-write the third & fourth paragraphs of the existing use case and the caption of figure one, using something like “scope”?

Just chipping in here to say that in the limitations section I used “module” because it was already used in the existing Use Cases section (section 2), and container, because, well “container queries”. Those terms sit well enough with me, but I don’t have a strong opinion. If the terms change I don’t mind replacing them in the limitations section.

I agree that the two sides of the equation both need names, though, and that they should be non-technical.

Okay, I'm not sure how you're counting paragraphs so I rephrased the whole section below. I avoided using any terms other than 'element', 'responsive layout', and 'design' and I think the text still makes sense. (and might even be clearer)

Here I'm calling any HTML element an 'element'. I'm calling any set of elements that have a responsive design intention a 'responsive layout', and this use case is trying to illustrate how the design intention behind some types of 'responsive layouts' are a poor fit for expression via media queries in CSS.

Original:

Figure 1 is an example of a relatively simple and fully self-contained module’s layout, using only a single min-width media query to reflow content.

Rephrase:

Figure 1 is an example of a responsive layout that ideally requires a single breakpoint to reflow its content based on the width it appears in a layout.

Original :

Figure 1: An example of a self-contained module that requires a single breakpoint.

Rephrase:

Figure 1: An example of a responsive layout that requires a single breakpoint.

Original:

In this layout, this module can occupy containing elements of varying widths, governed by multiple breakpoints. In small viewports, we’ll be using a linear layout where each of our five modules occupy the full viewport — this layout is covered by the base styles outside of our media query. At higher breakpoints, these modules will be displayed side-by-side: three across, then below that two across. The three-across layout will be covered by the global styles within our viewport-based media query. Parent-specific overrides will need to be written for the two-across layout, as these modules will need to shift to their wide-format at a smaller viewport size than the ones above them.

Rephrase:

Figure 2 is an example of a layout where five elements from Figure 1 appear as siblings inside a shared containing element. When the viewport is narrow, we'll be using a vertically stacked layout where each of our five elements can occupy the full width of their containing element. At wider viewport sizes when there is more room for these elements inside their containing element, these elements will be displayed side-by-side in a stacked layout: three across in the first row, then two below. Since these two rows of elements will be showing up at different widths when in our side-by-side layout, we will need to write two separate media queries to cover the single breakpoint our design requires.

Original:

Figure 2: Some of the contexts in which the module in fig. 1 might appear.

Rephrase:

Figure 2: Some layouts in which the elements from Figure 1 might appear

Original:

In order to accomplish this layout, a developer would need to duplicate all of this module’s “wide layout” styles into a second viewport-based media query—set to apply at a smaller min-width than the global breakpoint styles—with all of our styles scoped to a parent container. This now means that any future edits or bug fixes to the wide-format layout styles will need to be made in multiple places, and this maintenance cost increases exponentially with each module-level breakpoint required.

Rephrase:

In order to realize the intended layout using CSS media queries, developers must write two different media queries targeting these elements at different viewport widths. The first set of elements (3-across) appear narrower than the second set of elements (2-across). Because of this difference in width existing in the layout in Figure 2, the media query enabling these element's wider layout will need to be written for a narrower viewport width than the breakpoint required to style the set of elements above them.

Original:

Figure 3: A stylesheet heatmap showing the redundant styles required to accomodate the layout variations in fig. 2

Rephrase:

Figure 3: An illustration showing the mostly redundant styles needed to accommodate the layout variations in Figure 2

(They are mostly redundant because they will have either different breakpoints, or slightly different selectors)

Original:

Similarly, introducing a new context unlike the previous two—shown in figure 4 with the introduction of a “sidebar” on an interior page layout—means duplicating or overriding all of a module’s media queries yet again.

Rephrase:

Introducing these elements into a new layout (one in which the containing element holding these elements is a different width than the layout in Figure 2 relative to the viewport's width) means duplicating or overriding our existing media queries. The problem here is that the responsive breakpoints are coupled to the viewport's dimensions while our design intention is coupled to the width of these elements containing element or the size they appear in the layout.

(This is because an element's width can be informed either by the available space in its containing element, a length related to the available space, or its width can be specified separately from the space available)

Original:

Figure 4: A wireframe introducing a new context for the modules in fig. 1, where no breakpoint should apply

Rephrase:

Figure 4: An illustration showing the elements from Figure 1 inside a different layout where the media queries necessary to realize the layout desired in Figure 2 should not apply.

Original:

The module in this new sidebar context will never need to reflow to the wider layout, and as such we’re left with two options: scoping all of our modules—with the exception of the two-across layout—to a parent class, or introducing a new media query that overrides all of our wide-layout styles based on the sidebar’s parent class. Despite the relative simplicity of our module and our overall page layouts, one is left with a bloated and difficult to maintain stylesheet.

Rephrase:

The elements in this new layout will never need to reflow to the wider layout described in Figure 1. To ensure this is the case we have two options: we can add an identifier to each containing element these elements will appear inside and qualify all responsive style overrides for these elements with this extra identifier, or we can carefully override the unnecessarily applied media queries. These approaches can increase code size, selector specificity, and make the markup and styling of a layout more fragile.

@tomhodgins — I took the time to give this a real read-through and I don’t see a shift from talking about things ("widget/container/component/module/box/block") to talking about a fence around a set of things ("scope/barrier/border/partition/fence/enclosure"). What I do see, mostly, is "module" replaced with "element", and "context" replaced with "layout" (and more detail about some of the awkwardness of trying to use media queries to accomplish the use case).

Is that an accurate summation of what you’ve done here?
Has conducting a concrete re-write changed or refined your earlier thoughts about “scope” & co.?
What do you like about "element", vs "widget/container/component/module/box/block"?
What do you like about "layout" vs "context"?

Is that an accurate summation of what you’ve done here?

Yes, I rephrased the text as it was to something I thought made more sense and what ended up happening was I able able to use already well understood terms like "element" and "layout" to communicate what we had written, so there didn't seem to be a need for a new noun that we needed to pick a name for to communicate what we had already put down. That doesn't mean we don't need a name when we do want to talk about the containment aspect, or the boundaries of what can be affected - but what I learned rephrasing is that so far we haven't written anything that requires this new word…yet.

Has conducting a concrete re-write changed or refined your earlier thoughts about “scope” & co.?

No, I still think "scope" as a term has some ambiguity as long as the CSS specs still mention :scope which is something else entirely, so I'm not sure the term "scope" is going to add additional clarity to what we're talking about rather than create confusion. Whatever word we use I think it should be a brand new term that's never been associated with any other HTML or CSS technologies before. In the case of what we had written, it wasn't necessary to speak about this containment aspect, whether in the sense of the "thing-contained" or the "containment perimeter" so no placeholder word was used for it in my rephrasing.

I'm sure when we talk about the details of how the technology works (beyond the one use case we have written) the need will be more evident that in describing the most basic need for the technology.

What do you like about "element", vs "widget/container/component/module/box/block"?

I like 'element' when you're talking about HTML elements because if you pause in the middle of reading this to look up "What is an HTML element" you're going to find:

HTML Elements from W3Schools (this helps explain what we're talking about)
HTML Element from Wikipedia (this helps explain what we're talking about)

These all clarify what we're writing. But if I look up "What is an HTML module":

Angular Modules from W3Schools (this is a sidetrack and adds confusion)
HTML Modules issue from w3c/webcomponents (this is a sidetrack and adds confusion)

Anybody looking up those is either bound to stay confused, or get a little more confused about what they're reading. For what we're talking about is it essential to speak of the "elements queried" as some self-contained unit when in reality we're just talking about different HTML elements inside an HTML document?

Consider this example:

<div>
  <h2>This is a long and <strong>strong</strong> headline</h2>
</div>

<style>
  @element div and (min-width: 200px) {
    :self {
      border: 4px solid red;
    }
  }
  @element div h2 and (min-characters: 5) {
    :self {
      background: lime;
    }
  }
  @element strong and (min-characters: 5) {
    :self {
      color: purple;
    }
  }
</style>

<script src=http://elementqueries.com/EQCSS.js></script>

I have a div with an h2 inside it, with a strong inside that. I have written element queries for my div, for my h2, and for my strong elements separately. Do I have 3 'modules' here? Do I have one 'module'? I know I have three separate elements and three separate queries, but they're all contained inside the div…are those submodules of the first module? Are you even allowed to nest a 'module' inside another module in HTML? Nobody knows the answer to that because nobody knows what a 'module' is, means, or can and can't do.

When we're using a word like 'module' I am not going to be able to look up the answers about what they are, how to use them, etc. But if you're talking about them as HTML elements and you look up things like "can you nest HTML elements inside of other HTML elements" you're going to find the right answer for what we're talking about without us having to redefine an HTML element and explain and teach the same principle to everybody with a different name.

I'm sure there will be plenty of places where we are referring to the border of containment, and things on the inside of that perimeter and outside of it…but for most cases where we're talking about elements and querying them, the word 'element' works just fine.

Let's say we add another strong element here after the others:

<div>
  <h2>This is a long and <strong>strong</strong> headline</h2>
</div>
<strong>Hey</strong>

We have 1 strong element inside the div, and one strong element outside. I think we need this new word we're lacking when we're trying to say things like:

"The first strong element is within the _____ of the div element, but the second strong element is not".

You can fill in the blank with words either like "boundary" or like "zone", referring to a perimeter around an area or the area inside of a perimeter, but using words like "module" or "container" doesn't really fit. The idea of it being a 'self-contained part' doesn't even necessarily match the reality of a document with elements being queried at all levels, even inside other queries. It's not always the case that these will divide nicely into independent things that can be isolated from the document and transplanted into another document (although this technology would help greatly with that). It seems like it would also be the possible that we might have layouts that use this technology for responsive breakpoints, but are still built as an indivisible HTML layout that depends on the presence of different queried elements to work together too.

When I think of a "self-contained" group of HTML elements that can be moved around inside any HTML document, with their own self-contained responsive breakpoints…that definition matches what iframe elements already do 100%.

What do you like about "layout" vs "context"?

What is a "context" in HTML? When I look it up I just find information about HTML <canvas> element, is that what we're talking about here?

I believe the what we're showing in the illustrations are examples of website layouts, intended to be realized with HTML elements and CSS styles. So that makes me wonder — for an HTML element to show up in more than one "context" does it need to show up in more than location in HTML…or is changing CSS styling of an element enough to claim that somehow the "context" of an HTML element is different?

I don't know the answer to that because I don't know what constitutes a "context" or not (or how to look that up) but if I look up "layout" I find information (beyond just HTML and web design) that helps me understand what we're talking about here. Even generic graphic design explanations of what "page layout" means will still give insight into what we are talking about here, so why sacrifice all that understanding to use the word "context"? Can the argument be made that "context" is somehow more clear, or more helpful than using terms like "layout" or "design"?

This issue is growing a bit in “scope” (badum-chhh, thank you, thank you), so ① thank you for the clear answers! ② do you want to spin up a separate issue for the “context” vs “layout” stuff? This thread is ballooning a bit.

A little recap:

I raised this issue because I thought I saw “module” and “container” being used in different parts of the doc to refer to the same thing, and caught myself adding a third term, “component.”

Reading through the first batch of replies, and reading the document again, I realized that “container” was being used to talk about the thing being measured, and "module" was being used to describe a cohesive unit of visual content (that the author wants to change/adapt). Those are two distinct (and valuable) concepts to have in the document, and I find myself now wishing I had realized that before raising the issue, and opened up a can of worms in which we debate the pros and cons of “module“ vs many alternatives.

Like a few voices here, I don't love “module”,

because of the possible confusion with other specific webby things called “module”, which @tomhodgins has pointed out
because it just sounds like your mouth is full of marbles, I totes agree with @alanmoo

But you know what,

module | ˈmäjo͞ol | noun each of a set of standardized parts or independent units that can be used to construct a more complex structure, such as an item of furniture or a building.

For me, that’s good enough. A “module” is a cohesive sub-part of a larger whole. That's all I mean when I've used the word “component” in my two use-cases-in-progress, about a color picker and ad – “module” describes both. Give a few concrete examples, use the word “module” consistently to describe them, and no one will think you’re talking about Angular modules.

“Component” would work too, and even though “element” is technical, which I don't like (and aren't these chunks of UI composed of whole trees of multiple elements?), I wouldn’t raise an eyebrow or an issue if there was consensus around it. Paired with examples, I think it could also pass muster. I don't have a strong feeling for anything other than good enough and consistency.

Is there enough consensus to merit changing “module” to something else? Do others have strong feelings that a change is necessary?

Let's not forget that terms are repurposed all the time when required in different contexts. That's just how language works. If new terms were invented every time, things would get more confusing pretty quickly.

To repurpose a term, all that's generally needed is a definitions section or glossary in the document and for the terms to be used consistently.

"In the context/subject of container queries, a container is defined as X and a module is defined as Y"

Is there enough consensus to merit changing “module” to something else? Do others have strong feelings that a change is necessary?

@eeeps “Module” works for me, personally.

To repurpose a term, all that's generally needed is a definitions section or glossary in the document and for the terms to be used consistently.

@andykirk Well said. And +1.

Finding “component” + replacing with “module” in my drafts, and closing the issue.

WICG / cq-usecases