microformats include pattern
offers two methods — using
<a> — to include in a microformat
element parts of a document that are outside of that microformats element's
DOM tree. Both patterns have problems, and have not been widely adopted.
Also, the include pattern has not been updated for
This page is a proposal for a new include pattern using a
without any semantics.
The tag name I'm using for the custom element in the example pages is
<mf-include> but it could be anything. The custom element has a custom
includeid, but again, this attribute name could be anything.
includeid attribute would work the same way that the standard
Authors can use the new
includeid to place a space-separated list of
attributes. A microformats parser should then search for an element whose
id matches a token in the
includeid. If it finds a matching id, it should
include that matched element in the tree of the microformats element, as if
it appeared in the DOM inside the
<mf-include> element; also, the parser
should ignore any content in the custom element, effectively replacing
the custom element's content with the content of all included elements.
- example 1
- The first example is a page with an h-card element and two h-recipe elements.
The h-card element describes the author of the recipes. Rather than repeat
the h-card markup in each h-recipe, the page instead puts the h-card in
<header>element. Each h-recipe element includes the h-card by using an empty custom element. A microformats parser should include the properties of the h-card as if that element appeared inside the custom element.
- example 2
- The second example is identical to the first except for one difference. In this example, the custom element has content, a shortened, simplified h-card. The parser should produce the exact same JSON when it parses the microformat, because the parser should replace the contents of the custom element with the h-card element. Using this pattern, authors can offer a backup for older parsers that don't understand the new include pattern.