-
Notifications
You must be signed in to change notification settings - Fork 24
Pick one noun: module, component, container, or something else? #67
Comments
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 ***@***.***> 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. containerpros
cons
componentpros
cons
|
To address your thoughts too Ethan, I don't really feel the need to separate those concepts. 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.
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.) |
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:
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”. 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:
Rephrase:
Original :
Rephrase:
Original:
Rephrase:
Original:
Rephrase:
Original:
Rephrase:
Original:
Rephrase:
(They are mostly redundant because they will have either different breakpoints, or slightly different selectors) Original:
Rephrase:
(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:
Rephrase:
Original:
Rephrase:
|
@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).
|
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.
No, I still think "scope" as a term has some ambiguity as long as the CSS specs still mention 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.
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:
These all clarify what we're writing. But if I look up "What is an HTML module":
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:
I have a 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
We have 1
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
What is a "context" in HTML? When I look it up I just find information about HTML 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”,
But you know what,
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" |
@eeeps “Module” works for me, personally.
@andykirk Well said. And +1. |
Finding “component” + replacing with “module” in my drafts, and closing the issue. |
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?
The text was updated successfully, but these errors were encountered: