“An” is an article in an article about article design and semantics

Welcome. If you happened on this article in search of a spritely read—sorry, it isn’t. I created this article as a reference and a proving ground for my design teams when building article designs and design systems. I hope it’s helpful.

The text editor UI that your company uses provides a collection of standard formatting options, such as headings, paragraph text, blockquotes, bold, and italic. Those formats correspond to HTML content elements. The title (main headline) of an article, for example, is most likely formatted as Heading 1. If you view the HTML source code in your text editor or browser, you’ll see that Heading 1 content is wrapped in an <h1> HTML tag.

As designers, we build design patterns in Figma, which enables us to approach design in a platform-agnostic way, relying on a beloved colleague from Engineering—we’ll call her Effie—to make the connections between design and code. That does not absolve our responsibility for understanding the meaning of the material nor our role in optimizing the authoring and production processes.

Text editors are not platform-agnostic. They output content as HTML elements. HTML tags impart meaning about the structure, purpose, and importance of the content they enclose. As a designer, you’re responsible for the way the design looks, how it behaves, and the meaning implied by your choices.

Taking a higher level of ownership is a win for everyone. In doing so, you will:

• Enable great storytelling
• Collaborate more effectively with Content and Engineering
• Optimize the writing and production process for authors
• Build more purposeful design systems
• Unlock greater accessibility
• Create reliable hooks to simplify downstream publishing
• Elevate brand and QA through more predicitable design outcomes

In this article, I’ll cover what I feel are the basic semantic needs of an article design and help you anticipate a few common, reasonable wants not addressed in text editors. Our objective is to make the easiest path for an author to produce the best design outcomes and semantically accurate content.

Assess style needs

Create a spreadsheet. Inventory content elements that may appear in your design. Include all formatting options available in your text editor. Add any content elements that arise during your collaborations and design process.

Add a column called “Shared styles,” where you can note multiple content elements that share the same attributes. This column will help economize your design and avoid sprawl. Each content element will not require a distinct style or design token. An instance of a your serif font sized to 20px may be used in several styles.

Here are some content elements for your list:

Block-level elements

In HTML block layout, content elements are laid out—well—like blocks, one on top of the other vertically. The block encompasses the entire element from top to bottom, side to side. A style applied to a block affects all of the content within the block (unless overridden by an inline style, which we’ll discuss shortly).

Paragraph text element

Paragraph text is your most important design consideration, worthy of gobs of time and attention. It’s the body text of the article and the default format in most text editors. Each paragraph is wrapped in a <p> tag in HTML. Semantically, it’s pretty straightforward.

The styling of paragraph text, however, includes a designer’s most consequential decisions. Paragraph text is the heart and soul of an article. All of the baked-in virtues and flaws are compounded in every word, every paragraph, every article.

Focus on two things: typeface choice and implementation. Together, these choices affect:

• Legibility and readability.
• Accessibility for visually impaired and neurodiverse readers.
• Brand expression—personality, voice, tone, and vibe.
• Perception of value, trust, and authority.

Start with thoughtful selection of your body text typeface. Here’s an example process you can consider.

Font size: Relatively larger body text improves readability, value perception, and cognitive ease (all of your readers are not 28 years old). Be careful not to go so big that your lines of text break awkwardly on mobile screens. Perhaps you’ll decide to increase body text size at wider screen widths. If so, you’ll need more than one typography token to address body text size.

Line height. Standard ratio of line height to body text size is 1.5, but every typeface is different. Choose what works best for you. Tight spacing creates problems for readers with vision impairments. It also increases cognitive difficulty, forcing readers to work harder to maintain their place.

Letter spacing. There is no standard measure for letter spacing. Start at zero and adjust as needed. Your brain recognizes the space within and around characters just as much as the shape of the character. Add just enough spacing to retain distinct shapes between characters. But don’t add too much space. Excess space hurts recognition and readability.

Mind your arcs. Consider one of your fonts, let’s say your sans serif font at regular weight. Create a lineup of that font showing all sizes in your design. Note the line height and letter spacing for each size. As font size increases, line height ratios and letter-spacing should decrease. You should see a smooth progression in your values. If not, you probably have some one-off issues.

