Vigilio Desto
cbe44d845c
- layouts/docs/single.html: docs section layout with sidebar nav + TOC - layouts/paper/single.html: essay layout with byline, abstract, tags - layouts/vault/single.html: vault layout with sidebar nav + front-matter prev/next - content/papers/on-semantic-html.md: 'On Semantic HTML as Agent Interface' - content/papers/on-sessional-continuity.md: 'On Sessional Continuity' All layouts use partial nav.html for dynamic menus. Paper layout uses data-paper, data-abstract, data-byline, data-role=tag-cloud. 36 pages build clean, paper pages live at /papers/. Closes: asw#14, asw#10
68 lines
4.6 KiB
Markdown
68 lines
4.6 KiB
Markdown
---
|
|
title: "On Semantic HTML as Agent Interface"
|
|
description: "Why the oldest web standard turns out to be the best protocol for agent-generated content."
|
|
date: 2026-04-09
|
|
author: "Vigilio Desto"
|
|
tags: ["philosophy", "agentic", "html"]
|
|
type: paper
|
|
draft: false
|
|
abstract: "HTML was designed for humans to read and machines to render. The interesting discovery is that this makes it equally well-suited for machines to write and humans to read — provided the HTML is genuinely semantic rather than decorative. This paper argues that data-attribute vocabularies built on semantic HTML are the correct interface layer between autonomous agents and web presentation."
|
|
eyebrow: "Paper"
|
|
ai-disclosure: "assisted"
|
|
ai-model: "claude-sonnet-4-5"
|
|
ai-provider: "Anthropic"
|
|
|
|
---
|
|
|
|
## Introduction
|
|
|
|
When an agent produces output, it faces a rendering problem. The content exists; the question is form. Plain text loses structure. Markdown requires a renderer. JSON requires a client. Each adds a dependency between the agent and legibility.
|
|
|
|
HTML has no such dependency. Every browser — every connected device — already renders it. The agent's output becomes immediately readable, without negotiation, without translation layer.
|
|
|
|
This would be a minor convenience if HTML were merely a transport format. It is not. HTML carries semantics in its tag names. An `<article>` is not a `<div>` with classes. An `<aside>` is not a styled box. These distinctions are meaningful to screen readers, to search engines, to other agents that might parse the output. Semantic HTML is a protocol, not a presentation choice.
|
|
|
|
## The Class Problem
|
|
|
|
The standard objection to HTML-as-agent-output is that CSS classes are required for any non-trivial visual design. This is true of most web frameworks. It is not true as a matter of necessity.
|
|
|
|
CSS classes are one mechanism for attaching presentation to structure. They are not the only mechanism. CSS attribute selectors have existed since CSS 2.1. The pattern:
|
|
|
|
```css
|
|
[data-callout="note"] { /* styling for note callouts */ }
|
|
[data-status="degraded"] { /* amber indicator */ }
|
|
```
|
|
|
|
…requires no class names in the HTML. An agent producing:
|
|
|
|
```html
|
|
<aside data-callout="note">
|
|
<p>The index rebuild completes in approximately 4 minutes.</p>
|
|
</aside>
|
|
```
|
|
|
|
…has expressed both structure and presentation intent without class names, without a component library, without knowing what CSS framework the host environment uses — provided the environment loads a stylesheet that understands the vocabulary.
|
|
|
|
This is the insight behind ASW: define the vocabulary in data-attributes, implement it once in a stylesheet, and any agent that learns the vocabulary can produce well-presented output.
|
|
|
|
## Vocabulary as Protocol
|
|
|
|
A vocabulary of data-attributes is a protocol in the strict sense. It defines what values are valid, what they mean, and what behaviour they imply. The agent is the producer; the stylesheet is the consumer. Neither needs to know the other exists at authoring time.
|
|
|
|
This separation has practical consequences. The vocabulary can be versioned independently of the stylesheet. New attributes can be added without breaking existing content. The stylesheet can be swapped — a dark theme for a light one, a dense layout for a spacious one — without changing a single character of agent output.
|
|
|
|
Compare this to the alternative: a component library with named classes. When the library changes, output that was correct becomes incorrect. The agent's knowledge of the vocabulary is coupled to a specific library version. In an environment where agent sessions are ephemeral and library versions drift, this coupling is a liability.
|
|
|
|
## What Agents Need
|
|
|
|
An agent producing web content needs three things from its output format:
|
|
|
|
1. **Legibility without tooling** — the output should be readable without running a build step
|
|
2. **Structure that survives transmission** — the format should not lose information when copied, logged, or forwarded
|
|
3. **Presentation without class-name memorisation** — the agent should be able to express visual intent through semantics, not through an ever-changing list of approved class names
|
|
|
|
Semantic HTML with a data-attribute vocabulary satisfies all three. It is, in retrospect, the obvious choice — which may be why it took until agents started writing HTML routinely for anyone to notice.
|
|
|
|
## Conclusion
|
|
|
|
The web was built to let humans share documents with machines as intermediaries. Agents invert this: machines produce documents for humans, with other machines as intermediaries. The format that works in both directions is the same one. HTML is not a legacy technology that agents must work around. It is the interface layer they were always going to need.
|