_{—Part of CSS Primer for the AI Era — Foundations}

CSS never starts from nothing.
It always begins with a
'document that already has meaning'.

That meaning lives in HTML.

If we think of CSS as the way things look and behave visually,
HTML is the way things actually are —
headings, paragraphs, lists, buttons, links, sections.

In the AI era, our conversations about CSS only make sense
if we first understand what the document is trying to say.

HTML is a language for describing structure and intent:

• a heading
• a paragraph
• a list of items
• a navigation area
• a button that does something
• an image that illustrates something

None of this is about color, spacing, or layout.
It’s about what the content represents.

CSS comes later
and answers a different question:

“Given this meaning 
— understood by both humans and data readers — 
how should it appear to humans?”

AI often blurs this line.
Our job is to keep it clear.

When the browser reads HTML, it doesn’t keep the file as text.
It constructs a DOM —
a tree of nodes representing the structure of the document.

This tree is the browser’s understanding of the content:

• parent and child relationships
• block and inline semantics
• headings, paragraphs, lists, and controls
• the order in which things appear

CSS never styles the HTML file itself.
It styles the DOM —
the tree that the browser constructs from an HTML file.

This is the foundation for everything in CSS:
flow, inheritance, specificity, layout.

HTML elements carry meaning,
and that meaning comes with default behavior:

• Headings are block-level and define structure.
• Paragraphs are block-level and separate ideas.
• Lists stack items vertically.
• Links are inline and interactive.
• Buttons are controls with built‑in accessibility.

CSS doesn’t invent these behaviors.
It follows them.
It never talks to the HTML file directly.
It talks to this tree, the DOM.

When AI chooses the wrong element,
CSS ends up fighting the document
instead of working with it.

A few quiet examples:

• A <section> and a <div> may look identical with CSS,
  but only <section> carries structural meaning.
• A <button> and a clickable <div> can both respond to clicks,
  but only <button> behaves correctly for keyboard users.
• A <ul> with <li> items is already a vertical list;
  CSS simply styles what is already true.

Meaning first.
Appearance second.

This order keeps CSS simple, calm and predictable.

AI often treats HTML as interchangeable tags.
We can guide it toward meaning with gentle, precise cues:

• “Use a <button> here — it’s an action, not navigation.”
• “Wrap this group in a <section> with a heading.”
• “Use a <nav> element for the main navigation.”
• “Represent this as a <ul> with <li> items, not separate <div>s.”
• “Keep links as <a> elements when they navigate.”

We’re not just correcting tags.
We’re teaching AI
to respect the structure CSS depends on.

The 'Foundations' topic is about how CSS behaves.

By starting with semantics, we:

• give CSS a stable foundation
• give AI a clearer structure to work with
• give ourselves a shared vocabulary for the rest of the Primer

From here, when we talk about:

• normal flow
• block vs inline
• the cascade
• inheritance
• context

…we’re always talking about
how CSS responds
to the meaning already present
in the document.

HTML expresses meaning to humans.
CSS is the visual skin placed on top of that meaning —
but it has its own rules of presentation we must follow.

Our role is to keep the meaning clear
so the styling — and the collaboration — stays grounded.

Everything else in Foundations builds on this.

• Suggested Next Reading: How CSS Thinks

_{Tony de Araujo —New York | Lisbon}

• Top↑
• Back to Topic ↔
• Home←