Line length. Pay attention to the number of characters per line, which is a product of body text size and column width. Read about optimal ranges for a comfortable reading experience here, here, and here.

Pseudo classes

Your body text design should address style for hyperlinks in different states, called user action pseudo-classes. These classes include link, hover, active, visited, and focus. Your critical decisions for pseudo-classes are text colors, underline style, and interactivity feedback pattern.

For optimal readability, color for hyperlinks should adhere to the “smallest effective difference” philosophy—just different enough from body text to be clearly distinguished but close enough to ensure smooth reading (stark color differences cause eye jitter). Underlines should be noticeable, but not distracting.

Signify hyperlinks in two ways, in keeping with WCAG 2.1 accessibility best practices: color change and underline.

Don’t one-off your designs for body text pseudo-classes. Establish a consistent UI pattern for interactivity and feedback across your products.

Hover state is irrelevant on mobile devices but important on desktop.

Most publishers no longer style visited state in a distinct way. It relies on cookies to know if a URL has been visited by your computer. The level of complication and potential confusion outweighs the benefit, but be careful who you say that to. Purists will fight you.

Section heading elements

Headings describe, organize, and add hierarchy to article content. Search engines use heading tags to understand a page’s structure and content. Most text editors (not all) include six formatting options for headings. The formats correspond to HTML elements <h1>, <h2>, <h3>, <h4>, <h5>, <h6>. Your design should include specs for all of them.

These headings are used to make this article (links to examples included on this page):

• Heading 1. Also known as the title or main headline, it is assigned an <h1> tag. Only one H1 per article, please. (Example: “An” is an article in an article about articles design and semantics)
• Heading 2. This is the main subheading tagged as <h2>. (Example: Section heading elements)
• Heading 3. Less prominent than Heading 2, this heading is assigned an <h3> tag and is used for smaller text breaks. Heading 3 content is generally considered to be a child of Heading 2. (Example: Heading classes)
• Headings 4, 5, and 6. I don’t use them in this design, but I include them in my design spec nonetheless.

Your design should spec treatments for all heading formats offered in your text editor, even if you don’t use them. If a format appears in the editor, assume someone will use it. If your style code doesn’t account for Heading 5, your readers will get a blast of default Georgia.

Heading classes

You can assign only one style to a heading in your text editor. However, you can create aditional HTML classes of those elements to achieve different looks. These classes can be added to your design but will not show up in your text editor without effort from Engineering. In this design, I included three <H2> classes and one <H4> class (links to examples included):

• Heading 2-topic label. A simple label, a gadget to add context, description, or personality to an article. (Example: Article semantics)
• Heading 2-article description. This heading provides search engines with descriptive information about the article and may be used to generate snippets. More importantly, description headings are inferred by readers as comforting organizational components and concierge service that increases the perception of your brand. I call this class dek, which is an old newspaper term that describes its placement below the main headline. (Example)
• Heading 2-chapter heading. In long-form articles, chapter headings mark major thematic shifts in content. Chapter headings also add hierarchy, helping to organize content in articles like this one. (Example: Block-level elements)
• Heading 4-label-default. I use this class to make label boxes. (Example: Pros and cons)

You may be tempted to cleverly exploit an unused heading slot in your text editor, where you can slide your sharp new heading class. Technically, there is no reason why you cannot do that, but don’t. Each heading implies a level of importance. Best practice is to use classes for presentational distinctions.

List elements

Most text editors offer two formatting options for list elements:

• Ordered list, the one with the numbers. Choosing this format implies that the order or ranking of list items is important. Ordered list is tagged with <ol>.
• Unordered list, the one with the bullets, implies that the order or ranking of list items is not important. Unordered list is tagged with <ul>.

Each list type is a wrapper that determines the format of the enclosed list item elements. List items are tagged with <li>.

Designing lists can be as simple or complex as you make it. I prefer simple. Your big decisions are:

• Typeface selection
• Spacing, including the size of the list indent, the gap between the numbers/bullets and the list items, vertical spacing between list items, and spacing above and below the list.
• Bullet style. You can stick with the defaults (as I do), choose different bullet or numeral style, or design your own.
• Treatment of lists nested within lists.

Here’s an example of an unordered list—Artists featured in Ninth Street Women, by Mary Gabriel:

