h-resume: Résumés and Experience in HTML

One document, two audiences

An h-resume adds structure to a résumé that remains designed for people. The root identifies the résumé; nested properties associate identity, summary, experience, education, skills and affiliations. Structured markup should follow the visible hierarchy instead of creating a second invisible résumé whose dates or titles can drift from what readers see.

Contact identity

The p-contact property generally contains an h-card for the subject. Publish a stable professional URL and only the contact methods intended for public discovery. Home addresses, personal numbers and private email addresses rarely need to be embedded. A downloadable private résumé can carry different details from the public web profile.

Experience entries

Experience can be represented through nested h-event structures with an organization, role, start and end. Present-tense roles should not receive a fabricated future end date. Normalize machine-readable dates while allowing concise visible labels such as “2022–present.” Explain overlapping roles rather than assuming a parser or recruiter will infer part-time or advisory status.

Education and credentials

Education entries also benefit from explicit institution, subject and date boundaries. Distinguish completed credentials from attendance, certificates and informal training. Do not encode a credential as awarded when the visible text says it is in progress. Stable organization URLs reduce ambiguity between similarly named institutions.

Skills need evidence

A list of p-skill values is easy to publish but often too broad to evaluate. Group skills by practice area and connect important claims to visible projects or experience. Avoid keyword stuffing and duplicate variants inserted only for extraction. The human résumé remains the authoritative explanation of depth, recency and context.

Privacy and longevity

Résumé data is designed to be copied. Remove details that create unnecessary personal risk, use month precision only when it matters and establish a correction route. Cached structured data can survive later edits. Publishing fewer durable facts is often safer than exposing a complete employment database on a public page.

Test chronological structure

Parse the page and inspect the contact card, role names, organizations and date values. Test a current role, a role with month-only precision and concurrent positions. Validate the HTML and keyboard reading order. The extracted chronology should match the visible one without depending on CSS positioning or table layout.

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 one document, two audiences?
• What executable example or test demonstrates the intended behavior for contact identity?
• What executable example or test demonstrates the intended behavior for experience entries?
• What executable example or test demonstrates the intended behavior for education and credentials?
• What executable example or test demonstrates the intended behavior for skills need evidence?
• What executable example or test demonstrates the intended behavior for privacy and longevity?

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

h-card identity markup · Microformats overview