Microformats and Structured HTML

Structured data inside HTML

Microformats use agreed class names and link relationships to express data in human-readable HTML. The visible page remains the primary document; parsers extract structured properties from that same markup. This progressive approach differs from maintaining a separate data representation that can drift from what readers see.

Vocabulary and parsing

A microformat defines roots, properties and value-parsing rules. Modern microformats2 vocabularies use prefixes such as h- for roots, p- for plain text, u- for URLs, dt- for dates and e- for embedded markup. Correct class names are only part of conformance; nested value and datetime parsing also matter.

Identity and URLs

Person and organization data frequently contains URLs, email addresses and photographs. Publish only information intended to be public, use canonical URLs consistently and avoid sample personal details that look real. Structured markup makes data easier to collect, so privacy review matters.

Testing

Validate the HTML first, then inspect the parsed microformat result. A page can render correctly while a missing property prefix or nested structure changes the extracted data. Test canonical URLs, relative link resolution and date values across time zones.

When to use another format

Microformats are well suited to structured facts embedded in pages. JSON-LD is often more practical for complex Schema.org graphs, and dedicated APIs are appropriate for large dynamic datasets. The right choice depends on whether HTML is the authoritative representation.

Implementation notes

Choose the vocabulary from the visible object on the page: a person, event, review, post or other established root. Add the root class to the smallest element containing that object, then mark only properties the page genuinely publishes. Prefer stable links and semantic HTML elements before adding wrapper spans solely for extraction.

Treat parser output as the interface. Store representative rendered pages as fixtures and run a microformats2 parser after template changes. Inspect resolved URLs, dates, nested roots and embedded markup rather than counting class names. If JSON-LD is published for another consumer, compare shared facts automatically so the two representations cannot contradict each other unnoticed.

Failure modes

CSS refactoring can move a property outside its root or remove a class that looked presentational. Relative URLs can resolve against an unexpected base, and a date that is clear to local readers can be ambiguous to software. A browser screenshot will not reveal these problems; validation must include the extracted data model.

Structured publishing also increases discoverability of personal data. Avoid realistic personal details in examples, expose only durable public contact points and create a correction process. Hiding a value visually while leaving it in markup does not protect it. The human-readable page and extracted record should have the same privacy boundary.

Review checklist

• Established root selected
• Visible values marked up
• URLs canonicalized
• Dates unambiguous
• Parser output tested
• Privacy reviewed

Questions for a design review

Use this reference to make a review decision, not merely to recognize terminology. Record the concrete document, schema, processor or consumer being discussed; the language and processor versions; and the behavior that must remain compatible. A useful review produces fixtures and an owner for every unresolved assumption.

• What executable example or test demonstrates the intended behavior for structured data inside html?
• What executable example or test demonstrates the intended behavior for vocabulary and parsing?
• What executable example or test demonstrates the intended behavior for identity and urls?
• What executable example or test demonstrates the intended behavior for testing?
• What executable example or test demonstrates the intended behavior for when to use another format?

Include at least one ordinary case, one boundary case and one deliberately invalid or unsupported case. Check the result in the actual production toolchain, because parsers, validators, code generators and reasoners do not all implement the same optional features. Store the selected contract version with the test result, then repeat the review when a dependency, namespace, profile or public declaration changes.

Continue with a working reference

Data contract layers · Standards reference