• Lee Krasner
• Elaine de Kooning
• Grace Hartigan
• Joan Mitchell
• Helen Frankenthaler

Here’s an example of an ordered list—the evolution of Robert Motherwell’s Elegy to the Spanish Republic No. 132.

1. Begun in 1975, originally based on the composition of an earlier, small-scale work, Spanish Elegy with Orange No. 3. The first version contained areas of orange, like the small picture on which it was modeled.
2. Made structural revisions and repainted it entirely in black and white in 1975.
3. Major revisions again in 1976 and 1977.
4. Added large areas of pink and yellow ochre in 1983.
5. Painted over the pink areas with ochre, as seen in the final image.

One more: Description list element

This list implies a relationship in the pairing of term and description. You won’t find description list in most text editors. So why do I include them here? Stubbornness, I suppose. Description lists are standard HTML elements that are undervalued and underused. If the pattern is a good fit for your content, description list is a worthy workaround addition to your text editor.

Description lists are tagged with <dl> (the list type), <dt> (description list term), and <dd> (description).

Here’s an example of a description list—Abstract Expressionism terminology:

Automatism

Subconscious drawing in which the artist allows his unconscious mind to take control.

Gesturalism

Method of painting characterized by energetic, expressive brushstrokes deliberately emphasizing the sweep of the painter’s arm or movement of the hand.

Action painting

Highly-charged, impulsive style of abstract gestural painting during which paint is energetically splashed, spilled, or dribbled onto a canvas, usually placed face-up on the floor.

Although I believe description list should be standard, and that you should solve for it in your design, don’t pound your fist about it. Making description lists available to authors is one of those workarounds we discussed earlier.

I use a couple of list classes in this design. The links in the header and footer of this page are formatted as lists and styled so they appear inline, without decoration (no numbers or bullets). In this case, the additional class does not affect workflow and does not appear in text editors. It’s coded once, included on the page template, and it’s semantically correct.

Content that is a list should be designed and coded as a list. Example: Assistive readers will prep users, announcing to them that the information about to be read is a list of items.

Images and captions

Most text editors include the ability to insert images into an article. Approaches vary. Placing images using the text editor UI can be a clunky experience. Effie from Engineering and her team may instead provide authors a reusable component or custom block, including fields to add a caption and image credit. As a designer, you needn’t worry too much about that.

It may be helpful, however, to understand how image and caption are typically structured in HTML, so you can visualize the relationships.

• Let’s start with the figure element. The figure element is a wrapper containing the content associated with an image, such as the image and caption. Figure is tagged as <figure> in HTML.
• The image, called the image embed element, is nested within. The image is tagged as <img> in HTML.
• The caption, called the figcaption element is also nested within <figure>. The caption is tagged as <figcaption> in HTML.
• Oddly, there is no HTML element for an image credit, and your text editor probably doesn’t include a formatting option for it, hence the reusable component. Typically, a credit is placed within the caption element using span tags in HTML, so they can be targeted for styling.

There’s a lot more we could cover about image structure, but we won’t. You can partner with your Effie for more. What you’ll need to consider as the designer:

• Sizing the image reliably, which means responsively.
• Spacing around and within your captions.
• Typography for caption. As with body text, you’ll need to supply inline style and pseudo class specs.
• Typography and placement for the image credit. You should align with Effie from Engineering about how captions and credits will be structured.
• Image border? Probably not, but it’s a decision to be made.

Captions should not be treated as tertiary reference information. Captions are high-interest, go-to content. Expect them to be read. Consider readability as you would with body text. Attribution, however, can be thought of as user-facing meta data.

If body text and captions are too similar, it can cause confusion and usability issues for readers as they transition from one to the other. Spacing and typeface change are common tactics.

Images and captions are not immune from accessibility requirements. Visually, your caption typography should achieve AAA color contrast ratios, just like your body text. Authors should include alt text when inserting an image. Why am I telling you? As the experience designer, I call upon you to advocate for best accessibility practices.

Important: Learn how to size images responsively using percentages, min-width, and max-width. They’re your new best friends. Avoid the QA nightmares associated with fixed-width design.

Block quotation element

