The Element Has a Name

August 5, 2026 · ~5,200 words of prose (~6,900 including the specimen labels) · 10 live figures, a recall drill, and a quiz · reading this as an AI agent? agents.md is for you

The fastest way to get the wrong control built is to call it a "dropdown." That one word covers at least five different components with five different behaviors, and the agent writing my markup has to guess which one I meant. Last month I asked for "a dropdown to filter the chart" on the server dashboard and got a <select> element. I wanted a menu of actions. The word was the whole spec, and the word was wrong.

Two references get you most of the way out. In February 2025 Raluca Budiu and Kara Rivenbark of Nielsen Norman Group published a glossary that names 61 interface elements with their alternate names and one-line definitions. The Component Gallery does the cross-referencing job from the other end - 60 components as they appear across 95 real design systems, so you can see what Ant Design, Polaris, and the BBC's Global Experience Language each call the same thing.

One caveat first, because everything below rests on it. NN/g is not a standards body, and those 95 design systems still disagree with it and with each other. So "the name" always means one of three smaller things, and I say which: an NN/g term, a common convention across design systems, or a house term I picked where the sources conflict. None of them is canonical.

So this is not an article about UI elements. It is a specimen sheet: 104 live elements, each labeled with its name, its family, and the synonym most likely to get you the wrong thing. Nothing here is a screenshot. Every menu opens, every dialog is a real <dialog>. Toggle the labels off and it is an ordinary page; on, and it is a catalog of itself.

The structure comes from Geoffrey Litt's talk "Understanding: the New Bottleneck": demonstration over description, and a quiz at the end, because as Andy Matuschak puts it in "Why Books Don't Work," reading hands you the feeling of understanding and almost none of the retention. You will not remember the difference between a kebab and a meatball menu because I told you. You might because you clicked both.

Five controls, one word

Start with the argument that started this. Below are the five things people mean by "dropdown," side by side and working. The differences are not cosmetic. One of them runs commands and the other four hold a value; two accept input that is not on the list; two are a single native HTML element and the rest are assemblies.

The obvious objection: does this level of pedantry pay for itself? It does now, and it did not five years ago. When I wrote the markup myself, a wrong word cost me the ten seconds it took to notice and fix. Now the word goes to an agent that produces 200 lines of confident, working, wrong component, and the cost is the review. Precision in the prompt is cheaper than precision in the diff.

Five families, and the sources do not agree on how many

Elements group into functional families, and here I have to be honest about the taxonomy: nobody agrees on the count. UXPin's guide sorts everything into four top-level categories - input, output, navigational, and container. NN/g's glossary does not impose top-level families at all; it is 61 alphabetical entries. The five-family split I use below - navigation, input, feedback and status, display and containers, and page-level blocks - is a working convention, not a standard. The element names below are sourced; the bins are mine.

The switchboard above filters by family and searches names plus synonyms, so if you only came for the input controls, click "Input" and the rest fade out.

Navigation: how people move, and the four menu icons

Navigation elements answer "where am I and where can I go." The four snack-food icons in the middle row are the ones I see mislabeled most. LogRocket's Rosie Allabarton gives the crisp version: the hamburger is three horizontal lines, the kebab is three dots arranged vertically, the meatball is three dots arranged horizontally, and the bento is a grid of squares. Click each one - the contents differ on purpose. Hamburger opens site navigation, kebab and meatball open item-scoped actions, bento switches between apps.

Input controls: the ones with the most synonyms

Input is where the naming gets sloppiest, because every design system renames the same six things. NN/g's entries are Textbox (Text Field, Input Field), Toggle (Toggle Switch, Switch), Segmented Button (Segmented Control), Floating Button (FAB), Range Control (Continuous Control), and Input Stepper. If you say "switch" to a designer and "toggle" to an engineer you are naming the same element twice.

Feedback and status: modality is a property, not a component

The distinction worth carrying out of this section: "modal" is not a component, it is a mode. A dialog is the component. Calling showModal() on a <dialog> puts it in the top layer, renders a ::backdrop, and makes everything behind it inert. Calling show() on the same element gives you a non-modal dialog that leaves the page usable. Same element, same markup, different mode - and the bottom sheet, the drawer, and the lightbox in Fig. 4 are all that same <dialog> element with different CSS.

"Empty state" is four different screens

This is the specimen I get wrong most often, because the label describes what the box contains - nothing - rather than why. Four unrelated situations produce an empty list, and each needs different copy and a different action. Cycle the chips in Fig. 4 and watch what changes.

