Why Microformats Put Data in HTML

Human-readable first

Microformats begin with content already published for people. Class and relationship conventions identify useful properties inside that HTML, allowing software to extract contacts, events, posts and other facts. This reduces the risk that a hidden metadata block says something different from the page, although only disciplined templates and tests prevent drift completely.

Small conventions

A microformat solves a focused publishing problem with established naming and parsing rules. It does not attempt to model every domain in one ontology. Small vocabularies are easier to add incrementally and to test in existing pages. Extension should follow demonstrated publishing needs rather than speculative fields that nobody renders or consumes.

Reuse before invention

The design process looks for existing semantic HTML, link relations and vocabulary patterns before adding another convention. Reuse lowers parser complexity and improves compatibility, but only when the existing term carries the required meaning. Similar labels are not enough; examples and value parsing must align with the intended use.

Visible data reduces drift

A value embedded in a visible name, link or date is maintained whenever the page is maintained. Separate feeds and metadata scripts can still be appropriate for complex graphs, but they create another synchronization responsibility. Microformats are strongest when HTML is already the canonical public representation of a modest record.

Decentralized publishing

Independent sites can publish interoperable facts without registering every record with one platform. Stable URLs and common parsers let applications discover that information across the web. Decentralization also shifts responsibility to publishers: identity, privacy, corrections and long-term URL handling must be governed locally.

Limits and alternatives

Microformats are not a replacement for every API or graph format. Large datasets, private transactions and complex domain relationships often need dedicated interfaces or JSON-LD. The choice should follow the authoritative representation, consumer needs and update model. Publishing the same facts in several formats requires explicit consistency tests.

A practical adoption test

Choose one repeated template, add the smallest relevant root and properties, then inspect parser output from the deployed page. Confirm that a real consumer can use the result and that editors can maintain it. Expand only after the first case remains stable across design and content changes.

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 human-readable first?
• What executable example or test demonstrates the intended behavior for small conventions?
• What executable example or test demonstrates the intended behavior for reuse before invention?
• What executable example or test demonstrates the intended behavior for visible data reduces drift?
• What executable example or test demonstrates the intended behavior for decentralized publishing?
• What executable example or test demonstrates the intended behavior for limits and alternatives?

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

Microformats overview · Start with h-card