Everyone loves a blockquote. The blockquote element is a wrapper that encloses a quotation and an optional citation. Citation is not required and, in fact, some text editors make it dang difficult to add. Blockquotes are tagged as <blockquote> in HTML.

There are two use cases for blockquotes in this design: pull quotes and excerpts.

Pull quote

Pull quote is not an HTML content element. Rather, Pull quote, like dek, is jargon. Some text editors may refer to a blockquote as “Pull quote.” The term describes a familiar use case for blockquotes—a quotation that pops.

Here’s an example of a blockquote styled as a pull quote:

“Abstract art enables the artist to perceive beyond the tangible, to extract the infinite out of the finite. It is the emancipation of the mind.”

—Arshile Gorky

In this design, I uncharacteristically chose an italic typeface for the quotation. Don’t tell on me. I love the effect of the italics in the Portada typeface family; I wanted to leverage those qualities for my brand. However, know that italics are more difficult to read when styling more than a few words. I also added a left vertical border to frame the blockquote wrapper.

Design considerations:

• Point of view. Be thoughtful: Why do you want pull quotes in your article? For beauty? For impact? For an entry point? The answer will guide your design choices.
• Aesthetics. Pull quotes are a fun design task and a signature opportunity to contribute to the voice, vibe, and personality of your brand.
• Layout and spacing: How will you make your pull quote stand out? How prominent do you want it to be?
• Attribution. How will you treat the source of the quotation?

Excerpts

An excerpt, in this design, is a class of blockquote created for a specific purpose—to identify and style content quoted from outside sources. Because excerpts can be long, they are designed to be read like text, not like a larger pull quote.

Your text editor most likely offers a single blockquote format. Another class of blockquote may be required to make what I’m calling an excerpt. That means it’s another instance of a workaround. We’re keeping Effie from Engineering busy. I believe excerpt is a valuable tool in your storytelling toolbox and a worthy use of design and engineering time.

Here’s an example of a blockquote styled as an excerpt:

The The Museum of Modern Art said of Rothko:

Mark Rothko sought to make paintings that would bring people to tears. “I’m interested only in expressing basic human emotions—tragedy, ecstasy, doom, and so on,” he declared. “And the fact that a lot of people break down and cry when confronted with my pictures shows that I can communicate those basic human emotions….If you…are moved only by their color relationships, then you miss the point.”

Like his fellow New York School painters Barnett Newman and Clyfford Still, Rothko painted to plumb the depths of himself and the human condition. For him, art was a profound form of communication, and art making was a moral act.

Design considerations:

• It’s a good practice to include a citation and link to the source of the excerpt.
• Excerpts are typography challenges. The design should signal that the material reads within the flow of the article but not native to the article. Tricky.

Pull quotes are good things that can become bad things. They can be overused design gadgets that intrude on your narrative. Use pull quotes sparingly.

Good candidates for pull quotes are less than 50 words and chosen for impact. Careful, they can get real big, real fast. This is a good use of coaching and collaboration with Content.

Inline body-text elements

Inline elements override block-level style and are usually applied to portions of a block.

Common text editor inline formats

Strong and Emphasis

Strong and emphasis impart meaning on content, telling browsers, text-to-speech engines, and screen readers how we want words to be read and inferred.

Tagging content as strong (<strong>) implies that it is of great importance, seriousness, or urgency. Applying the emphasis element (<em>) implies a stressed emphasis relative to surrounding text.

Bold and Italic

Styling affordances for bold and italic are available in most text editors. Bold and italic are presentational tags; they change appearance but do not impart any meaning. These styles are accomplished with <b> and <i> tags.

By default, a font-weight of 700 is applied to achieve strong and bold. Italic font style is applied to achieve emphasis and italic.

You can change default styles in your design and style code if you like, but be cautious. Strong, bold, emphasis, and italic are heuristics; readers intuit the meaning attached to the design convention. Sometimes, when working with certain font families, I will override the default 700 font weight assigned to strong and bold and replace it with a semibold weight of 600 if I feel the pairing is better. Yup, I can get crazy.

Inline code

Content can be presented as code (<code>) fragments. Here is an example. The browser-default result is a monospace font that resembles computer code with no color background. In this design, I add a light blue background behind code instances.