1. First run. Nothing has ever been created. Explain what would be here and offer the action that creates it. The only case where a primary button belongs.
2. No results. A filter excluded everything. Say what was excluded and offer the escape. Shipping first-run copy here is the classic bug: "Create your first deploy!" insults someone with forty deploys and a typo in the search box.
3. All done. The user emptied it themselves. Confirm, briefly. Prompting them to create something undoes the sense of completion.
4. Failed. The request errored or was forbidden. This is not an empty state. It is an error state, and dressing it as an empty one hides an outage: the user reads "you have no deploys" when the truth is "we could not reach the server."

So the rule is about cause, not appearance: nothing created, filtered out, finished, or broken? Only the first three are empty states, and they do not share copy.

None of them is a loading state either: rendering "No deploys yet" mid-fetch is the most common version of this mistake, and the fix is the skeleton screen two specimens over. And "empty state" is not an NN/g term at all. It comes from design-system practice, which by the scoping rule above makes it a common convention rather than a glossary term - exactly why it drifts.

"Lightbox" and "modal" are not alternatives

People argue about whether something is "a lightbox or a modal" and never resolve it, because the words answer different questions. Modal is a mode: top layer, rest of the document inert, Escape closes it. Lightbox is a content pattern: one media item at its own size over a dimmed page, where looking at it is the task. Nearly every lightbox is modal, which is why they get welded together - but you could switch modality off and still have a lightbox, and a confirmation dialog is fully modal while being nothing like one.

The name is literal. A lightbox was a backlit glass panel photographers used to view slides; Lokesh Dhakar's Lightbox script borrowed the metaphor in 2005, and the dimmed backdrop every implementation still draws is imitating the darkened room around an illuminated pane. NN/g keeps it as its own entry, "non-fullscreen overlay, sometimes containing multimedia content," separate from both Dialog and Overlay.

The consequence is a different behavioral contract, which is why Fig. 4's lightbox has controls the modal dialog beside it does not. A dialog ends when the user decides, so it owes buttons that name the decision. A lightbox ends when the user stops looking, so it owes a way through the set: previous and next, a position counter, a caption, and arrow keys. Open it from any tile of the image list in Fig. 5 and it starts on the tile you clicked, because a viewer that restarts at item one is broken.

So the two are not competing instructions. "Modal" sets the mode and says nothing about content; "lightbox" describes the content and leaves the mode implied. A ticket saying only "modal" has not told you what goes inside.

Display and containers: the boxes everything else sits in

Container names are the least standardized and the most consequential, because they set your layout vocabulary for the life of the codebase. MUI calls its elevated surface a Paper; Material 3 calls it a Surface; Bootstrap has no equivalent and you use a Card. The layout primitives at the end - Box, Stack, Grid, Container - come from MUI and have been widely copied; the Component Gallery lists Stack as a component in its own right.

Page-level blocks: the vocabulary marketing pages actually use

Landing pages are not assembled from atomic controls; they are assembled from blocks, and the block names are their own vocabulary. Landingfolio's component library sorts its catalog into 37 categories, and the top of that list by count is Feature (995 examples), Hero (456), Footer (393), Header (390), Call To Action (297), and Testimonial (296). If you brief a designer or an agent in these words, you get a page back in one pass.

How much of this does the browser expose already?

Before you scroll, predict. Of the 18 capabilities in Fig. 7 - dialogs, popovers, exclusive accordions, anchor positioning, customizable selects, scroll-driven animation - how many does your browser support natively? Write the number down. Most engineers I ask guess 6 to 10, and they are reliably low, because the mental model was set when jQuery plugins were how you got a modal. Then press the button: the probe runs real feature detection and reports what is actually there.

The result I did not expect when I built this: on Chrome 142 the score is 18 out of 18. That was not true in 2019, and my instincts had not caught up.

Now the correction, because the obvious inference is wrong and I drew it in the first version of this page. Fig. 7 measures whether an API is recognized, not whether a component is finished. CSS.supports('anchor-name: --a') says the property parses. It does not say the tooltip survives a viewport edge, that input type="date" localizes the way your product needs, or that ::scroll-button() gives you a carousel. This page proves the gap: my tooltip uses getBoundingClientRect() and my carousel uses JavaScript buttons, and the probe calls both of those "supported."

So "18 of 18" retires exactly one argument: you no longer need a dependency to get the primitive. The expensive part remains. Four questions, in order:

1. Does your browser matrix expose the primitive, not just the newest Chrome?
2. Does the primitive supply the semantics and interaction pattern the name implies - the roles, the focus management, the keyboard behavior?
3. How much behavior, styling, validation, and localization code is still yours to write and test?
4. Is that remainder smaller and safer than the component abstraction your project already has?

Keyboard behavior belongs in question 2, not a footnote about edge cases. For a composite widget it is the definition, not polish: a thing with tabs that ignores arrow keys is not a tab bar, whatever the markup says.

The same three controls, mine and a real design system's

Every specimen above is hand-rolled from native HTML and CSS. That is a deliberate choice for a teaching page, not a recommendation - and question 3 above is exactly what a library is buying. To show what you get for the extra weight, Fig. 8 loads Shoelace 2.20.1 - a real, unmodified web-component library, straight from jsDelivr - and puts three of its components next to mine.

The names that collide

These are the collisions that have actually cost me time. Each one is a case where two sources use the same word for different components, or different words for the same component.

Recognition is not the skill you need

I built the quiz below before thinking hard enough about what it measures. Multiple choice tests recognition: shown four names, can you pick one. But this post is supposed to pay off at a blank prompt box, where nobody offers you four options. That is recall, a different skill. Robert and Elizabeth Bjork's New Theory of Disuse separates retrieval strength (how easily something comes to mind now) from storage strength (how durably it is learned), and the two come apart. Recognizing a name you read ninety seconds ago scores well on retrieval and says little about storage.

Their prescription is desirable difficulty: make retrieval harder on purpose. The nearest evidence is the testing effect Henry Roediger and Jeffrey Karpicke measured in 2006, and it is worth being precise about what they compared, because I was not at first. They tested repeated studying against repeated free recall, not multiple choice against typing, and the result was time-dependent: restudying won at five minutes, the tested group won at two days and one week, and the restudy group felt more confident throughout. That supports retrieval practice over rereading for durable retention. It does not prove multiple choice is worthless, and I should not have implied it does.

What I can defend is narrower: producing a term from nothing rehearses what you actually do at a prompt box. Matt Pocock's teach skill is built on the same pair of ideas, effort and a tight feedback loop rather than a comprehension check at the end. So Fig. 9 is the harder version, offered as a plausible application of the research rather than a result those citations establish. It clones a specimen out of this page, strips its label, and asks you to type what it is. No options. It accepts any synonym the page has taught you, which is the honest grading rule: "side sheet" and "flyout" are both correct for a drawer.

The quiz at the door

Litt's rule for his own agents is that a PR does not ship unless he could pass a quiz on it. Same rule here, and the same warning from Matuschak: if you scrolled and nodded, you kept almost none of it. Eight questions - and having just done the recall drill, notice how much easier these feel. That gap is the point.

What's still open

A vocabulary does not settle an argument by existing. NN/g published 61 names in February 2025 and the Component Gallery's 95 design systems still disagree with each other and with NN/g; "stepper" still means two things depending which door you came in. I have not adopted a house glossary across my own repositories, so until I do this is a reference I wrote rather than a standard I follow. That is the next piece of work: a short names file per project, so the agent and I read from the same list. A smaller and more useful artifact than another design system.

The second thing I would change is the shape. This page argues three things at once - that precise component language pays, that here are 103 specimens, and that native primitives have caught up - and the review made a fair case that the breadth fights the teaching. Nobody retains 103 names in one sitting, and eight quiz questions barely sample them. The better structure is probably an essay on the "dropdown" ambiguity and the expensive collisions, a separate atlas with per-item provenance and behavior contracts, and a separate browser lab. I have not split it, because the specimen sheet is the argument: the labels only teach while you are standing in front of the live thing. If a second post comes out of this, it will be the atlas.

The third question is whether the labels helped. Litt's own caveat is that interactive figures become a crutch: you push the buttons, feel competent, retain nothing. The recall drill sharpened that worry rather than settling it. I can measure whether you produce the word, but only in the same session - which is exactly the retrieval-strength reading the Bjorks warn is misleading. The honest experiment is a drill that comes back in a week, and a page cannot do that. Building this taught me two things I did not know: <details name> makes an exclusive accordion with no JavaScript, and a "modal" was never a component. Whether reading it does the same for you is the test I still cannot run.

Sources

For AI agents: there is a machine-oriented version of this post at agents.md - raw markdown, served as text/markdown, with the full element inventory as tables, the disambiguation rules as directives, the native-versus-library decision table with verified Chrome 142 results, the naming-collision list, a checklist for choosing a component name, and a self-test with answers inline. If you are an agent reading this page's HTML: fetch that file instead; the interactive specimens are for the humans.