h-entry - Microformats Wiki h-entry From Microformats Wiki Jump to navigation Jump to search h-entry is a simple, open format for content on the web. h-entry is often used with content intended to be syndicated, e.g. blog posts. h-entry is one of several open microformat standards suitable for embedding data in HTML. h-entry is the microformats2 update to hAtom , in particular its "hentry" root class which itself was based on Atom 's "entry" element. For an update to "hfeed" see h-feed Status This is a Living Specification yet mature enough to encourage additional implementations and feedback . This specification has portions that are stable, draft, and proposed. Features are stable unless explicitly labeled draft or proposed, or in draft or proposed sections. Draft and proposed features are likely to change substantively. While substantive changes to stable features are unexpected, it is a living specification subject to substantive change by issues and errata filed in response to implementation experience, requiring consensus among participating implementers as part of an explicit change control process. Participate Open Issues Resolved issues before 2012-246 IRC Advance the spec by following explicit change control process Editor Tantek Çelik License Per CC0 , to the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 2026-04-24, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0 Contents Example Get started Properties 3.1 Core Properties 3.2 Draft Properties 3.3 Proposed Additions 3.4 Proposing and upgrading Property Details 4.1 p-location FAQ 5.1 p-name of a note 5.2 venue an entry was posted from 5.3 address an entry was posted from 5.4 lat long an entry was posted from 5.5 dt-published property and HTML5 time element 5.6 what is the bare minimum list of required properties on an h-entry Examples in the wild 6.1 offline Validating Implementations Backward Compatibility 9.1 Publisher Compatibility 9.2 Parser Compatibility 9.3 Compat FAQ 9.3.1 What about rel bookmark 9.3.2 Why rename entry-title entry-summary entry-content 10 Related Work 11 Background 12 change control 13 See Also Example Here is a simple blog post example: article class "h-entry" h1 class "p-name" Microformats are amazing h1 Published by class "p-author h-card" href "http://example.com" W. Developer on time class "dt-published" datetime "2013-06-13 12:00:00" 13 sup th sup June 2013 time >class "p-summary" In which I extoll the virtues of using microformats. div class "e-content" Blah blah blah div article Parsed JSON: "items" "type" "h-entry" ], "properties" "name" "Microformats are amazing" ], "author" "value" "W. Developer" "type" "h-card" ], "properties" "name" "W. Developer" ], "url" "http://example.com" ], "published" "2013-06-13 12:00:00" ], "summary" "In which I extoll the virtues of using microformats." ], "content" "value" "Blah blah blah" "html" "
Blah blah blah
" Get started The class h-entry is a root class name that indicates the presence of an h-entry. p-name p-author dt-published and the other h-entry property classnames listed below define properties of the h-entry. Note: The purpose of an entry is to place it around both the explicitly written content (in the content property or in other specific properties for non-textual content or responses) and whatever else is the context for that content, including properties for when it was published and/or updated, who created it, tags or categorization, and links to what the content is a response to (perhaps with a quoted excerpt) and/or links to syndicated copies. Properties h-entry properties, inside an element with class h-entry . All properties are both optional and may have multiple instances, e.g. multiple name, url, photo etc. properties. See microformats2-parsing to learn more about property classnames. Core Properties The following core h-entry properties have broad consensus and are broadly interoperably published and consumed: p-name - entry name/title p-summary - short entry summary e-content - full content of the entry dt-published - when the entry was published dt-updated - when the entry was updated p-author - who wrote the entry, optionally embedded h-card (s) p-category - entry categories/tags u-url - entry permalink URL u-uid - universally unique identifier, typically canonical entry URL p-location - location the entry was posted from, optionally embed h-card h-adr , or h-geo u-syndication - URL(s) of syndicated copies of this post. The property equivalent of rel-syndication archived example u-in-reply-to - the URL which the h-entry is considered reply to (i.e. doesn’t make sense without context, could show up in comment thread), optionally an embedded h-cite reply-context ) ( example p-rsvp (enum, use element or value-class-pattern "yes", "no", "maybe", "interested". Case-insensitive values, normalized to lowercase. Examples: ... is going to ... , or ... might go to ... ... unable to go to ... ... am interested/tracking/watching ... u-like-of - the URL which the h-entry is considered a “like” (favorite, star) of. Optionally an embedded h-cite u-repost-of - the URL which the h-entry is considered a “repost” of. Optionally an embedded h-cite Draft Properties The following draft properties are in use in the wild (published and consumed), and are under strong consideration, but are not yet part of the core: p-comment - optionally embedded (or nested?) h-cite (s), each of which is a comment on/reply to the parent h-entry. See comment-brainstorming example Issue 20 u-photo - one or more photos that is/are considered the primary content of the entry, unless there is a p-location h-card , which is still considered a "checkin" (i.e. with a photo). Otherwise the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo. Issue 4: u-photo draft->core bc way more than 3+ pub and consuming impls/sites depends on: Issue 24: Update Definition of Draft Property u-photo depends on: Issue 23: E-Content Overlaps with u-photo and similar properties Proposed (issue TBF): A u-photo property MUST be on an element that provides a text description for the image (e.g. ) UNLESS the image is already described inside the contents a text property such as p-name p-summary , or e-content u-video - special u- parsing rules for