The default monospace font that is used to render inline code fragments is determined by your browser. Defaults differ among browsers. You can specify a consistent font of your choosing in your style code, maybe an available system font you like or a custom font you license. If your brand doesn’t insert many code fragments in your content, stick with the defaults and avoid an additional font load. If you write lots of tech articles, it may be worthwhile to invest in a monospace font that adds to your voice and brand.

Anchors

The anchor element, when combined with an href attribute and a URL, creates a hyperlink. This is an example. By default, a hyperlink receives an underline. You can adjust the look of the underlines in your style code. You can even eliminate them, allowing a change in text color to serve as your sole signifier of a hyperlink, but don’t do that. As noted earlier, hyperlink underlines are a useful accessibility best practice.

We discussed styling considerations for hyperlinks earlier.

“Underlines”

The format that’s called “underline” in text editors is a weird case. This is an example.

In the 1990s, <u> meant underline, a purely presentational markup devoid of meaning. It was just an underline. For that reason, the element was deprecated in 1997 with the release of HTML4. Like bad TV writing, the <u> tag reemerged in HTML5 with a new identity: unarticulated annotation. Same tag, new meaning. The tag now implies that there is some additional meaning or context associated with the tagged content (but that meaning is not stated). The <u> tag is also used in Chinese to denote proper nouns.

Underline still appears in most text editors, baiting authors to engage unknowingly in improper semantics to achieve a presentational effect. Shame, shame, shame. Encourage authors to abstain from <u> when the objective is purely presentational. If the intention is to add strength or emphasis, encourage them to use <strong> or <em>.

There’s also the obvious usability problems: An underline might be mistaken by a user for an anchor link until—tap-tap-tap—they realize it isn’t.

Strikethrough

The strikethrough element, <s>, denotes information that is not correct.

Accept browser-default styling for strikethrough (<s>). No need to include it in your design spec or tokens. The default is fine.

Superscript and Subscript

If you want to cite the Pythagorean theorem (a² + b² = c²) or the chemical expression of an orange pigment (C₁₆H₁₀N₄O₅), these styles are for you. These styles are accomplished with <sup> and <sub> tags.

Perhaps I’m being overly precious, but I augment browser default styling for the subscript (<sub>) and superscript (<sup>) elements. Their defaults insert awkward line spacing to body text, so I add one line of code to my CSS to adjust the line-height a tiny bit.

Uncommon text editor inline formats

Most text editors do not offer formats for the following content elements, but I suggest adding them to your design and style code anyway. You never know when an adept staff writer, freelancer, guest columnist, or wire service will post an article with proper HTML tagging.

Marked (highlighted) text

Noteworthy content can be highlighted using the mark text element (<mark>). Here is an example. Some text editors offer a “highlight” format, which enables you to change the color of the text. The more semantically correct mark element changes the background color behind the text. By default, browsers apply an intense yellow background color to marked text. I change the color to a less intense yellow.

Citations

Citations are used to denote the titles of works of creative, such as Eastside Peddler by Grace Hartigan, 1956. Citations are made using the <cite> tag. By default, browsers italicize citations.

Small Text

Small print, side comments, and legal notes can be shown with the <small> tag, which, by default, is one font-size smaller than paragraph text. This is what small print text looks like. It’s a subtle but noticeable difference.

Inline quote

Quotes made with the <q> tag are inline styles. If you can’t find your inspiration by walking around the block one time, go around two blocks—but never three. —Robert Motherwell. By default, inline quotes are italicized, but you can design them any way you want.

Beware a design pitfall of the inline quote. Because it’s a quotation, you may be tempted to go overboard with your styling in an attempt to replicate a blockquote effect. Keep it simple.

Impostor elements

These are legitimate content elements that are used mostly during the editing process and not typically end-user facing. These elements are uncommon in text editors but relevant if you are designing a business-user experience for authors. I call them imposter elements because, from a design point of view, their default styling mimics other elements:

• The inserted element, <ins>, applies meaning: The underlined content has been added to a document, perhaps during an editing process. This is an example. It looks like underline.
• The deleted element, <del>, identifies content that has been removed from a document. It looks like strikethrough.

Thank you

That’s enough for today. There is so much more—video and social embeds, tables, footnotes, comment threads. But I’ve given you enough to keep you busy. I hope this has been helpful.