Page builder developers have been pretty bad at naming things for the last decade. It makes for a frustrating experience for advanced users and a much steeper learning curve for beginners.
As we develop Etch, a next-era visual development environment for WordPress, we’re putting a lot of thought into how things have been named and how they should be named going forward.
Bringing clarity to naming conventions shouldn’t just be an Etch thing, though. There’s room for improvement across the board.
Unification of terminology:
- Improves data liberation and translation.
- Makes it easier for users to adopt new tools and new workflows.
- Makes it easier for agencies and freelancers to manage sites they didn’t build.
- Reduces the learning curve for beginners.
Below is a list of confusing terms, an explanation for why the term is confusing, and a proposal for better terms.
“Block”
Perhaps the most widespread term with the most confusion is “block.”
- WordPress’s Gutenberg editor identifies as a “block editor” and all the elements are called “blocks.” But, other page builders don’t identify as block editors.
- Some builders refer to elements as “blocks,” others as “modules,” and some as “elements.” There’s even the throwback term, “widgets.”
- In Bricks Builder, there is a “block” element, which is just a div set to display flex by default.
- In fundamental web development, elements can be “block level” or have their display set to “block,” which is a description of how the element is rendered.
This is all quite confusing for no reason. As a general principle, we shouldn’t casually repurpose terms. The term “block” is already reserved for the display property in web design. It can’t just be hijacked and used to describe every element in a specific type of editor.
Proposal: The fundamentals of web design already decided that divs, headings, links, images, etc. are HTML “elements.” In CSS, you can select these things via an “element selector.” This is a done deal. There’s no need to rename these things. They’re called elements, they’ve always been called elements, so let’s keep calling them elements.
Proposal 2: There’s a definite use case for a div that’s set to display flex/column and 100% width by default. This is what Bricks refers to as a “Block” element. This should be renamed to “Flex Div” because that’s exactly what it is. “Block” is actually the exact opposite of what this is, since display: flex; is definitively not display: block;.
Section
The section element is a very important grouping element in web design. Unfortunately, most visual builders don’t offer this element and the ones that do, often offer it incorrectly.
Whether the section uses a traditional container and gutter structure, a content grid structure, or a safe-content-width structure is up to each environment, but the section element should exist, should be structured properly, and should have a semantic section tag by default.
Examples of builders that don’t offer this element: Elementor, Gutenberg, Beaver Builder, etc. all use generic “container” (definitely wrong – see below), “group,” or box elements to make a section.
Examples of builders that do this wrong: Oxygen Builder and Breakdance put the “gutter” and section padding in the container element instead of the section element. This is objectively wrong, since it interferes with the chosen content width of the website and destroys the usefulness of the box model of the container.
Container
The direct child of a section element, or any box that establishes “content width” and center alignment, is often referred to as a “container.” Many page builders offer a “container” element that is a shortcut for adding this behavior.
However, some page builders (Elementor, for example) use “container” for literally everything structural. They call every box a container with zero differentiation between the semantic tag being used (section, div, list, etc.) or its behavior (page-width and centered). This is chaos!
The problem with both of these situations is that “container” creates confusion with container queries.
When you add a container query in CSS, you establish a “container.” This is the only time that a browser inspector will actually refer-to and label something as a container. But, this container is clearly different from a content-width container or any other generic box.
Once again, we’re trying to repurpose terms and we’re creating mass confusion in the process.
In this case, there’s no official term for a box that establishes content-width and center alignment. We’re free to name it, but we should avoid using names that are already in use.
Proposal: This is an element that I’m not 100% sold on a name for. I’m leaning toward “shell” because it’s a good structural and containment term. I’m open to suggestions as long as they’re short, concise, and make sense.
Proposal: Multiple people have voted for “Inner.” This is a common nomenclature for section inner wrappers.
Proposal 2: Stop calling every box a container. A “container” is not a multi-purpose term. Everything can’t be a container – that’s madness.
Gutter
In Automatic.css, we’ve been using “Gutter” as the name of the inline space that protects content from touching the edge of the screen.
A big problem with existing visual builders is that they fail to establish a consistent gutter and seemingly fail to recognize its tremendous importance.
Since most builders don’t have a section element, users end up adding group blocks, containers, boxes, or divs and then must add padding or manually establish a gutter on a section by section basis.
This requires the user to remember and manually match their inline space value on every section manually while creating a ton of room for inconsistencies. And since this value is rarely tokenized, the user has no global control over it later.
To make matters worse, we discovered that Bootstrap was already using the term Gutter, but inappropriately.
From Bootstrap: “Gutters are the padding between your columns, used to responsively space and align content in the Bootstrap grid system.”
This is completely nonsensical and confusing for two reasons:
- There’s already a term for this space. It’s called “gap.”
- “Gutters” don’t run between things. The gutters on a bowling alley are exclusively on the outside of the lane. The gutters on a street are exclusively on the outside of the street. The gutters on houses are exclusively on the outside of the house.
It should come as no surprise that Bootstrap is inappropriately using this term, though, because confusion is their favorite hobby. After all, this is the framework that has a “grid system” built with Flexbox. Stop the madness!
Proposal: “Gutter” is the term exclusively reserved for the inline space between the farthest edge of your content (content-width) and the viewport (viewport-width). It should be tokenized with var(--gutter) so the value is consistent and easily referenceable.
Columns
Bricks, Gutenberg, Elementor, Divi, Beaver Builder and many other page builders have a “columns” element. The problem is that “columns” is a very poor description of how these elements behave and it conflicts with how “columns” is used elsewhere in web design.
What these “columns” elements all do is create a multi-column flex layout, but there’s no way to know how that’s being done from the term itself, and the method used is of critical importance.
“Columns” in CSS describe a multi-column layout where content can flow freely from column to column. This is a very specific type of layout that is completely different from the flex and grid layouts being used by the “Columns” element in page builders.
Another issue is that columns are also established by CSS Grid. But the “columns” element doesn’t tell us whether or not our columns will be established by flex or grid. And…
The final issue here is that creating structural “columns” with Flexbox is usually the worst way to create columnized content. For structural layouts, grid is far superior to flex.
Proposal: This element should be called “Flex Columns” to differentiate from the CSS columns property and its use should be extremely limited. I’d even argue that there’s no real reason for this element to exist as grid is almost always a better choice. In the instances you’d need Flex (e.g. Flex Grids), the page builder is usually not advanced enough to provide this as an element.
Proposal 2: End the offering of a “row” element. There’s no such thing. A Flex Div is already a row or has the ability to be a row. Grids have rows by default. Block level elements align themselves in rows by default. The concept of a “row” is established by the parent’s display property and can’t be offered as an element by itself without creating tremendous confusion.
Text/Basic Text/Rich Text
When I add text in Bricks Builder, it adds a div with text inside (head scratcher).
In Gutenberg, there’s no text element. It’s a paragraph element that adds a paragraph tag. But there’s no “rich text” element like we have in Elementor, Bricks, Divi, etc.
The rich text element in these page builders allow the user to freely write long-form content while including things like lists, images, and formatted text.
This is all very confusing, though, and the rich text element is one of the most problematic elements in page builders because the things inside the rich text interface typically can’t be styled independently with the builder’s inputs.
Proposal: We should offer a “paragraph” element that adds a single paragraph with an editable HTML tag so that it can transmute into a div or span if necessary.
Proposal 2: Rich text is okay to offer as long as the interface allows for granular control of rich text children. Offering rich text without this granular control is extremely problematic for users.
Button
In almost every page builder, the “button” element adds a link that’s pre-styled to look like a button. The problem, obviously, is that there is a <button> element in HTML and this is not the element being used by the builder.
The general rule here is that links are for navigation and buttons are for triggering on-page events. This rule speaks to the HTML element used, not what the element looks like.
Unfortunately, the word “button” is used to describe a visual appearance where the semantics of HTML actually say nothing about visual appearance.
This is one of those areas that essentially proves that you can’t build websites without proper requisite knowledge. If the button element actually adds a <button>, beginners will always use the wrong element.
It’s tempting to try to step in to rescue the beginner user, but this is precisely what we should avoid. All of these terminology problems exist because builders are trying to coddle beginner users instead of building the tool the right way.
In the long run, it’s disempowering to beginners and highly frustrating for people who actually know the language of web design.
Proposal: Builders should provide a Link element that adds an <a> and a Button element that adds <button>. It’s up to the user to style their link to look like a button, which can be done automatically with builder options or with a single utility class. We should also make it clear which HTML tag is being used by an element at all times and make it easily editable.
Templates
The term “templates” in modern web design is diabolical. It’s an absolute free-for-all.
Every builder/platform seems to have a different take on what a template is and some have even branched off to define various types of templates.
In the screenshot above, every template in the Bricks Builder templates list is actually a template, except the first one. And if you were able to keep scrolling, you’d see more non-templates listed in the templates area.
This is because Bricks refers to almost everything as a template. Save a button to the “template library,” that’s a template! Save a hero section, that’s a template! Save a full page with conditional logic that uses dynamic data to display content as a single source of truth for unlimited instances – also a template!
Webflow has an entire library of themes that they refer to as “templates.” Elementor says the same thing.
WordPress foregoes the term templates, choosing instead to use “themes.” Except, their use of the word “theme” goes far beyond design and layout and deep into architecture, which is a huge issue we’ll tackle shortly.
The problem is that we need to avoid conflating design, layout, architecture, and functionality. A hero section can’t be a “template” if a full blog post layout with conditional logic and dynamic data is also a “template.” These are not the same!
Terms are important because they’re supposed to consistently convey specific information. This is what makes communication functional and effective.
Examples of actual templates:
- Blog post template
- Post type template
- Archive template
- Search results template
- Etc.
Not a template:
- Header
- Footer
- Hero Section
- Card
- Etc.
Proposal: The term “template” should be reserved for single-source, page-level renderings using conditional logic and dynamic data. This is in alignment with atomic design principles and ensures that we’re all on the same page with what a template is and isn’t. If the content is static and not assigned with conditional logic, it’s not a template – it’s functionally something else (hint: we have a name for it! Keep reading.).
Components
Another diabolical term in modern web design!
But why? Why the confusion? Why are we pretending like there’s no existing spec for components?
Builders often refer to things like sliders, modals, accordions, etc. as components. Hell, when we created Frames we became guilty of the same thing (but we’re committed to fixing this!).
Another twist in this story is that builders came up with the concept of “global components.” This refers to an element that can be used in duplication where both the style and content are locked to the original instance.
Guess what? None of these things are components!
The “global component” in most page builders is a neutered form of component functionality. It’s mostly useless in the context of actual components.
Static duplications of pre-configured dynamic elements like sliders, accordions, etc. are not components at all.
Proposal: Components in web design are encapsulated elements whose style and content are controlled from a single source of truth, with defined content properties to ensure that content is interchangeable without losing control of the component’s HTML and JS. If that definition isn’t met, you can’t call it a component.
Proposal 2: Accordions, modals, sliders, carousels, etc. are “Dynamic Elements.” This is a differentiation from a standard Element like a div, section, heading, etc.
Proposal 3: Headers & footers are/should be components. Stop calling them templates.
Patterns
We need a term to describe specific layout instances that are static and typically contained in a library of dozens, hundreds, or even thousands of options.
In terms of atomic design, we might have atom patterns (button), molecule patterns (cards), and organism patterns (hero section).
In some cases, we could have a full template or page layout pattern, but the use of the term pattern over template would convey to the user exactly what’s going on with the functionality.
See, patterns are static. You can turn a pattern into a component or a template, but if you’re inserting a “pattern” from a “pattern library,” you know that you’re inserting a static thing with no pre-configured component-based functionality, dynamic data, or conditional logic.
Frames, for example, is a pattern library and Dynamic Element library (we’re gonna fix that name). Etch will have a pattern library.
Proposal: Patterns and pattern libraries are for common/saved patterns that users can insert anywhere. It’s then up to the user if they want to componentize or templatetize these things.
Themes
Designers should perfectly understand what “theming” is.
So do event planners. “What’s the theme of the party?”
Here’s a question: Can you throw many different themed parties in the same venue? Of course!
Theming just describes the skin of something, essentially.
Webflow has one single architecture that you can build infinite different designs with. Just pick an industry like plumbing. We can create 100 different plumbing websites that all look completely different, but that are built on the same architecture.
What should we call these things? Themes!
But WordPress, which powers 43% of the internet, screwed everyone by insisting that the word “theme” describes design, layout, AND architecture!
If you’re choosing between plumbing themes on WordPress, you can’t just choose the one that you like the look and feel of, because the decision you’re making also determines the architecture that’s available to you!
To make matters worse, there are now “classic themes,” “hybrid themes,” and “block themes.”
Block themes have a completely different architecture and are designed to work with the name-fail “block editor” in conjunction with their “Full Site Editor” which is some weird hybrid of a neutered component editor and template management system (nobody really knows because they struggle to communicate all this themselves).
And since the architecture is intertwined with the theme, you can’t just swap themes without breaking a lot of stuff.
By the way, WordPress is coming out with components, but they’re not calling them components. They prefer the cute term, “partially synced patterns.”
Chaos!
Proposal: “Theme” (noun) describes the design and pre-configured layouts of a website within a shared architecture. You can also edit “theme styles” (colors, spacing, etc.) separately from the layout and architecture, preferably with a styling framework.
Proposal: “Theme” (verb) describes the act of styling something consistently, hopefully with a styling framework like Automatic.css.
Wrap Up
Are you on the same page with the importance of using consistent terminology?
Do you see the current level of confusion in the industry?
I’m going to treat this article like a living, breathing document. It’ll get updated as needed and you’re welcome to drop your thoughts and suggestions below.
34 comments
David
I’m not from a web developer background but find inconsistent use of terminology to be confusing. This was an enlightening article.
DK123
Now I can’t get
“content-zone”
out of my head as a default candidate – inspired by how you have already defined and used it here:
https://automaticcss.com/docs/content-grid/
/* . . . . . START QUOTE . . . . . */
YOUR CONTENT GRID
By default, your Content Grid will establish four content zones:
1. Content
2. Feature
3. Feature Max
4. Full
Content Zone
The Content Zone is the main content channel, centered within your Content Grid just like a section centers content using an inner wrapper.
>>>>>The default width of the content zone is your website’s content width: var(–content-width).<<<<>>>>Content Zone by default<<<<<.
/* . . . . . END QUOTE . . . . . */
Zack
There isn’t much point to labeling something as “div” or “block” if there is a selector in the builder where you can simply change it to a span or some other spec element. It’s not a div if you change it to “article” or “aside” or list items.
I propose something more simplified such as “element” which doesn’t represent any one thing, but is simply a way to select any HTML spec element. Semantically, a developer should know when they want to do a or an or whatever it might be, and some of these are naturally block and some inline, so calling them div or block doesn’t make sense. I’d rather just have something called “HTML element” and then choose which I want.
Then, I could “pin” or just have a list of common ones like a div or list or whatever.
There are so many contextually and semantically valid HTML elements that never get used because page builders just don’t have them. How many page builders let you do a ? Or a ? Or a ? They just don’t exist.
In some builders, you can add a div and perhaps change its tag with a few preselected options, but it’s not a free for all unless it lets you create a “custom tag”.
HTML spec allows custom elements, so we need that option too. One single element called “HTML element” and then you choose from all the spec elements or set your own custom one.
This way, things like a div or list items or definition lists or tables are simply preconfigured html elements or components with the tag(s) already set and perhaps a few default options/styles and parent>child relationships created for them.
I am a fan of the builder letting me do anything possible in the standard HTML and CSS spec.
Jim Hummel
I completely agree that there needs to be common lexicon. While wearing my SEO hat, I work with various pagebuilders and the lack of consistency is frustrating. As I grew into a developer role, the convoluted terminology was confusing to me even though I had plenty of practical experience.
This is readily evident when reading pleas for help in various Facebook groups. Some of the responsibility falls on a lack of education but it’s difficult to offer assistance when the terminology is easily misinterpreted.
Kudos, Kevin, for taking a stand, speaking out and driving the conversation.
Isaura
The Container one is a tough one! The first div inside a Section tend to do that: contain the content. So Container seems accurate. But then Container queries enter to the game… And Container Div? As you have Flex Div? Not sure. As I am not 100% sold on Shell, either. But it may grow as a standard. As said, it is a tough one! Good job, though, taking care of that level of detail for Etch! 🙂
Tom
Glad to see this type of thought going into Etch it is very important.
For most of your suggestions I agree with. Here are a few I have further thoughts/suggestions for:
Container / Shell => Frame
Not a huge fan of shell. To be honest Frame makes better sense to me (though not perfect). Obviously you already have a Frames Product and use the term Frame in that to describe a Pattern but I assume at some point you will change at least the concept of a frame into a pattern.
Basic Text / Rich Text => Text
Just have an element called Text that can have the wrapper turned on or off. Turing the wrapper on and setting it to div allows the content of Text to be wrapped if needed (like a Rich Text). Else if not needed the Rich Text doesn’t have to be wrapped by the element since it is most likely already wrapped by a parent element. If it is just “basic text” then the user can enable the wrapper and select p (and use the content editor of the element to insert spans if needed)
Components
You don’t directly mention it but Components should be able to contain other components. In Bricks they have a section template which you can use the template element. I assume this type of more basic functionality you would just use a Component for.
Patterns
Should have the ability to be made up of Elements and Components (maybe even templates or even other Patterns (not sure here)).
I assume Frames will be moving to Patterns (at least in Etch) and not being able to better manage/maintain/scale Patterns for those who have a default set of patterns by being able to reuse them on new websites creates a lot more maintenance. For example maintaining the pattern library itself that uses the same component in different patterns or by having to recreate parts of patterns into components every time that you import a pattern (especially if that component was already used on the site somewhere else. When imported it would be the same component (and the website would recognize this and not create a new component that is exactly the same) but maybe with different settings.
Themes
Your definition of a theme makes sense but WordPress has been using Themes to describe not just the design and layout but architecture for a while now (not that we should continue this bad behaviour). Another alternative here could be Scheme but then that just refers to colors IMO so maybe not…
Blueprints / Package
If themes is going to be used to describe the design an layout but not architecture. How do we describe the old description of a theme (and even expand on its use)? Blueprint could work here.
Cases for this use would be like the new Guide you are developing for the inner circle. You plan to package this up for inner circle users. This package (or Blueprint) needs to contain pages, templates, CPTs, custom fields, taxonomies, etc… and even posts with content. Blueprints could also have requirements before installing like this version of WordPress, Etch, and even third party plugins (though they wouldn’t get setup)
Variants / Schemes / Presets
Should we define these as well and how they are used? Variants is usually used with components to describe different versions. Scheme is used when relating to just color changes… like light and dark mode. Could elements, templates, components have different variants / schemes / presets / Versions?
zack
“Package” makes sense as a general term that encompasses everything. Even bundled plugins, code, sets of things, styles, pre-configured content, architectures (CPTS and templates), etc. What else could package mean except like a zip file filled with every kind of thing?
But package is a boring word. Nobody wants to browse the “package store” for a new website design, look and feel. But browsing the “theme store” sounds much better.
So “theme” could be used for a package that contains a bit of everything, just like how WP does it now. It would contain the style, components, architecture, content, controls, plugins, templates, CPTs, components, etc. Ready to go out of the box.
Whether called a theme or package, it still has to bundle everything.
Nobody wants to have to buy both a general framework “system” and also obtain separately something called a theme or design that styles it.
I like that the two things are separate because it means you keep your architecture, and replace the design/theme to get a different look and options.
But if you can’t ever replace a design without also replacing the tightly connected architecture, what’s the point? Just keep calling it a theme because it sounds better than “package”.
In summary, package is a great word for a bundle of everything, it’s just ugly to say. Besides, you don’t ever want to be caught asking your friends if they’ve seen your package!
Kevin Geary
Great feedback, thx.
Andreas
There is a problem with the link for the phrase “atomic design principles” because it redirects to Elementor Library.
Kevin Geary
Fixed, thx.
Rob Custers
I feel the appropriate term for a container is “box”. You put stuff in a box. A box can have a shadow. A box can be modelled. A box can contain other boxes. It could be a flex box. Box makes the most sense to me.
Kevin Geary
But that doesn’t distinguish the fact that it’s supposed to be content width and center aligned by default.
Rob Custers
Then wouldn’t we look back to print design. Other terms that suit would be “spread.” A spread determines how 2 pages look combined. A spread would contain headlines, text, images, etc.. multiple spreads make up magazine articles over a number of pages. Centre spread, full spread.
Or another word could simply be “layout.” As the layout determines the look for that section.
Vasco Egthuijsen
The elements can be referred to as “elements” or “nodes,” as that’s what they technically are. However, “elements” sounds better.
For consistency, I would name it “div (flex)” rather than “Flex div”. Also, mention the lowercase naming convention, as it’s considered best practice in HTML.
Instead of referring to a “container element,” simply stick with div — since that’s what it is. However, I do see potential issues with automatically applied classes for content width and similar styling.
There is no specific “row” element in HTML, so just use a div. The user should apply the appropriate styling.
For text, I’d suggest creating an element called “paragraph”, which can be converted into other tags like
Vasco Egthuijsen
Whoops, the HTML tags aren’t being escaped.
Kevin Geary
They’re in inline code blocks. I don’t include the brackets on purpose.
Simone Carè
Thank you for sharing your thoughts on this topic! I’ve been reflecting on these challenges, and I’d like to share my perspective on naming conventions for common elements in web design and page builders. Here’s how I would approach it:
Block → “Element” – Aligning with standard HTML terminology to avoid confusion with other definitions.
Section → “Section” – A semantically accurate term to represent a logical portion of HTML content.
Container → “Container” – A term reserved for elements that define content width and layout, distinct from a “Wrapper.”
Gutter → “Gap” – For the spacing between columns, clearly separate from internal Padding.
Columns→ “Grid Columns” – To explicitly refer to layout grids, with internal spacing managed through Padding.
Text/Basic Text/Rich Text → “Text Block” – A unified term for a text container, regardless of its complexity.
Button → “Button” – A universally recognized and semantically clear choice, consistent across HTML and design systems.
Templates → “Page Template” – Referring to complete page layouts, rather than fragments or reusable components.
Components → “Component” – A standard term for reusable design elements, following best practices.
Patterns → “UI Pattern” – For repeatable user interface models, differentiated from individual components.
Themes – Style → “Style Theme” – Focused exclusively on visual aspects, such as colors, typography, and global spacing.
Themes – Layout → “Layout Theme” – Referring to pre-defined structural and layout configurations, such as grids or section arrangements.
I believe this naming approach can help create clear distinctions between structural, visual, and reusable elements, but I’d love to hear other perspectives on this topic. 😊
Kevin Geary
Gutter is still needed.
Mark LaRiviere
Isn’t “container” simply shorthand for “container block,” which is already well-defined in the CSS3 specification? Here is a brief version of the definition as found on w3.org:
A rectangle that forms the basis of sizing and positioning for the boxes associated with it. Notably, a containing block is not a box (it is a rectangle); however, it is often derived from the dimensions of a box.
https://www.w3.org/TR/css-display-3/#containing-block
Kevin Geary
What is a container block? There’s no such thing. All references to “container” refer to
@containerfor container queries.Shukhrat
Thank you for the great article. It’s much clearer now to understand how to structure this information, even for myself, and how to perceive these concepts.
Greenshift team is currently working on a New “theme” which will be clean “block theme” for WordPress that will remove most of default styles and, along with Greenlight elements, allow the use of pure HTML elements in Gutenberg, with a class system, data-atrributes, variables, and JS interaction layers.
Tyree Brown
I also immediately thought of Frames haha. I appreciate you holding to the standard you’re calling for. I love the clarity and even asking for others to give input. Super productive post.
Jérémy Franck
Hear, hear.
But that container one is a though nut to crack — no pun intended.
And then again, perhaps it’s just force of habit to use shell — I mean, we “paint” pages and “crawl” the web and no one bats an eye, so perhaps in a few years a “shell” or whatever other terminology may emerge will feel completely obvious to use?
Kevin Geary
Yeah, I think the “obviousness” comes from general use. So it might seem like a strange term out of the gate, but it will “fit” after not too long. And it’s unlikely to ever clash with anything.
Dan Stanley
I totally agree to all written.
And I would to see a more simplified and webdeveloper correct naming convention used.
Remove those not needed at all, like flex.
Iv been thru most of the builders outthere and they all have their own different take on it.
By the way I hate Widgets 🙂
Kevin Geary
Death to widgets.
Rob DeHaven
I worked for a company that used UML (unified modeling language) to map out very complex workflows for companies like Boeing. I went through their training to learn how to use the software and disciplines to accomplish these mapping tasks. The very first task to complete was identifying all the lexicon that was used in the process and then determining if it was common across the entire process. Without consistent terms, chaos ensues and the workflow would reach bottlenecks, dead ends, or worse yet, skip things because of confusion. We found most people would adapt to the new terms quickly as long as they were clearly defined and consistent across the entire company. It was our job to identify all the terms, gather the stakeholders, and let them determine the final terms. This was sometimes the hardest part of the process and would result in many hours of arguments. It was like going to a marriage counselor so there was a mediator to keep things civil and productive. WordPress being open sourced has its challenges, but if everyone could agree to adopt a common lexicon it would propel the product to the next level.
Kevin Geary
Agreed!
Simon Logan
“Container” >>> “Wrapper”???
Kevin Geary
Can’t do that because “wrapper” is used quite often in generic grouping contexts.
Tudor Stan
I love the call for consistency, but I’m not sold on shell either. Honestly I think container is fine as long as we vouch to only use container to describe “divs with a contained inline-size or block-size”. Practically, container queries wouldn’t create confusion with this naming. They’d actually align with it because container queries are essentially divs you define and name in order to track their inline-size or block-size.
Kevin Geary
Sure, but I foresee the use of a “container” element in visual builders in the future that exists for the sole purpose of establishing a container query. This would conflict. Also, container queries are designed to be for any inline-size where as the current “container” element is content-width.
Tudor Stan
Wow, ok! I can get behind that vision. Using a “container” to establish a container query automatically is definitely cool.
I guess my biggest problem with Shell is that it defines an outer layer, while I always thought of the Container as definitionally Inner to the Section.
I would find a name that would describe what the Container does like “Limiter”, “Content div” (cause its width is the content width of the website) or where it is like “Inner Section”, “Inner div” or “Inside”, more intuitive than shell.
Some of these names would also feel more cohesive with the “Flex div” you proposed.
Kevin Geary
Someone else voted for “Inner” also. I think that’s a good name.