Microformats Wiki - User contributions [en]

microformats2-prefixes

2021-08-17T15:32:39Z

Kevin Marks: /* naming conventions for generic parsing */

{{DISPLAYTITLE:microformats2 prefix conventions}}

[[microformats2]] uses a small number of prefixes to distinguish microformats2 class names from other class names.

== microformats2 prefixes ==
=== naming conventions for generic parsing ===
The naming conventions for microformats class names make it obvious when:'''
* a class name represents a microformat '''root class name'''
* a class name represents a microformat '''property name'''
* a class name represents a microformat '''property that needs special parsing'''

In particular:
* '''"h-*" for root class names''', e.g. "h-card", "h-event", "h-entry"
* '''"p-*" for plain (text) properties''', e.g. "p-name", "p-summary"
** generic plain text parsing, element text in general, certain HTML elements use special attributes first, e.g. img/alt, abbr/title.
* '''"u-*" for URL properties''', e.g. "u-url", "u-photo", "u-logo"
** special parsing required: prefer a/href, img/src, object/data etc. attributes to element contents.
* '''"dt-*" for datetime properties''', e.g. "dt-start", "dt-end", "dt-bday"
** special parsing required: [[value-class-pattern]] and separate date time value parsing for readability
* '''"e-*" for element tree properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]]. The 'e-' prefix can also be mnemonically remembered as "element tree", "embedded markup", or "encapsulated markup".

== microformats2 examples ==
Example: simple heading h-card example:

<source lang=html4strict>
<h1 class="h-card">Chris Messina</h1>
</source>

More examples: here is that same heading example with name components:

<source lang=html4strict>
<h1 class="h-card">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</h1>
</source>

with a hyperlink to Chris's URL:

<source lang=html4strict>
<h1 class="h-card">
<a class="u-url" href="http://factoryjoe.com/">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</a>
</h1>
</source>

=== backwards compatibility ===

microformats2 provides backwards compatibility by enabling content authors to markup with both old and new class names for compatibility with old tools.

Here is a simple backcompat example:

<source lang=html4strict>
<h1 class="h-card vcard">
<span class="fn">Chris Messina</span>
</h1>
</source>

A microformats2 parser would see the class name "h-card" and imply the one required property from the contents, while a microformats 1.0 parser would find the class name "vcard" and then look for the class name "fn". no data duplication is required. this is a very important continuing application of the <abbr title="don't repeat yourself">DRY</abbr> [[principle]].

And the above hyperlinked example with both sets of class names:

<source lang=html4strict>
<h1 class="h-card vcard">
<a class="u-url n fn url" href="http://factoryjoe.com/">
<span class="p-given-name given-name">Chris</span>
<abbr class="p-additional-name additional-name">R.</abbr>
<span class="p-family-name family-name">Messina</span>
</a>
</h1>
</source>

== vendor extensions ==
Proprietary extensions to formats have typically been shortlived experimental failures with one big recent exception.

Proprietary or experimental CSS3 property implementations have been very successful.

There has been much use of border radius properties and animations/transitions which use CSS properties with vendor-specific prefixes like:

* -moz-border-radius
* -webkit-border-radius

etc.

Note that these are merely string '''prefixes''', not bound to any URL, and thus not namespaces in any practical sense of the word. This is quite an important distinction, as avoiding the need to bind to a URL has made them easier to support and use.

This use of vendor specific CSS properties has in recent years allowed the larger web design/development/implementer communities to experiment and iterate on new CSS features while the features were being developed and standardized.

The benefits have been two-fold:
* designers have been able to make more attractive sites sooner (at least in some browsers)
* features have been market / real-world tested before being fully standardized, thus resulting in better features

Implementers have used/introduced "x-" prefixes for IETF MIME/content-types for experimental content-types, MIME parameter extensions, and HTTP header extensions, per RFC 2045 Section 6.3, RFC 3798 section 3.3, and [https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_header_fields#Common_non-standard_headers Wikipedia: HTTP header fields - non-standard headers] (could use RFC reference instead) respectively, like:

* application/x-latex (per [https://secure.wikimedia.org/wikipedia/en/wiki/Internet_media_type#Type_x Wikipedia Internet media type: Type x])
* x-spam-score (in email headers)
* X-Pingback (per [http://en.wikipedia.org/wiki/Pingback Wikipedia:Pingback])

Some standard types started as experimental "x-" types, thus demonstrating this experiment first, standardize later approach has worked for at least some cases:

* image/x-png (standardized as image/png, both per [http://tools.ietf.org/html/rfc2083 RFC2083])

There have been times when specific sites have wanted to extend microformats beyond what the set of properties in the microformat, and currently lack any '''experimental''' way to do so - to try and see if a feature (or even a whole format) is interesting in the real world before bothering to pursue researching and walking it through the microformats process. Thus:

* '*-x-' + '-' + meaningful name for root and property class names
** where "*" indicates the single-character-prefix as defined above
** where "x" indicates a literal 'x' for an experimental extension OR
** OR "x" indicates a vendor prefix (more than one character, e.g. like CSS vendor extension abbreviations, or some stock symbols, avoiding first words/phrases/abbreviations of microformats properties like dt-)
** e.g.
** "h-bigco-one-ring" - a hypothetical "bigco" vendor-specific "onering" microformat root class name.
** "p-goog-preptime" - to represent [http://www.google.com/support/webmasters/bin/answer.py?answer=173379 Google's "preptime" property extension] to [[hRecipe]] (aside: "duration" may be another property type to consider separate from "datetime" as it may be subject to different parsing rules.)
** "p-x-prep-time" - a possible experimental property name to be added to hRecipe upon consideration/documentation of real-world usage/uptake.

Background - this proposal is a composition of the following (at least somewhat) successful vendor extension syntaxes
* [http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords CSS 2.1 4.1.2.1 Vendor-specific extensions]
* IETF MIME/content-type "x-*" extensions per RFC 2045 Section 6.3. [http://en.wikipedia.org/wiki/Internet_media_type]
* IETF MIME experimental fields (e.g. x-spam-score)
* HTTP header extensions (e.g. x-pingback)
* note also [http://www.mnot.net/blog/2009/02/18/x- some critical thoughts from mnot]

== TO DO ==
* move resolved '''issues''' to a separate page.
* clean-up and move background research to a microformats2-background or history page

== issues ==
=== Hungarian prefixing issues ===
Raised by [[User:BenWard|BenWard]] 01:16, 11 April 2011 (UTC)

Microformats 2.0 proposes using an explicit <code>[a-z]-</code> prefix on properties, to differentiate them from other uses of the class attribute, and identify them as microformat properties, such that they can be parsed generically.

* The differentiation use case is supported by anecdotal evidence of sites (such as Facebook, Twitter, Yahoo) removing microformats or breaking objects in page edits. The addition of a prefix assists self-documentation of code.
* The generic parsing use case is supported by Google Rich Snippets, Yahoo Search Monkey, and extensible plugins like Operator and the Firefox microformats parser. Although these extract microformats from the page, they are intermediate systems between the page content and the actual interpretation of the data. They need to parse all objects from a page, and then another developer or application will interpret some of them into something else.

(Note: the theoretical assertion "they need to parse all objects from a page" is not actually backed by *any* existing use of microformats/microdata/RDFa parsing - *none* of those parse "all objects from a page" if you consider every markup element an "object" - rather, one of the strength of microformats (mimicked by the others) is that the publisher is able to markup *just* the data to be extracted, rather than perhaps purely "presentational" content, ads, UI widgets etc. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC) )

The µf2 proposal goes further, though, into a small vocabulary of [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian] prefixes of properties based on data type. This increases the level of understanding required to read microformats, and reduces the benefit of all microformat properties having a consistent identifying prefix.

(Debatable assertion:"increases the level of understanding required to read microformats" - how? In microformats 2.0, authors/developers know that any single-letter-and-hyphen prefixed class name is for microformats 2.0, in contrast to today - developers have consistently given feedback that's hard to tell which generic class names (other than h* names) are microformat related and which are not. As for specific prefixes, "h-*" is special and follows the pattern of existing microformats. p = generic (p)roperty, and the other prefixes have trivial mnemonics as well, d for (d)atetimes etc. (so far, hopefully we can keep that up). -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC) )

Hungarian notation itself is controversial amongst programmers.
Plenty find it uglifies their code, can be a cause of confusion (especially when very-short prefixes are used, or esoteric types, or where the declared set of types differs from the available types in other programming languages.) Others support its benefits to type identification.

(Programmers are not the priority here, rather, designers/authors/publishers are. We design microformats for them first as they're the common use case, and we should avoid making statements that seem to imply any priority for the aesthetic preferences of programmers. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC))

Critically, however, there is no clear indication that either of the above use cases requires types to be strongly identified.

<div class="discussion">
* For identifying µf in pages, a differentiator is required from regular classnames. There is no evidence of further requirement to differentiate between properties beyond their name (and existing criticisms of Hungarian notation suggest it can harm understandability.)
** There is such evidence, and perhaps thus this would be a good FAQ topic. The derivation is quite simple - it comes directly from minimally affecting existing markup, and maximally using existing semantic information. Example of special purpose parsing, URL-like properties use the value of the 'href' (or equivalent) attribute because that's where that data already is in pages. Similarly with dates and datetimes - special parsing rules for that data type have permitted us to design the [[value-class-pattern]] to take advantage of specially parsing date and time separation. By re-using data *where publishers already put it, including attributes vs inline* we minimize the risk of data drift. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)
** Additionally, this special type-specific parsing of microformats properties conveys microformats advantages of markup brevity that other syntaxes lack. E.g. you can convey *multiple* properties and values from a single existing element, e.g. the *very* common real-world pattern <code><br/><nowiki><a href="http://example.com/user">User Name</a></nowiki><br/></code> is minimally marked up as <code><br/><nowiki><span class="h-card"><a class="p-name u-url" href="http://example.com/user">User Name</a></span></nowiki><br/></code>
* For generic parsing, there is no requirement that datatypes be established at extraction time. Data types will instead be applied by the developers of apps and widgets that build on the generic parsers.
** There are requirements based on experience with actual markup. In order to support the patterns of where content publishers put the data we want to extract, we have determined (based on those publishing patterns) a few different ways (types) of parsing this data. This is all captured in the [[hcard-parsing]] property-specific parsing rules each of which were added one at a time as Brian Suda and myself encountered real world sites wanting to use [[hCard]] but not wanting to have to rewrite their markup (adding one span and some class names was about the limit, moving tags/attributes around was a showstopper in many/most cases), and each of the microformats 2.0 "types" are directly derived from such special purpose data/type parsing across *multiple* microformats. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)
* A counter argument may be that special properties in microformats—such as URLs, or images—need to be identified because in microformats it is common to parse an attribute (href, or src) rather than inner text of an element for these properties. However, in the context of extracting and then interpreting HTML in other contexts this is insufficient: For example, though an image only exists as a single property in vcard, in HTML it is both a URL to a resource ''and'' and text string (alt) representing an accessible fallback. A ‘generic extracter’ of microformats from a page must capture all of this information from HTML, so that the interpreting application can choose which data type is most relevant to its context. Likewise, an application interpreting a URL may also consider using the original inner text as an inferred label. Both pieces of data are useful, and a generic parser should not discard elemental semantics at the extraction level.
** It's not just "*common* to parse an attribute rather than inner text of an element for these properties" - it is the vast overwhelming majority - if not all - such cases!
** One misconception: "image only exists as a single property". No, there is both 'photo' and 'logo'. The 'url' and 'sound' properties are also of type 'url'. For all of these, when parsing an "object" element, you must use the 'data' attribute first for example. hCalendar has "attachment" as well. Etc.
** Theoretical assertion: "A ‘generic extracter’ of microformats from a page must capture all of this information from HTML, so that the interpreting application can choose which data type is most relevant to its context." Why? There is no existing nor demonstrated use case for this requirement, even across other formats. While I agree it "might be nice" to develop a new "structured image" type - that's brand new work (deserving of research per the [[process]] etc.), and not a good source of reasoning to reject existing working patterns. I reject blocking microformats 2.0 on an as-yet-to-be-researched-enhancement. This is certainly a case where "better" is an enemy of the good.
** Theoretical assertion: "a generic parser should not discard elemental semantics at the extraction level" - already does for other syntaxes like both microdata and RDFa - so clearly this is not a reasonable "should not" assertion (and thus unnecessary) for development of a minimally competitive syntax. RDFa kind of cheats by overloading the 'rel' attribute in attempt to solve the name+url case as mentioned above, but that's only two types - and existing real world use of microformats has demonstrated utility of a few more. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)
</div>

Given this, hungarian prefixes are of no benefit to parsers (and may in fact harm applications down the chain if parsing is prematurely strict.) It would be sufficient then not to concern embedding data types in property names, and instead settle on one single property prefix to differentiate all properties consistently. This would reduce the prefixes to just 3:

* <code>h</code> would indicates a root class name. An ‘object in HTML’.
* <code>p</code> would indicates a property within an object.
* <code>x</code> would indicates an experimental extension to an object.

--[[User:BenWard|BenWard]] 01:16, 11 April 2011 (UTC)

The primary benefit of type-specific parsing is *not* for parsers, but rather, publishers (who we still hold in higher priority than parsers).

I will also note that *each* of the type-specific parsing methods in [[hcard-parsing]] was added both conservatively, reluctantly, and only when it became clear that such type-specific publishing patterns existing across *multiple* sites that would otherwise be unable to change their markup to work with microformats (Yes, I'm wishing now that I better documented exactly *which* sites, precisely *when*, but like many startups, early on we didn't exactly know how much to document vs get things done - frankly I think we documented far more than any other comparable such efforts, e.g. we managed to at least capture/grow both an explicit [[process]] and [[principles]] in *far* greater detail than anything remotely comparable either before microformats or since!). The type-specific parsing features are certainly not overdesigned, on the contrary they've *slowly* evolved, adapting to real world data on the web.

While per the [[simplicity]] principle, I would actually *strongly* prefer to only have the three prefixes given above, or actually just *two* (I started with just two for the design of microformats 2.0 actually, just "h-*" and "p-*"), doing so would be a step *backwards* in terms of the adaptability of microformats to existing markup, and that's IMHO an unacceptable barrier, and a sufficiently high barrier to hurt the adoption/applicability of microformats 2.0.

(Aside: In addition, note that you still need h-x-* for experimental objects, and thus it's *simpler* to simply have *both* h-x-* and p-x-* rather than add x-*. Alternatively x-h-* and x-p-* is no better, in some ways worse, in that object vs. property is a more important distinction for parsers than established vs experimental, especially if/when an experimental property (or object) may be adopted. Also, mild precdent: PNG started with image/x-png, not x-image/png.).

To put it in a positive way, type-specific parsing conveys microformats a publisher-markup-density (and re-use) advantage which neither microdata nor RDFa have, and it would behoove us to *keep* this significant real-world advantage as we evolve microformats.

-- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)

== motivating causes ==
As described on the [[microformats 2]] page.

=== distinguishing properties from other classes ===
Current microformats properties re-use generic terms like "summary", "photo", "updated" both for ease of use and understanding.

However, through longer term experience, we've seen sites that accidentally drop (or break) their microformats support (e.g. Upcoming.org, Facebook) because web authors sometimes rewrite all their class names, and either are unaware that microformats were in the page, or couldn't easily distinguish microformats property class names from other site-specific class names.

This issue has been reported by a number of web authors:
* [http://html5doctor.com/microformats/#comment-10241 Wim's comment on HTML5Doctor] "Authors use classes like 'url' or 'region' all the time ... All sorts of markup might look like a microformat."
* ...

There has also been an anecdotal report of a design firm who was not (yet) familiar with microformats seeing the "extra" classes that "that don't seem to be used" (without corresponding CSS rules) and asking if they "can remove them". By making microformats class names different from generic words, authors unfamiliar with microformats may at least notice such distinction and infer special functionality accordingly.

Thus microformats 2 uses ''prefixes'' for property class names, e.g.:
* '''p-summary''' instead of ''summary''
* '''u-photo''' instead of ''photo''
* '''dt-updated''' instead of ''updated''

Such prefixing of all microformats class names was first suggested by Scott Isaacs of Microsoft to Tantek on a visit to Microsoft sometime in 2006/2007, but specifically aimed at making microformats easier to parse. At the time the suggestion was rejected since microformats were focused on web authors rather than parsers.

However, since experience has shown that distinguishing property class names is an issue for '''both web authors and parser developers''', this is a key change that microformats 2 is adopting. See the next section for details.

=== existing microformats parsing requirements ===
A non-trivial number of parser and tools developers have been sufficiently frustrated with some general issues with microformats that they've done the significant extra work to support very different and less friendly alternatives (microdata, RDFa). Based on this real-world data (market behavior), it behooves us to address these general issues with microformats for this constituency.

COMMUNITY and TOOLS (that) USE MICROFORMATS
* parser / parsing
* structured
* getting the data out
* json - 1:1 mapping

[[parsing]] microformats currently requires
# a list of root class names of each microformat to be parsed
# a list of properties for each specific microformats, along with knowledge of the type of each property in order to parse their data from potentially different portions of the HTML markup
# some number of format-specific specific rules (markup/content optimizations)

This has meant that whenever a new microformat is drafted/specificied/adopted, parsers need to updated to handle it correctly, at a minimum to parse them when inside other microformats and avoid errantly implying properties from one to the other (containment, [[mfo]] problem).

=== naming conventions for generic parsing ===
There is a fairly simple solution to #1 and #2 from the above list, and we can make progress towards minimizing #3. In short:

'''Proposal: a set of naming conventions for microformat root class names and properties that make it obvious when:'''
* a class name represents a microformat root class name
* a class name represents a microformat property name
* a class name represents a microformat property that needs special parsing (specific type of property).

In particular - derived from the real world examples of existing proven microformats (rather than any abstraction of what a schema should have)
* '''"h-*" for root class names''', e.g. "h-card", "h-event", "h-entry"
** The 'h-' prefix is based on the existing microformats naming pattern of starting with 'h'.
* '''"p-*" for simple (text) properties''', e.g. "p-fn", "p-summary"
** vocabulary generic parsing, element text in general, treat certain HTML element/attribute combination as special and use those first, e.g. img/alt, abbr/title.
** The 'p-' prefix is based on the word "property" starting with 'p'.
* '''"u-*" for URL properties''', e.g. "u-url", "u-photo", "u-logo"
** special parsing required: prefer a/href, img/src, object/data etc. attributes to element contents.
** The 'u-' prefix is based on URL/URI starting with the letter 'u', which is the type of most of these related properties.
* '''"dt-*" for datetime properties''', e.g. "dt-start", "dt-end", "dt-bday"
** special parsing required: [[value-class-pattern]], in particular separate date time value parsing for better human readabillity / DRY balance.
** The 'dt-' prefix is based on "date time" having the initials "dt" and the preponderance of existing date time properties starting with "dt", e.g. dtstart, dtend, dtstamp, dtreviewed.
*** Initially I had proposed "dt-*" but Chris Messina suggested reducing it to "d-*" so that all prefixes were a single letter - made sense.
*** However, I've noticed that Google+ is using "d-*" class names on [https://plus.google.com/109182513536739786206 profile pages], thus we can't really use 'd-' as a microformats 2 property parsing prefix. [[User:Tantek|Tantek]] 03:00, 22 July 2011 (UTC)
* '''"e-*" for element tree properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]]. The 'e-' prefix can also be mnemonically remembered as "element tree", "embedded markup", or "encapsulated markup".
** special parsing required: follow the [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments HTML spec: Serializing HTML Fragments algorithm] to create a serialization.

This provides a simpler transition/education story for existing microformats authors/publishers:
* "h*" to "h-*", "dt*" to "dt-*", url-like properties to "u-*", entire embedded markup to "e-*", and "p-*" for all "plain text" properties.

As part of microformats2 we would immediately define root class names and property names for all existing microformats and drafts consistent with this naming convention, and require support thereof from all new implementations, as well as strongly encouraging existing implementations to adopt the simplified microformats2 syntax and mechanism. Question: which microformats deserve explicit backward compatibility?

As a community we would continue to use the microformats [[process]] both for researching and determining the need for new microformats, and for naming new microformat property names for maximum re-use and interoperability of a shared vocabulary.

If it turns out we need a new property type in the future, we can use one of the remaining single-letter-prefixes to add it to microformats 2.0. This would require updating of parsers of course, but in practice the number of different types of properties has grown very slowly, and we know from other schema/programming languages that there's always some small limited number of scalar/atomic property types that you need, and using those you can create compound types/objects that represent richer / more complicated types of data.

==== ADVANTAGES ====
This has numerous advantages:
* '''better maintainability''' - much more obvious to web authors/designers/publishers which class names are for/from microformats.
* '''no chance of collision''' - for all practical purposes with existing class names and thus avoiding any need to add more complex CSS style rules to prevent unintended styling effects.
* '''simpler parsing''' - parsers can now do a simple stream-parse (or in-order DOM tree walk) and parse out '''all''' microformat objects, properties, and values, without having to know anything about any specific microformats.
* '''separation of syntax and vocabulary''' - by abstracting microformats 2 syntax independent of any vocabulary, it allows and encourages development of shared vocabularies that can work in alternative syntaxes.

==== prefixes for future consideration ====
possibly also:
<div class="discussion">
* '''"s-*" for structured properties''' basically s-* works just like h-* except that no properties (e.g. 'name','url','photo') are implied when there are no properties present. Example uses: s-geo and s-adr. This is being considered as a result of [[microformats-2-parsing#Parsing_Literal_Values|microformats 2 parsing discussions]]. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** -1. Although I do think the implied-literal parsing behaviour carries some complications and parsed-cruft with more 'structural' formats, introducing a further generic prefix to differentiate one kind of format from another is oesoteric, won't be understood by authors (we're already considering a full reversal rename of 'fn' to 'name' in response to user comprehension), and we've seen historically that mixed prefixes (v and h) also cause muddle. --[[User:BenWard|BenWard]] 06:30, 5 October 2011 (UTC)
*** This is good reasoning, especially the comparison to v vs. h prefixed root class names (my experience with authors concurs with that). Each new prefix introduces complexity and thus must have advantages sufficient to exceed the complexity cost. [[User:Tantek|Tantek]] 06:55, 5 October 2011 (UTC)
** Furthermore, both of the examples given here have in-the-wild use cases for literal parsing: Geo's existing documented optimisation of <code>1.233;0.453</code> is applied in two (one valid) manners with the <code>abbr</code> element (incorrectly as an expansion of a place name, and as an alternative to degree-format co-ordinates. Coordinates are also displayed in-place alongside map references, markers, and the like.) In the case of <code>adr</code>, there's an overlap with existing uses of the <code>label</code> label property, which is used in cases of unstructured addresses (common in most social network profile systems, also in vcalendar.) Based on previous discussion around unstructured addresses, Twitter uses <code><* class="adr"><* class="label"></code> on profiles ([https://twitter.com/intent/user?screen_name=benward&detailed Example].) Having literal parsing of <code>adr</code> would be neater though, if <code>label</code> were to be deprecated. --[[User:BenWard|BenWard]] 06:30, 5 October 2011 (UTC)
*** [[geo]] has been historically quite problematic in practice, despite our efforts at making it work better via optimizations. I'd like to see real world examples of "Coordinates are also displayed in-place alongside map references, markers, and the like" documented on a page like [[geo-examples]] so we can see how any kind of geo-markup could/would help. Interesting about the Twitter use of 'label' inside 'adr' - quite prescient as [[vCard4]] moved 'label' from being its own top-level property to being an attribute (what we used to call subproperty) of 'adr'. Thus we should consider adding 'p-label' as a property for 'h-adr', given a) Twitter's real world usage, b) the refactoring of label into adr in vCard4. [[User:Tantek|Tantek]] 06:55, 5 October 2011 (UTC)
* '''"e-*" for properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]]. (2011-09-21 note: this has now been included in microformats 2, the below discussion is kept for posterity [[User:Tantek|Tantek]] 09:44, 21 September 2011 (UTC))
** unclear if this is necessary in general. and if so, if this is only for hAtom, that's insufficient to justify putting it in the generic syntax.
** Would be sufficient to have all <code>p-</code> properties parse the complete content, including any nested mark-up if present, and then implementations to sanitize/run a <code>strip_tags</code> style function (as per data input best practice) as appropriate. --[[User:BenWard|BenWard]] 22:05, 19 September 2011 (UTC)
** Ouch that sounds like passing on complexity downstream for all cases just to handle *one* known use-case so far. Since we'd typically do the opposite (simplify for the 99% case over the 1% case), passing on content including mark-up by default seems like a step backwards. Also, given how many vulnerabilities seem to deal with parsing/filtering, doing that *first* rather than burdening downstream implementations seems like the right choice. I'd rather wait til we get a concrete complaint from a microformats-2 hAtom consumer before worrying about this for hAtom 2.0. Or are there other current real world use cases besides Atom? [[User:Tantek|Tantek]] 22:22, 19 September 2011 (UTC)
*** In addition to <code>entry-content</code> in hAtom there's also <code>entry-summary</code>, plus any large region of text in other microformats, which at the very least can commonly contain additional hyperlinks, images, and phrasing mark-up: <code>description</code> in hCal, hReview, hProduct, hListing, <code>note</code> in hCard, <code>ingredient</code>, <code>instructions</code> in hRecipe may link to a store, or wikipedia entry for the ingredient, or include an image to illustrate a step of a recipe, as well as recipe instructions that are expressed as lists. If an author/publisher marks up a property in such a way that it contains further mark-up, that mark-up should be assumed to be part of the value. It's always going to be up to an implementation to decide whether it wishes to translate that HTML mark-up into some other format (e.g. Markdown-esque text annotation when converting to something like <code>vcard</code>, or some other kind of formatting language on non-HTML platforms, or stripping text altogether. —[[User:BenWard|BenWard]] 01:05, 20 September 2011 (UTC)
**** While hAtom's <code>entry-content</code> and possibly hCard's <code>note</code> may be the only existing practical use-cases (<code>entry-summary</code> and other "large region of text" are potential/prospective use cases), I'm now convinced the hAtom use-case alone is worthy of including the "e-" prefix because it enables a full fidelity replacement for typical Atom use cases. [[User:Tantek|Tantek]] 09:44, 21 September 2011 (UTC)
* '''"i-*" for ID properties''', e.g. "i-uid" (if this is the only one, then perhaps we just always re-use "uid" or collapse with "u-*" into "u-id".)
** parsing is no different than "u-*" parsing, thus no need to introduce for now.
* '''"n-*" for numbers''', e.g. "n-rating", "n-geo", where the numbers may have different human-readable-friendly and decimal/machine values (e.g. with geo lat/long degrees minutes seconds vs decimal).
** requires definition of how would different parsing work before worthy of consideration.
* '''"t-*" for time duration''', e.g. "t-duration" in [[hCalendar]], [[hAudio]], [[hRecipe]] (note also Google's hRecipe extensions "preptime", "cooktime", "totaltime")
** requires definition of how would different parsing work before worthy of consideration.
** now that the HTML5 <time> element supports representing durations, we should simply incorporate duration (and timezone at that) into the 'dt-' datetime parsing rules. Certainly no need for a separate prefix. [[User:Tantek|Tantek]] 08:45, 1 December 2011 (UTC)
</div>

==== reserving other prefixes ====
We should '''reserve all other single-letter-dash prefixes for future use''' (within the scope of '''h-''' objects: outside of the context of an '''h-''' object, this is inapplicable).

In practice we have seen little (if any) use of single-letter-dash prefixing of class names by web developers/designers, and thus in practice we think this will have little if any impact/collisions. Certainly far fewer than existing generic microformat property class names like "title", "note", "summary".

==== existing single letter class prefixes ====
We should document existing usage of single/double letter prefixed names:
* Google+ (e.g. [https://plus.google.com/109182513536739786206 profile page], others) uses:
** '''a-'''
** '''d-'''
** '''g-''', '''gb*'''
* [http://getskeleton.com/#utilities Skeleton] uses
** '''u-''' for utility classes u-full-width u-max-full-width u-pull-right u-pull-left and u-cf
* [https://github.com/suitcss/utils SUITCSS] uses
** '''u-''' for utility classes. Usually two words written in camelCase: u-alignTop u-floatLeft however some use abbreviations: u-nbfc (new block formatting context) u-cf (clearfix)
* Yahoo
** '''y-'''
* others? please add alphabetical by company/org name.

== see also ==
* [[microformats-2]]
* [[microformats-2-brainstorming]]
* [[microformats-2-faq]]

menu-brainstorming

2020-12-04T15:04:10Z

Kevin Marks: /* Brainstorming */ agree p-caetgory is good

{{stub}}

Per [[process]], for documenting ideas towards a restaurant [[menu]] microformat, based on experience and research into:
* [[menu-examples]]
* [[menu-formats]]
And of course using existing microformats as building blocks when appropriate.

== Brainstorming ==
There may be some similarities with [[h-resume]], which also has an [[h-card]] for the organization (e.g. restaurant) whom the resume belongs to.

The obvious path forward is to use [[h-product]] for menu items. [[h-product]] offers pretty much everything a menu item microformat needs: p-name for the item name, (e.g. mushroom soup), u-photo, e-description, and p-price. There are some additional things in menus, notably calories, that might require a new property. If a menu has a page for individual items, u-url is available. [[h-review]] might be useful for review sites like Yelp or Google (though that might be a disincentive for restaurants, which tend to harbor strong antipathy to review sites in general and Yelp in particular. I'm not sure if p-category can be reused, but some way to tag items -- as vegetarian, gluten-free, etc. -- would be useful. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:12, 4 December 2020 (UTC)

Yes, p-category makes sense as a general tagging model. Gathering examples of categories used is useful to see what may be worth including as examples. [[User:Kevin Marks|Kevin Marks]] ([[User talk:Kevin Marks|talk]]) 15:04, 4 December 2020 (UTC)

What's missing is a container for the menu items. Such a menu container microformat could include meta information such as availability (e.g., a dinner menu is available 5pm -10pm). [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:14, 4 December 2020 (UTC)

... feel free to add more unstructured thoughts there.

== See Also ==
* [[menu]]

h-cite

2020-10-22T02:52:25Z

Kevin Marks: /* Examples in the wild */

{{DISPLAYTITLE:h-cite}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-cite</dfn> is a simple, open format for publishing citations and references to online and other publications. h-cite is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML/HTML5.

== Example ==
Here is a simple minimal abstract web citation example:
<source lang=html4strict>
<span class="h-cite">
<time class="dt-published">YYYY-MM-DD</time>
<span class="p-author h-card">AUTHOR</span>:
<cite><a class="u-url p-name" href="URL">TITLE</a></cite>
</span>
</source>

=== Get started ===
The class '''<code>h-cite</code>''' is a ''root class name'' that indicates the presence of an h-cite.

The classes '''<code>dt-published</code>''', '''<code>p-author</code>''', '''<code>p-name</code>''', and '''<code>u-url</code>''' define ''properties'' of the h-cite.

The class '''<code>h-card</code>''' on the same <code><span></code> as '''<code>p-author</code>''' indicates the presence of a nested [[h-card]] microformat as the '''author''' of the h-cite.

== Properties ==
h-cite properties (inside class <code>'''h-cite'''</code>)

* '''<code>p-name</code>''' - name of the work
* '''<code>dt-published</code>''' - date (and optionally time) of publication
* '''<code>p-author</code>''' - author of publication, with optional nested [[h-card]]
* '''<code>u-url</code>''' - a URL to access the cited work
* '''<code>u-uid</code>''' - a URL/URI that uniquely/canonically identifies the cited work, canonical permalink.
* '''<code>p-publication</code>''' - for citing articles in publications with more than one author, or perhaps when the author has a specific publication vehicle for the cited work. Also works when the publication is known, but the authorship information is either unknown, ambiguous, unclear, or collaboratively complex enough to be unable to list explicit author(s), e.g. like with many wiki pages.
* '''<code>dt-accessed</code>''' - date the cited work was accessed for whatever reason it is being cited. Useful in case online work changes and it's possible to access the dt-accessed datetimestamped version in particular, e.g. via the Internet Archive.
* '''<code>p-content</code>''' for when the citation includes the content itself, like when citing short text notes (e.g. tweets).

== Status ==
'''h-cite''' is a microformats.org draft specification. Public discussion on h-cite takes place on [[h-cite-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

== Property Details ==
(stub, to be expanded)

All web citation properties are derived from those implied in [[citation-formats#styles|existing citation styling guides]] for citing permalinks to articles and short text notes online.

Date-time properties (dt-published, dt-accessed) may optionally include time information in addition to the date if relevant to the citation (e.g. when citing short text notes (tweets) of which there may be several in a single day).

To be added:
* for each property, what equivalent TCMOS, APA, MLA terms/vocabulary is being expressed/captured as researched in the [[citation-formats#styles|citation formats styles]] section.
* transforms from the web citations proposal properties into each of those citation styles.
** for citations of blog posts / articles
** for citations of text notes / tweets
** see examples in wild below for markup samples to style in each of the TCMOS/APA/MLA styles for blog/note citations.

== Offline Citations ==
The web citation proposal can be used for simple web-to-off-web citation use cases. As suggested by Ed Summers, dropping the hyperlink to the cited web article provides a simple off-web citation, e.g. a citation of a physical book:

<source lang=html4strict>
<span class="h-cite">
<time class="dt-published">YYYY-MM-DD</time>
<span class="p-author h-card">AUTHOR</span>:
<cite class="p-name">TITLE</cite>
</span>
</source>

Note: physical books typically only provide the YYYY (year) published, not the precise date.

Next steps:
* Try such markup with actual content being published on the web (perhaps a bibliography, list of papers in a resume, etc.)
* See how it works/feels there
* Determine what seems to be missing.
* See if the "p-publisher" property helps in some web-to-off-web citation use cases.

== Examples in the wild ==
Real world in the wild examples:
* ... add uses of h-cite you see in the wild here.

* <cite class="h-cite">[http://christopheducamp.com/blog/test-indieweb-parvenir-a-posser-un-article-vers-twitter/ Test #IndieWeb : Parvenir à « POSSEr » un article vers Twitter]</cite> has an h-cite of a short note:
<source lang=html4strict>
<blockquote><p>
<cite class="h-cite">
<a class="u-url p-name" href="http://tantek.com/2013/104/t2/urls-readable-speakable-listenable-retypable">
URLs should be readable, speakable, listenable, and unambiguously
retypable, e.g. from print: tantek.com/w/ShortURLPrintExample #UX
</a>
(<abbr class="p-author h-card" title="Tantek Çelik">Çelik</abbr>
<time class="dt-published">2013-04-14</time>)
</cite>
</p></blockquote>
</source>

* Mastodon uses h-cite by default to show threads and replies to posts [https://github.com/tootsuite/mastodon/pull/1063 added in 2017]

See also examples documented here:
* https://indiewebcamp.com/h-cite#Indieweb_examples

Real but not quite wild (used by the specification author)
* Every blog post on http://tantek.com has a text field for copying h-cite markup for that blog post.
* <cite class="h-cite">[http://tantek.com/2012/353/b1/why-html-classes-css-class-selectors Why you should say HTML classes, CSS class selectors, or CSS pseudo-classes, but not CSS classes]</cite> has a couple of interesting uses of h-cite:
** properties used: p-name, u-url, p-author, p-publication, dt-published, dt-accessed (basically all proposed properties except p-content!)
** additional experimental property: p-x-translation - which refers to a nested h-cite with its own implied p-name and implied u-url.

== Background ==
This work is based on how existing [[citation-formats#styles|citation format ''styles'']] (APA, MLA, TCMOS) represent references to articles on the web, and is designed to match the implied schema of those styles. The web citations proposal defines how to markup such reference representation styles in order to satisfy the use-cases above.

=== Goal ===
A primary goal of the web citation effort is to both start small, and always "make small possible", that is, no matter how it is extended, continue permitting very small meaningful citations with perhaps only 2-3 properties (e.g. date published, author, name of work).

=== Previous Proposals ===
The biggest problem with all previous proposals is that they tried to do too much. They didn't design a citation ''micro''format that could be used as a building block, but rather, erred on the side of attempting to describe the myriad types of references to dead-tree resources. They were so over-designed that their authors didn't even dogfood them on their own sites. -- [[User:Tantek|Tantek]] 00:56, 7 August 2012 (UTC)

== FAQ ==
=== Why ===
''Why markup web citations? What problem does it solve?''

A: In the simplest form, marking up a web citation URL, name, date published, author etc. allow for processing of web citations into whatever "style" or "format" (MLA vs APA etc.) a user wishes to publish them themselves.

=== Why not just a href ===
''Doesn't <code><a href></code> solve the problem of marking up citations in an article on the web that refers to other articles on the web?''

A: No, <code><a href></code> is necessary but insufficient for marking up <em>citations</em> to articles on the web.

* '''Insufficient semantic.''' <code><a href></code> is sufficient only for providing a hyperlink (which may or may not be a citation, e.g. it may be a "see also" link rather than link to a source being cited for particular assertion or fact).
* '''A href only marks up article link and name''' An <code><a href></code> can only represent the "url" and "name" of a citation. Where as [[citation-formats#styles|published web citations]] typically also include:
** article author name (sometimes author photo and URL)
** article publication date
** article publication name
** article access date (sometimes, e.g. Wikipedia citations)

== Design Principles ==
Principles driving this proposal:
* '''solve a [[specific]] problem'''. In this case '''web citations''' seeks to solve a ''more'' specific problem than previous proposals, that of citations from the web to the web (more constrained than any publication to any publication).
* [[solve simpler problems first]]. Existing web-to-web citations contain very little information compared to generalized academic citations, thus '''web citations''' is greatly simplified compared to previous proposals by only starting with a handful of properties.
* [[humans first]] - '''web citations''' focuses on the human readability and writability aspects of citations in articles first and foremost, and only secondarily considers the machine readability/reusability of the data contained therein.
* [[reuse]] building blocks - by re-using the better designed aspects of [[citation-formats#styles|existing citation conventions]] for web resources, '''web citations''' builds on top of previous work to make citations human readable/writable, as well as what implied properties are commonly expressed by such previous work.
=== Focus ===
The <dfn>web citations</dfn> proposal uses a smaller, [[simpler]] set of only ''eight'' properties to solve the [[specific]] problem of how to markup citations in an article <em>on the web</em> that refers to other articles <em>on the web</em>. Offline to offline, and online to offline references were specifically not explicitly addressed in initial design.

== First Proposal ==
This design was first publicly proposed as the result of an interactive web citation design discussion during IndieWebCamp2012:
* <span class="h-cite"><time class="dt-published">2012-07-01</time> <span class="p-publisher">IndieWebCamp2012</span>: <cite class="p-name">[http://indiewebcamp.com/2012/Academic_Citations_Web Academic Citations for the Web]</cite></span>

[[Category:Draft Specifications]]

admin-to-do

2018-06-12T14:49:35Z

Kevin Marks: /* inbox */ reCAPTCHA

<entry-title>admin to-do</entry-title>
Filtered and processed [[to-do]] items specifically for [[admins]].

Only [[admins]] should edit this page with non-minor edits.

Please add to-do suggestions for admins to the general [[to-do#Admins|to-do page's Admins section]]. Thanks!

Items here may list who originally suggested the item on the [[to-do]] page.

Related: [[admin-how-to]].

== inbox ==
Per GTD, here are inbox items that seem reasonable and thus have been moved here by admins from the [[to-do#Admins|to-do page's Admins section]].

Main site home page:
* The microformats2 page, should also be referred from the main page of the website http://microformats.org/ like perhaps a new small right box in between "What are microformats?" and "Microformat specifications" saying something like "Microformat version" as a title and place both versions, the old one is the latest with a short description, and the new one should be imediately under the title, with the same description below.
** +1 agreed. We need a home page redesign with at least this, maybe also @microformats tweets. [[User:Tantek|Tantek]] 13:32, 15 September 2013 (UTC)

ex: [http://screencast.com/t/77YHGASumqm Homepage with the right box implemented] .

Wiki area suggestion:
*Wiki creates duplicate content by allowing duplicate pages for microformats2: the main one is http://microformats.org/wiki/microformats2 and the other one is http://microformats.org/wiki/microformats-2 .

To eliminate this problem, the 2nd page http://microformats.org/wiki/microformats-2, in the <head> section of the source code, should contain the following line <link rel="canonical" href="http://microformats.org/wiki/microformats2" />. This will tell Search Engines that this page is a duplicate content, thus it won't be indexed.

This implementation should be done on all other duplicate content pages of the website.

* This sounds like a good request. Is there a MediaWiki extension/plugin for adding rel=canonical to redirect handling pages? - [[User:Tantek|Tantek]] 13:32, 15 September 2013 (UTC)

Mirror server requests:
* Note that requests from 88.190.13.197 are for a mirror server run by [[User:Neuro|neuro]] at 88.190.224.126.
* ...

Admins Mailing list deliverability
* the last admins mailing was put in spam for kevinmarks@gmail.com by gmail for unclear reasons
** it was labelled: 'security: microformats.org did not encrypt this message link to support.google.com/mail?hl=en&p=tls '
** Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20161025 header.b=NpEH0xA1;
spf=pass (google.com: best guess record for domain of microformats-admin-bounces@microformats.org designates 64.207.154.205 as permitted sender) smtp.mailfrom=microformats-admin-bounces@microformats.org

reCAPTCHA replacement needed
* I had to edit out the https from link above to get this to save.

== next actions and projects ==
Per GTD, here are processed next-actions for admins, grouped by area/project

* [[events/2008-03-10-sxsw-admins-meetup#next_actions|next-actions from 2008-03-10 sxsw admins meetup]]
** noted here for tracking purposes.
*** This was a very long time ago - we need to reprocess this item to see what is still relevant >5 years later! - [[User:Tantek|Tantek]] 13:33, 15 September 2013 (UTC)

=== web server ===
* Investigate an upgrade of PHP from 5.2.
** PHP 5.6 active support ended 2017-01-19 and security support will end 2018-12-31 [http://php.net/supported-versions.php]. Upgrading to PHP7 might be a good idea currently. [[User:GRegorLove|gRegor]] 19:40, 9 May 2017 (UTC)

=== irc ===
* Pibb integration for the #microformats IRC channel. It is relatively simple to [http://janrain.com/blog/2007/08/08/how-to-embed-pibb/ embed the Pibb chat widget] into a webpage that bridges to the #microformats IRC channel. This would allow for greater access and transparency to the IRC discussions as well as allow people to participate using only their web browser. [[User:Chris_Messina]] 16:50, 31 Aug 2007 (PDT)

* maintainer for [[mfbot]]. Ryan King has indicated that he no longer has time to maintain [[mfbot]] and would like another admin to pick up the maintenance and running of mfbot.

* The https://indieweb.org/discuss options and Loqi cover these needs currently. [[User:GRegorLove|gRegor]] 19:43, 9 May 2017 (UTC)

=== wiki ===
==== for site update to microformats2 ====
* about
** create [[about]] from updated version of http://microformats.org/about
** change "about" link to /wiki/about

* get-started
** update [[get-started]] with info from http://microformats.org/2014/03/05/getting-started-with-microformats2

===== update wiki skin to mf2 =====
See:
* https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Skinning
* update the microformats MediaWiki skin from using [[hAtom]] (e.g. 'hentry' class name) to [[h-entry]]
* update any other classic microformats markup in the skin to mf2

==== more spec styling ====
We have [[specifications]] and [[draft specifications]] which add classnames to the body element ("specification" and "specification draft" respectively), which are then styled by the skin to look more spec-like.

We should do the same for [[stub specifications]] and update [[process]] accordingly as well.

==== wiki problems ====
Problems with the microformats wiki that an admin needs to look at and resolve:
===== MediaWiki needs updating =====
MediaWiki needs updating
* Last time update attempt broke the theme, didn't have time time debug and fix. - [[User:BenWard]]
** The IndieWeb wiki had the same problem, our resolution was to just drop the custom theme and switch to the default Vector theme. [[User:Aaronpk|Aaronpk]] 21:48, 4 December 2017 (UTC)

===== Version looks weird =====
http://microformats.org/wiki/Special:Version looks weird
* suggested culprit from cweiske: https://github.com/microformats/mediawiki-entry-title-override (so maybe that needs debugging in this case?)
* suggested troubleshooting from Tom Morris:
** do a diff between microformats.org wiki and the old version of MW
** see what's different between the two, then we can see what the likely cause of the problems are
** perhaps document differences on our [[mediawiki customization]] page for future better troubleshooting

===== Password reset page problems =====
Password reset page doesn't work:
* http://microformats.org/wiki/Special:PasswordReset
* as of 2015-06-15, this is still a problem and is now affecting users. [http://logs.glob.uno/?c=freenode%23microformats&s=15+Jun+2015&e=15+Jun+2015#c81446 relevant irc log]

==== wiki documentation ====
Need more documentation about how we have the wiki setup, so more [[admins]] are able to fix/update it.
* Update our [[mediawiki customization]] documentation with specifically:
** What plug-ins/add-ons are installed?
** What customizations / patches have been made to MediaWiki?
** What special things does the microformats mediawiki theme depend on?
** [[User:BenWard]] likely best knows these things.

==== wiki feature requests ====
===== spam fighting =====
* Install [https://www.mediawiki.org/wiki/Extension:AbuseFilter AbuseFilter]. This would allow admins to set up custom rules (similar to email rules like in Outlook/Thunderbird/Gmail etc.) that could be adapted to current spam on-the-fly.
* Install [http://www.mediawiki.org/wiki/Extension:TitleBlacklist TitleBlackList Extension] and then block creation of pages with "http:" or ".com" in the title to stop spammers from creating autolinks in the IRC logs of wiki edits.
* Consider additional mediawiki.org anti-spam strategies: https://www.mediawiki.org/wiki/Manual:Combating_spam (from Tom Morris)
** also: add reCAPTCHA setting for ConfirmEdit and SimpleAntiSpam (GPHemsley added them to the WAHTWG wiki on 2012-296)

===== semantic requests =====
* Try adding https://github.com/microformats/LinkAttributes to our wiki install to permit rel and class on links in wiki pages.
* Add Extensions - especially those that help implement more microformats on the wiki itself!
** Evaluate against Wikipedia's [http://en.wikipedia.org/wiki/Special:Version Version Page] for a list of currently installed extensions on the English Wikipedia.
** I'd personally advise getting [http://www.mediawiki.org/wiki/Extension:Cite Cite], [http://meta.wikimedia.org/wiki/ParserFunctions ParserFunctions] --[[User:JimboJW|JimboJW]] 13:38, 25 Sep 2007 (PDT) (Syntax Highlighting is done in Wiki 2.0)
** [http://www.mediawiki.org/wiki/Extension:HTML_Profiles HTML Profiles] - allows people editing the wiki to add URIs to <code><head profile></code> [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
*** +1 [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
** [http://www.mediawiki.org/wiki/Extension:Link_Attributes Link Attributes] - allows easy-ish setting of rel/rev/class attributes on links. [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
*** +1 [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
* add a class, <code>noprint</code> to the site's CSS, so that sections (such as "related pages" footers) can be made non- printing.
** ‘noprint’ isn't so semantic, but we should get a proper print stylesheet, for sure.
* Allow <kbd>webcal://</kbd>, <kbd>javascript:</kbd> (for posting [[favelets]]/bookmarklets on the wiki) and perhaps (other) x-protocols to be linkified
** +1 [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
* Would be great to have a video template that embeds an object. [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
* Can we imply <code>entry-title</code> from <code>h1</code>? [[User:Tantek|Tantek]]

===== misc requests =====
* Set up a cron job to export the wiki database (without user details), and make it available in a public location.
* Install creation template extension(s)(see: http://meta.wikimedia.org/wiki/Inputbox or http://www.mediawiki.org/wiki/Extension:CreateBox or http://www.mediawiki.org/wiki/Extension:CreateArticle) [[User:RobManson]] 14:00, 20 Jul 2007 (AEST)
* Add admins sidebar (quick ban list access)
* Do something to allow easy copying of sample input (e.g. add ‘Copy’ UI, or abuse <code>input</code> element
* Fix MediaWiki to lowercase URLs — especially fragment identifiers generated from headings. Content ''should not'' be sub-optimally edited according to the requirements of the CMS.
* Update the interwiki-links table to allow for sensible linking to other wikis doing similar work. See [https://www.mediawiki.org/wiki/Manual:Interwiki help page on mediawiki.org] and [http://microformats.org/wiki/api.php?action=query&meta=siteinfo&siprop=interwikimap current interwikimap as XML from MediWiki API].
** some plausible interwiki links: Wikipedia and other Wikimedia sites, IndieWebCamp, W3C Wiki, WHATWG wiki.

=== forum ===
In the past there have been requests (e.g. on the lists) for an online forum for microformats discussions.

If there is an admin who's interested in helping run a forum (has the time to community manage it), take a look at:

* consider create a new forum on microformats.org
** e.g. install http://vanillaforums.org/ (Geoloqi uses it successfully on https://community.geoloqi.com/ and highly recommends it)

== ongoing ==
Ongoing and as neeeded duties/tasks:

* Delete spam and block spammers from the wiki.
* Send emails to the microformats list(s) guiding the community per our [[mailing-lists]] guidelines.
* Helped out with questions on [[IRC]]
* Accepted / filtered comments on the blog (or posted!)
* Help with web server matintenence:
** Apache (reboot Apache if it hangs, debug Apache server problems)
** WordPress (including upgrading installs as needed)
** Mailman (clearing of internal spam queues)
** MediaWiki (upgrades, help package mods for resubmission back to core)
* Provide guidance to other admins
* Remove [http://microformats.org/wiki?title=Special:Whatlinkshere&target=delete pages awaiting deletion]

== waiting for ==
Per GTD, here are next-actions for admins that are awaiting some external dependency.

Waiting-for:
* Upgrade the MediaWiki to a new enough version for IndieAuth plugin to work (that is in use on indieweb.org) In order to:
** install and make available IndieAuth login, as a replacement for OpenID login (previously requested by a while ago from [[User:DanC]] and [[User:Chris_Messina]] (especially for comments in WordPress). [[User:Chris_Messina]] 16:50, 31 Aug 2007 (PDT))

== someday maybe ==
Per GTD, here are parked and otherwise deemed low-priority next-actions and projects for admins.

=== someday actions ===
* Make the edit comment UI better — textarea, not single line box. (Dev Status: Might be impossible without hacking the core)

=== someday maybe projects ===
==== improved issue tracking ====
<div class="discussion">
Issue tracking at microformats.org is poor. The wiki is difficult to track, resolutions get lost. A proper bug tracking system is desirable: However, the adminstration overhead of our current infrastructure is too high for volunteers. Questionable whether maintain another custom install of something is the direct we want to move in.
* I don't think this is worth pursuing - issue tracking systems are notoriously problematic, and at least with the wiki, editing/resolving many issues at once is far more efficient - and efficiency for microformats maintainers is an important priority since all this work is all-volunteer. [[User:Tantek|Tantek]] 02:38, 10 September 2009 (UTC)
* I think there are a few benefits to having a tracker. The primary one is simply to track proposals and have an easy platform for people to suggest new ones. That way there is a decent place for a high-level overview of what is going on. But, all of the suggested solutions suck. If it is to be done, we should investigate a custom built tracker for our needs. [[User:Garbee|Garbee]] 00:43, 3 June 2013 (UTC)
* Note that a few specs have started tracking issues on GitHub, e.g. [[h-entry]] [[User:Aaronpk|Aaronpk]] 21:47, 4 December 2017 (UTC)
</div>

* Investigate possibility/santity of using Launchpad/Github/Google Code for spec issue tracking
* Wiki is excellent documentation tool. Terrible issue tracking tool.
* External services avoid large maintenance burden
* Could better handle this todo list
* Better handle issue resolutions
* Better handle issue discussions

* Evaluate options
** Consider integration points with µf.org
** Consider open standards a plus (OpenID)
** Consider effort in porting existing content
* Copy over issues from each wiki page as standalone bugs
* Ensure that each spec editor is added with suitable authorities to manage issues

=====Custom Install of Trac=====
* + Reliable
* + Well Established
* + Can customise to look like µf.org
* + Flexible milestones etc.
* + Hook into source repository of our choosing
* + OpenID support
* + Support whatever licensing we like
* - Administration overhead

Need to check permissions structures. Can the hCard editor have control over /hcard, but not over /haudio? Do we care?

=====Google Code=====
Chris Messina has ‘microformats’ on Google Code

* + Reliably Hosted, minimal admin overhead
* + Very flexible milestones/tagging
* + SVN repository for test cases, libraries
* - Can't be styled to µf.org
* - No OpenID
* - Ugly as sin
* - No Public Domain license support

=====Launchpad=====
Ben Ward has ‘microformats’ on Launchpad

* + BZR repository for test cases, libraries
* + Public Domain License Support
* - Not instantly intuitive
* - Seems better suited to software than specifications
* - Can't style like µf.org, but, quite pretty
* - No OpenID

=====Github=====
* + Git repository for test cases, libraries
* + Issue tracking is integrated
* - No OpenID

== related ==
* [[to-do]]
* [[admins]]
* [[admin-how-to]]

admin-to-do

2018-06-12T14:48:15Z

Kevin Marks: /* inbox */ add admin list deliverability issue

<entry-title>admin to-do</entry-title>
Filtered and processed [[to-do]] items specifically for [[admins]].

Only [[admins]] should edit this page with non-minor edits.

Please add to-do suggestions for admins to the general [[to-do#Admins|to-do page's Admins section]]. Thanks!

Items here may list who originally suggested the item on the [[to-do]] page.

Related: [[admin-how-to]].

== inbox ==
Per GTD, here are inbox items that seem reasonable and thus have been moved here by admins from the [[to-do#Admins|to-do page's Admins section]].

Main site home page:
* The microformats2 page, should also be referred from the main page of the website http://microformats.org/ like perhaps a new small right box in between "What are microformats?" and "Microformat specifications" saying something like "Microformat version" as a title and place both versions, the old one is the latest with a short description, and the new one should be imediately under the title, with the same description below.
** +1 agreed. We need a home page redesign with at least this, maybe also @microformats tweets. [[User:Tantek|Tantek]] 13:32, 15 September 2013 (UTC)

ex: [http://screencast.com/t/77YHGASumqm Homepage with the right box implemented] .

Wiki area suggestion:
*Wiki creates duplicate content by allowing duplicate pages for microformats2: the main one is http://microformats.org/wiki/microformats2 and the other one is http://microformats.org/wiki/microformats-2 .

To eliminate this problem, the 2nd page http://microformats.org/wiki/microformats-2, in the <head> section of the source code, should contain the following line <link rel="canonical" href="http://microformats.org/wiki/microformats2" />. This will tell Search Engines that this page is a duplicate content, thus it won't be indexed.

This implementation should be done on all other duplicate content pages of the website.

* This sounds like a good request. Is there a MediaWiki extension/plugin for adding rel=canonical to redirect handling pages? - [[User:Tantek|Tantek]] 13:32, 15 September 2013 (UTC)

Mirror server requests:
* Note that requests from 88.190.13.197 are for a mirror server run by [[User:Neuro|neuro]] at 88.190.224.126.
* ...

Admins Mailing list deliverability
* the last admins mailing was put in spam for kevinmarks@gmail.com by gmail for unclear reasons
** it was labelled: 'security: microformats.org did not encrypt this message link to support.google.com/mail?hl=en&p=tls '
** Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify) header.i=@gmail.com header.s=20161025 header.b=NpEH0xA1;
spf=pass (google.com: best guess record for domain of microformats-admin-bounces@microformats.org designates 64.207.154.205 as permitted sender) smtp.mailfrom=microformats-admin-bounces@microformats.org

== next actions and projects ==
Per GTD, here are processed next-actions for admins, grouped by area/project

* [[events/2008-03-10-sxsw-admins-meetup#next_actions|next-actions from 2008-03-10 sxsw admins meetup]]
** noted here for tracking purposes.
*** This was a very long time ago - we need to reprocess this item to see what is still relevant >5 years later! - [[User:Tantek|Tantek]] 13:33, 15 September 2013 (UTC)

=== web server ===
* Investigate an upgrade of PHP from 5.2.
** PHP 5.6 active support ended 2017-01-19 and security support will end 2018-12-31 [http://php.net/supported-versions.php]. Upgrading to PHP7 might be a good idea currently. [[User:GRegorLove|gRegor]] 19:40, 9 May 2017 (UTC)

=== irc ===
* Pibb integration for the #microformats IRC channel. It is relatively simple to [http://janrain.com/blog/2007/08/08/how-to-embed-pibb/ embed the Pibb chat widget] into a webpage that bridges to the #microformats IRC channel. This would allow for greater access and transparency to the IRC discussions as well as allow people to participate using only their web browser. [[User:Chris_Messina]] 16:50, 31 Aug 2007 (PDT)

* maintainer for [[mfbot]]. Ryan King has indicated that he no longer has time to maintain [[mfbot]] and would like another admin to pick up the maintenance and running of mfbot.

* The https://indieweb.org/discuss options and Loqi cover these needs currently. [[User:GRegorLove|gRegor]] 19:43, 9 May 2017 (UTC)

=== wiki ===
==== for site update to microformats2 ====
* about
** create [[about]] from updated version of http://microformats.org/about
** change "about" link to /wiki/about

* get-started
** update [[get-started]] with info from http://microformats.org/2014/03/05/getting-started-with-microformats2

===== update wiki skin to mf2 =====
See:
* https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Skinning
* update the microformats MediaWiki skin from using [[hAtom]] (e.g. 'hentry' class name) to [[h-entry]]
* update any other classic microformats markup in the skin to mf2

==== more spec styling ====
We have [[specifications]] and [[draft specifications]] which add classnames to the body element ("specification" and "specification draft" respectively), which are then styled by the skin to look more spec-like.

We should do the same for [[stub specifications]] and update [[process]] accordingly as well.

==== wiki problems ====
Problems with the microformats wiki that an admin needs to look at and resolve:
===== MediaWiki needs updating =====
MediaWiki needs updating
* Last time update attempt broke the theme, didn't have time time debug and fix. - [[User:BenWard]]
** The IndieWeb wiki had the same problem, our resolution was to just drop the custom theme and switch to the default Vector theme. [[User:Aaronpk|Aaronpk]] 21:48, 4 December 2017 (UTC)

===== Version looks weird =====
http://microformats.org/wiki/Special:Version looks weird
* suggested culprit from cweiske: https://github.com/microformats/mediawiki-entry-title-override (so maybe that needs debugging in this case?)
* suggested troubleshooting from Tom Morris:
** do a diff between microformats.org wiki and the old version of MW
** see what's different between the two, then we can see what the likely cause of the problems are
** perhaps document differences on our [[mediawiki customization]] page for future better troubleshooting

===== Password reset page problems =====
Password reset page doesn't work:
* http://microformats.org/wiki/Special:PasswordReset
* as of 2015-06-15, this is still a problem and is now affecting users. [http://logs.glob.uno/?c=freenode%23microformats&s=15+Jun+2015&e=15+Jun+2015#c81446 relevant irc log]

==== wiki documentation ====
Need more documentation about how we have the wiki setup, so more [[admins]] are able to fix/update it.
* Update our [[mediawiki customization]] documentation with specifically:
** What plug-ins/add-ons are installed?
** What customizations / patches have been made to MediaWiki?
** What special things does the microformats mediawiki theme depend on?
** [[User:BenWard]] likely best knows these things.

==== wiki feature requests ====
===== spam fighting =====
* Install [https://www.mediawiki.org/wiki/Extension:AbuseFilter AbuseFilter]. This would allow admins to set up custom rules (similar to email rules like in Outlook/Thunderbird/Gmail etc.) that could be adapted to current spam on-the-fly.
* Install [http://www.mediawiki.org/wiki/Extension:TitleBlacklist TitleBlackList Extension] and then block creation of pages with "http:" or ".com" in the title to stop spammers from creating autolinks in the IRC logs of wiki edits.
* Consider additional mediawiki.org anti-spam strategies: https://www.mediawiki.org/wiki/Manual:Combating_spam (from Tom Morris)
** also: add reCAPTCHA setting for ConfirmEdit and SimpleAntiSpam (GPHemsley added them to the WAHTWG wiki on 2012-296)

===== semantic requests =====
* Try adding https://github.com/microformats/LinkAttributes to our wiki install to permit rel and class on links in wiki pages.
* Add Extensions - especially those that help implement more microformats on the wiki itself!
** Evaluate against Wikipedia's [http://en.wikipedia.org/wiki/Special:Version Version Page] for a list of currently installed extensions on the English Wikipedia.
** I'd personally advise getting [http://www.mediawiki.org/wiki/Extension:Cite Cite], [http://meta.wikimedia.org/wiki/ParserFunctions ParserFunctions] --[[User:JimboJW|JimboJW]] 13:38, 25 Sep 2007 (PDT) (Syntax Highlighting is done in Wiki 2.0)
** [http://www.mediawiki.org/wiki/Extension:HTML_Profiles HTML Profiles] - allows people editing the wiki to add URIs to <code><head profile></code> [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
*** +1 [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
** [http://www.mediawiki.org/wiki/Extension:Link_Attributes Link Attributes] - allows easy-ish setting of rel/rev/class attributes on links. [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
*** +1 [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
* add a class, <code>noprint</code> to the site's CSS, so that sections (such as "related pages" footers) can be made non- printing.
** ‘noprint’ isn't so semantic, but we should get a proper print stylesheet, for sure.
* Allow <kbd>webcal://</kbd>, <kbd>javascript:</kbd> (for posting [[favelets]]/bookmarklets on the wiki) and perhaps (other) x-protocols to be linkified
** +1 [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
* Would be great to have a video template that embeds an object. [[User:Tantek|Tantek]] 09:58, 25 June 2009 (UTC)
* Can we imply <code>entry-title</code> from <code>h1</code>? [[User:Tantek|Tantek]]

===== misc requests =====
* Set up a cron job to export the wiki database (without user details), and make it available in a public location.
* Install creation template extension(s)(see: http://meta.wikimedia.org/wiki/Inputbox or http://www.mediawiki.org/wiki/Extension:CreateBox or http://www.mediawiki.org/wiki/Extension:CreateArticle) [[User:RobManson]] 14:00, 20 Jul 2007 (AEST)
* Add admins sidebar (quick ban list access)
* Do something to allow easy copying of sample input (e.g. add ‘Copy’ UI, or abuse <code>input</code> element
* Fix MediaWiki to lowercase URLs — especially fragment identifiers generated from headings. Content ''should not'' be sub-optimally edited according to the requirements of the CMS.
* Update the interwiki-links table to allow for sensible linking to other wikis doing similar work. See [https://www.mediawiki.org/wiki/Manual:Interwiki help page on mediawiki.org] and [http://microformats.org/wiki/api.php?action=query&meta=siteinfo&siprop=interwikimap current interwikimap as XML from MediWiki API].
** some plausible interwiki links: Wikipedia and other Wikimedia sites, IndieWebCamp, W3C Wiki, WHATWG wiki.

=== forum ===
In the past there have been requests (e.g. on the lists) for an online forum for microformats discussions.

If there is an admin who's interested in helping run a forum (has the time to community manage it), take a look at:

* consider create a new forum on microformats.org
** e.g. install http://vanillaforums.org/ (Geoloqi uses it successfully on https://community.geoloqi.com/ and highly recommends it)

== ongoing ==
Ongoing and as neeeded duties/tasks:

* Delete spam and block spammers from the wiki.
* Send emails to the microformats list(s) guiding the community per our [[mailing-lists]] guidelines.
* Helped out with questions on [[IRC]]
* Accepted / filtered comments on the blog (or posted!)
* Help with web server matintenence:
** Apache (reboot Apache if it hangs, debug Apache server problems)
** WordPress (including upgrading installs as needed)
** Mailman (clearing of internal spam queues)
** MediaWiki (upgrades, help package mods for resubmission back to core)
* Provide guidance to other admins
* Remove [http://microformats.org/wiki?title=Special:Whatlinkshere&target=delete pages awaiting deletion]

== waiting for ==
Per GTD, here are next-actions for admins that are awaiting some external dependency.

Waiting-for:
* Upgrade the MediaWiki to a new enough version for IndieAuth plugin to work (that is in use on indieweb.org) In order to:
** install and make available IndieAuth login, as a replacement for OpenID login (previously requested by a while ago from [[User:DanC]] and [[User:Chris_Messina]] (especially for comments in WordPress). [[User:Chris_Messina]] 16:50, 31 Aug 2007 (PDT))

== someday maybe ==
Per GTD, here are parked and otherwise deemed low-priority next-actions and projects for admins.

=== someday actions ===
* Make the edit comment UI better — textarea, not single line box. (Dev Status: Might be impossible without hacking the core)

=== someday maybe projects ===
==== improved issue tracking ====
<div class="discussion">
Issue tracking at microformats.org is poor. The wiki is difficult to track, resolutions get lost. A proper bug tracking system is desirable: However, the adminstration overhead of our current infrastructure is too high for volunteers. Questionable whether maintain another custom install of something is the direct we want to move in.
* I don't think this is worth pursuing - issue tracking systems are notoriously problematic, and at least with the wiki, editing/resolving many issues at once is far more efficient - and efficiency for microformats maintainers is an important priority since all this work is all-volunteer. [[User:Tantek|Tantek]] 02:38, 10 September 2009 (UTC)
* I think there are a few benefits to having a tracker. The primary one is simply to track proposals and have an easy platform for people to suggest new ones. That way there is a decent place for a high-level overview of what is going on. But, all of the suggested solutions suck. If it is to be done, we should investigate a custom built tracker for our needs. [[User:Garbee|Garbee]] 00:43, 3 June 2013 (UTC)
* Note that a few specs have started tracking issues on GitHub, e.g. [[h-entry]] [[User:Aaronpk|Aaronpk]] 21:47, 4 December 2017 (UTC)
</div>

* Investigate possibility/santity of using Launchpad/Github/Google Code for spec issue tracking
* Wiki is excellent documentation tool. Terrible issue tracking tool.
* External services avoid large maintenance burden
* Could better handle this todo list
* Better handle issue resolutions
* Better handle issue discussions

* Evaluate options
** Consider integration points with µf.org
** Consider open standards a plus (OpenID)
** Consider effort in porting existing content
* Copy over issues from each wiki page as standalone bugs
* Ensure that each spec editor is added with suitable authorities to manage issues

=====Custom Install of Trac=====
* + Reliable
* + Well Established
* + Can customise to look like µf.org
* + Flexible milestones etc.
* + Hook into source repository of our choosing
* + OpenID support
* + Support whatever licensing we like
* - Administration overhead

Need to check permissions structures. Can the hCard editor have control over /hcard, but not over /haudio? Do we care?

=====Google Code=====
Chris Messina has ‘microformats’ on Google Code

* + Reliably Hosted, minimal admin overhead
* + Very flexible milestones/tagging
* + SVN repository for test cases, libraries
* - Can't be styled to µf.org
* - No OpenID
* - Ugly as sin
* - No Public Domain license support

=====Launchpad=====
Ben Ward has ‘microformats’ on Launchpad

* + BZR repository for test cases, libraries
* + Public Domain License Support
* - Not instantly intuitive
* - Seems better suited to software than specifications
* - Can't style like µf.org, but, quite pretty
* - No OpenID

=====Github=====
* + Git repository for test cases, libraries
* + Issue tracking is integrated
* - No OpenID

== related ==
* [[to-do]]
* [[admins]]
* [[admin-how-to]]

microformats2-json

2018-04-23T17:27:42Z

Kevin Marks: /* See Also */ rel-urls

<dfn style="font-style:normal;font-weight:bold">microformats2 JSON</dfn> is the canonical output format of the [[microformats2-parsing|microformats2 parsing]] algorithm. As such it can be used to compare parsers and create [[test-suite|test suites]]. It is also used as the official serialisation format of microformats objects, and relied upon by specifications such as [https://micropub.net/ Micropub].

<div style="margin:1em;padding:1em;background:#FFDC00;font-size:smaller">⚠️ The JSON format used is not pinned to a specific [https://indieweb.org/JSON#Specs JSON specification]. See [https://github.com/microformats/microformats2-parsing/issues/23 issue #23] for a discussion on the subject.</div>

== Parsed Document Format ==

Parsers collect not only microformats2 objects, but also [[rel|link relationships]]. Parsing an entire document will result in an outer object with 3 members named <code>items</code>, <code>rels</code>, and <code>rel-urls</code>:

<pre>{
"items": [],
"rels": {},
"rel-urls": {}
}</pre>

# <code>items</code> is an array of [[microformats2-json#microformat2_Objects|microformats2 objects]], ordered according to their order in the source document.
# <code>rels</code> is an object where the member names reflect all <code>rel</code>-values found in the source document.
# <code>rel-urls</code> is an object where the member names reflect all URLs found in the source document with <code>rel</code>-values attached.

== microformat2 Objects ==

The '''microformats2 object''' is an object with 2 required members named <code>type</code> and <code>properties</code>, as well as an optional member named <code>children</code>:

<pre>{
"type": [],
"properties": {},
"children": []
}</pre>

# <code>type</code> is an array of the types that identify the microformat, ordered alphabetically.
# <code>properties</code> is an object where the member names reflect all properties found for the microformat.
# The optional member <code>children</code> is an array of other microformats2 objects that were found nested in the current one.

=== type ===

<div style="margin:1em;padding:1em;background:#7FDBFF;font-size:smaller">ℹ️ '''This section is a stub.''' It needs an example of a microformats2 object that uses multiple types.</div>

The <code>type</code> member contains an alphabetically sorted array of root class names. These names express what the microformat is expressing, and are often coupled to which properties to expect through documented conventions.

The root class names are individual strings that match the pattern <code>h-([0-9a-z]+-)?[a-z]+</code>.

The following example shows an <code>h-entry</code> type microformats2 object, with a single property attached. The <code>h-entry</code> type is [[h-entry|documented on the wiki]], this way types point towards documented conventions that hold true no matter what the source document was.

<pre>{
"type": ["h-entry"],
"properties": {
"summary": ["A short published note."]
}
}</pre>

=== properties ===

The <code>properties</code> member contains an object where every member name is a microformats2 property name, and every member value is an array of the found microformats2 values. Even when only one value is given, it will be inside an array.

Valid values in the value array are one of the following:

# a string value, the most common value,
# an embedded markup object, containing both a plain string value and the verbatim mark-up from the source document, or
# another microformat2 object.

If a microformat2 object is used as the value of a property, it will gain the additional member <code>value</code> to express a plain string representation. If a consuming application does not understand the nested microformat2 object, it can opt to treat it as that string.

If a microformat2 object is used as the value of a property, when the parser is also instructed to return it as an embedded markup object, it will gain the additional member <code>html</code>.

The following example shows an <code>h-entry</code> type microformats2 object, with 3 properties to show the 3 different types of properties. The <code>name</code> is a single string, the <code>content</code> contains verbatim HTML from the source document, and the <code>author</code> is a nested microformat2 <code>h-card</code> object. The <code>in-reply-to</code> property has been added to show how one property may contain multiple valid values.

To see what these properties mean in the context of an <code>h-entry</code> type, see [[h-entry#Core_Properties|the Core Properties section on the type’s wiki page]].

<pre>{
"type": ["h-entry"],
"properties": {
"name": ["An example entry"],
"content": [
{
"html": "<p>Ut non sit saepe porro porro est aut. Dicta ut repellat quisquam repellendus et iste consequatur.</p>\n<p>Consequuntur repellat sed aut in et dolores. Consequatur amet quo enim.</p>",
"value": "Ut non sit saepe porro porro est aut. Dicta ut repellat quisquam repellendus et iste consequatur.\nConsequuntur repellat sed aut in et dolores. Consequatur amet quo enim."
}
],
"author": [
{
"type": ["h-card"],
"properties": {
"name": ["Mx Example"],
"url": ["https://example.com/"]
},
"value": "Mx Example"
}
],
"in-reply-to": [
{
"type": ["h-cite"],
"properties": {
"name": ["Example Domain"],
"author": ["IANA"],
"url": ["https://example.org/"]
},
"value": "https://example.org/"
},
"https://example.net/"
]
}
}</pre>

=== children ===

The optional <code>children</code> member is added when nested microformats are found and contains an array of microformat2 objects.

This happens when other objects are contained with outer ones, e.g. data is marked up with microformats within the content of an <code>h-entry</code>. Another possibility is that the outer object exists to group all its nested objects, such as an <code>[[h-feed]]</code>.

The following example shows an <code>h-feed</code> type microformats2 object with a few properties that describe the feed, and an array of <code>h-entry</code> objects as its children.

<pre>{
"type": ["h-feed"],
"properties": {
"author": ["https://example.org/"],
"name": ["Example Feed"]
},
"children": [
{
"type": ["h-entry"],
"properties": {
"name": ["Entry 1"],
"content": [
{
"html": "<p>Ut non sit saepe porro porro est aut.</p>\n<p>Dicta ut repellat quisquam repellendus et iste consequatur.</p>",
"value": "Ut non sit saepe porro porro est aut.\nDicta ut repellat quisquam repellendus et iste consequatur."
}
]
}
},
{
"type": ["h-entry"],
"properties": {
"name": ["Entry 2"],
"content": [
{
"html": "<p>Ut non sit saepe porro porro est aut.</p>\n<p>Dicta ut repellat quisquam repellendus et iste consequatur.</p>",
"value": "Ut non sit saepe porro porro est aut.\nDicta ut repellat quisquam repellendus et iste consequatur."
}
]
}
},
{
"type": ["h-entry"],
"properties": {
"name": ["Entry 3"],
"content": [
{
"html": "<p>Ut non sit saepe porro porro est aut.</p>\n<p>Dicta ut repellat quisquam repellendus et iste consequatur.</p>",
"value": "Ut non sit saepe porro porro est aut.\nDicta ut repellat quisquam repellendus et iste consequatur."
}
]
}
}
]
}</pre>

== rels Object ==

<div style="margin:1em;padding:1em;background:#7FDBFF;font-size:smaller">ℹ️ '''This section is a stub.''' You can help the microformats.org wiki by expanding it.</div>

== rel-urls Object ==

<div style="margin:1em;padding:1em;background:#7FDBFF;font-size:smaller">ℹ️ '''This section is a stub.''' You can help the microformats.org wiki by expanding it.</div>

== See Also ==

* [https://tools.ietf.org/html/rfc8259 RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format]
* [https://gist.github.com/Zegnat/65ed9a9fb0546fb8c4aa0c0b790b8a40 JSON Schema for microformats2 objects], by [https://vanderven.se/martijn/ Martijn van der Ven]
* [https://github.com/cleverdevil/microformats2 Type- and vocabulary-aware microformats2 JSON validator in Python], by [https://cleverdevil.io/ Jonathan LaCour]
* [http://microformats.org/wiki/microformats2-parsing-brainstorming#more_information_for_rel-based_formats the thinking behind rels and rel-urls]

sharelink-formats

2017-09-21T12:29:44Z

Kevin Marks: /* examples */ bookmarklet links

<entry-title>sharelink formats</entry-title>

Part of the Sharelink effort.

[https://twitter.com/cramforce/status/822184263172796416 Malte Ubl ‏@cramforce Jan 19]
*specifically we’d like to propose <link rel=share> (or similar name) to provide preference of shared URL for a given page.
Per the microformats [[process]] this page is here to document previous formats for pages publishing share links for themselves.

{{stub}}

== examples ==
* [[rel-canonical]]
** [https://twitter.com/adactio/status/822253267665252356 Jeremy Keith ‏@adactio]<br> @cramforce Is this not already covered by rel="canonical"?
** [https://twitter.com/cramforce/status/822254953985019904 Malte Ubl ‏@cramforce]<br> @adactio we’d fallback to that, but people want to override it for some legit and less legit reasons.<br>people sometimes use canonical to point to an entirely different publication that was the original source of the content.<br>and others want to do share tracking with #.1234 style URLs (see e.g. @Medium URLs).
** [https://twitter.com/kevinmarks/status/822257980049485824 Kevin Marks ‏@kevinmarks] <br> @cramforce @adactio @Medium or google inspired &utm_source things
** [https://twitter.com/rmondello/status/910276001300488192 Ricky Mondello‏ @rmondello] <br>Safari on iOS 11 will share the canonical link for a page, which can improve the experience of sharing a "mobile" website.
** [http://known.kevinmarks.com/2017/day-7-to-amp-or-not-to-amp-100daysofindieweb bookmarklets for switching to or copying canonical links]

*[http://microformats.org/wiki/h-entry#Draft_Properties u-repost-of]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?

* [[rel-bookmark]]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?<br>rel-bookmark is already in the [https://www.w3.org/TR/html51/links.html#link-type-bookmark html5 spec], and in lots of CMSs, including WordPress …
** [https://twitter.com/cramforce/status/822264992992927744 Malte Ubl ‏@cramforce] <br>@kevinmarks @adactio I think bookmark comes pretty close. Not quite the same, but close.

* [[rel-shortlink]]
** https://twitter.com/voxpelli/status/822378518902239233 [Pelle Wessman ‏@voxpelli] <br>@cramforce @kevinmarks @adactio There's also rel-shortlink which is often used for sharing + is widely supported

*rel=self
** the [https://tools.ietf.org/html/rfc4287#section-4.2.7.2 Atom Link element] defines rel="self" as
The value "self" signifies that the IRI in the value of the href
attribute identifies a resource equivalent to the containing
element.

== see also ==
* [[sharelink-examples]]

rel-canonical

2017-09-21T12:12:31Z

Kevin Marks: /* rel-amphtml */ typo

<entry-title>rel-canonical</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Kevin Marks|Kevin Marks]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">rel=canonical</dfn> is a link relation to indicate the canonical URL of the current page, to avoid duplicate content.

{{cc0-owfa-license}}

== Abstract ==
<p class="entry-summary">By adding <code>rel="canonical"</code> to a hyperlink, a page indicates that the destination of that hyperlink {{should}} be considered the preferred or definitive version of the current page. This helps search engines avoid duplicate content, and is useful for deciding how to link to a page when citing it.</p>

== Discussion ==
There are many reasons for a site to serve the same content at multiple URLs, but duplicate pages are undesirable in search results. The [https://www.mattcutts.com/blog/seo-advice-url-canonicalization/ historic recommendation] was to use 301 redirects to the canonical page, but that can be jarring for users. There are many use cases for a URL to have additional information added as query parameters or fragments to indicate the navigation history for referral purposes, but would prefer a single main referent from searches. This was codified in February 2009 as rel=canonical, and [https://webmasters.googleblog.com/2009/02/specify-your-canonical.html adopted] by [http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ many] [https://blogs.msdn.microsoft.com/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx search] [https://web-beta.archive.org/web/20091008070823/http://blog.ask.com/2009/02/ask-is-going-canonical.html engines].

Search engines prefer <code>rel=canonical</code> on a <code><link></code> element, and will [https://www.mattcutts.com/blog/rel-canonical-html-head/ ignore it] on an <code><a></code> element.
=== Cross-domain links ===
Although the primary use case is links within the same domain, rel=canonical can be used [https://webmasters.googleblog.com/2009/12/handling-legitimate-cross-domain.html across domains] too. A common use case recently is from [https://www.ampproject.org/docs/guides/deploy/discovery cached AMP pages] to their original.
== The opposite of canonical ==
There are several ways of indicating non-canonical versions of a page, depending on what is intended. A non-comprehensive list
=== rel-syndication and u-syndication ===
[[rel-syndication]] and [http://microformats.org/wiki/h-entry#Core_Properties u-syndication] link to copies that the author has syndicated or shared onto other sites. The syndicated copies {{should}} have a rel-canonical link back to the original if the other site allows it.
=== rel-alternate===
[[rel-alternate]] is used to link to versions of the page in other forms, whether a different format with <code>type</code>, language with <code>hreflang</code> or presentation medium with <code>media</code>.
=== rel-amphtml ===
[[rel-amphtml]] is used to link to the Accelerated Mobile Pages version, a html subset limiting javascript, replacing built-in elements with custom elements and designed for caching. It is [https://www.ampproject.org/docs/guides/deploy/discovery recommended] to link back from the AMP version to the original with rel-canonical

=== rel-shortlink ===
[[rel-shortlink]] is used to link to a url shortened version designed for sharing and (often) tracking.
=== rel-me ===
[[rel-me]] is explicitly saying that another domain or page represents the same person or organisation as the current page. As such it is a different level of abstraction from rel-canonical, as it refers to the representation rather than the content.
=== rev-canonical ===
A deprecated way of linking to a short link, briefly [https://revcanonical.wordpress.com/ popular], [https://www.mnot.net/blog/2009/04/14/rev_canonical_bad disliked] and not recommended.

== Issues ==
* See https://github.com/whatwg/html/issues/2351

== See Also ==
* [[existing-rel-values]]
* https://en.wikipedia.org/wiki/Canonical_link_element
* [https://support.google.com/webmasters/answer/139066?hl=en Google's canonical advice page]
* [http://known.kevinmarks.com/2017/day-7-to-amp-or-not-to-amp-100daysofindieweb canonical bookmarklets]
* [[sharelink-formats]]
* [https://tools.ietf.org/html/rfc6596 RFC 6596 - The Canonical Link Relation]

sharelink-formats

2017-09-21T12:10:48Z

Kevin Marks: /* examples */ Safari 11 sharing canonical link

<entry-title>sharelink formats</entry-title>

Part of the Sharelink effort.

[https://twitter.com/cramforce/status/822184263172796416 Malte Ubl ‏@cramforce Jan 19]
*specifically we’d like to propose <link rel=share> (or similar name) to provide preference of shared URL for a given page.
Per the microformats [[process]] this page is here to document previous formats for pages publishing share links for themselves.

{{stub}}

== examples ==
* [[rel-canonical]]
** [https://twitter.com/adactio/status/822253267665252356 Jeremy Keith ‏@adactio]<br> @cramforce Is this not already covered by rel="canonical"?
** [https://twitter.com/cramforce/status/822254953985019904 Malte Ubl ‏@cramforce]<br> @adactio we’d fallback to that, but people want to override it for some legit and less legit reasons.<br>people sometimes use canonical to point to an entirely different publication that was the original source of the content.<br>and others want to do share tracking with #.1234 style URLs (see e.g. @Medium URLs).
** [https://twitter.com/kevinmarks/status/822257980049485824 Kevin Marks ‏@kevinmarks] <br> @cramforce @adactio @Medium or google inspired &utm_source things
** [https://twitter.com/rmondello/status/910276001300488192 Ricky Mondello‏ @rmondello] <br>Safari on iOS 11 will share the canonical link for a page, which can improve the experience of sharing a "mobile" website.

*[http://microformats.org/wiki/h-entry#Draft_Properties u-repost-of]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?

* [[rel-bookmark]]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?<br>rel-bookmark is already in the [https://www.w3.org/TR/html51/links.html#link-type-bookmark html5 spec], and in lots of CMSs, including WordPress …
** [https://twitter.com/cramforce/status/822264992992927744 Malte Ubl ‏@cramforce] <br>@kevinmarks @adactio I think bookmark comes pretty close. Not quite the same, but close.

* [[rel-shortlink]]
** https://twitter.com/voxpelli/status/822378518902239233 [Pelle Wessman ‏@voxpelli] <br>@cramforce @kevinmarks @adactio There's also rel-shortlink which is often used for sharing + is widely supported

*rel=self
** the [https://tools.ietf.org/html/rfc4287#section-4.2.7.2 Atom Link element] defines rel="self" as
The value "self" signifies that the IRI in the value of the href
attribute identifies a resource equivalent to the containing
element.

== see also ==
* [[sharelink-examples]]

h-feed

2017-09-12T23:41:53Z

Kevin Marks: /* Parser Compatibility */ wordpress suggestions

<entry-title>h-feed</entry-title>

<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a simple, open format for publishing a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts. h-feed is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-feed is the [[microformats2]] update to [[hAtom]], and in particular its "hfeed" root class.

{{cc0-owfa-license}}

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Status ==
'''h-feed''' is a microformats.org draft specification. Public discussion on h-feed takes place on [[h-entry-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

== Use Cases ==
* Named feeds
** IndieWeb Readers are consuming home page feeds marked up with h-feed and using the name of the h-feed in their user interfce.

* Generate an Atom feed
** This seems like a legacy use-case, not sufficient to actually justify h-feed.

* Feed per channel of content - needs a name
** "I will have a feed per tag (channel) so I want to name them." - Sandeep Shetty in #indiewebcamp
** It appears there is some desire to create separate feeds for an indieweb site for separate subsets of content, and name them <em>explicitly</em> accordingly. This presents a need for a container object for the h-entry elements, where the container itself can have a name. This is a potential interesting use-case for an explicit 'h-feed'.

== Examples in the wild ==
Add any examples in the wild that you find to the top of this list.
* ...
* http://sandeep.io/ uses h-feed with p-name and p-author properties and child h-entry posts. In particular using h-feed on the <html> element allows using p-name on the <title> element and re-using the visible window title of the HTML page as the name of the feed, neatly avoiding a [[DRY]] violation.
* http://tantek.com/ uses h-feed with p-name and p-author properties and child h-entry posts.

== Implementations ==
=== Readers ===
* [https://github.com/kylewm/woodwind Woodwind]
* [https://github.com/barnabywalters/shrewdness Shrewdness]
* http://notenoughneon.com/feed.php (404 as of 2017-05-29)

=== Proxies ===
* Bridgy

=== Converters ===
* '''[http://unmung.com unmung]''' - will transform an RSS or Atom feed into an [[h-feed]] containing h-entries,
* '''[http://pipes.yahoo.com/pipes/pipe.info?_id=afc5568b4e8643bfb05436b1caaf91bc microformats to RSS]''' - a Yahoo! pipe that converts a URL containing an [[h-feed]] containing h-entries, into an [[RSS]] feed. ([http://waterpigs.co.uk/notes/4SeNi5/ 2013-10-21 blog post announcing])

== Backward Compatibility ==
=== Publisher Compatibility ===
(this section is a stub and needs to be expanded with real world examples and minimal properties)

=== Parser Compatibility ===
When <span id="Parsing">parsing</span> a page for an h-feed, in addition to just following the [[microformats2-parsing]] specification, implementations may do the following for backward compatibility with existing [[hatom|hAtom]] content.

(this section is a stub and needs review and citations to note what real world examples would each of these rules actually help parse)

If there is no explicit "h-feed" element, implementations may:
* Treat the <code><title></code> of the page or the URL of the page as the p-name
* Use https://indieweb.org/authorship to discover authorship of posts.
* Treat top level [[h-entry]] elements as items in the feed.

If there is a "hfeed" element, implementations may:
* Treat site-title as p-name [wordpress has this by default, and without it implied p-name will be the whole feed]
* Treat site-description as p-summary [wordpress has this by default]

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">sandeep.io</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-feed-issues]]
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

plant-examples

2017-09-06T12:25:24Z

Kevin Marks: Undo revision 66542 by spammer Bendyman (Talk)

= Plants Examples =
Proposing a microformat to describe a particular plant, classified by its latin name. Plants all have common attributes associated with them related to appearance, growing conditions, disease, pests, maintenance etc. Many websites publish information about plants, but as yet this information is not open to exchange and aggregation.

== The Problem ==
To collect information on the current status of plant related information on the web.

Here are a few possible applications:

* Collection of distributed plant information from the web into larger plant databases. There is a lot of information currently available on the web both in large plant databases and indivual's sites, but there is no way to efficiently build a reference material on top of this.
* Plant catalogs can be published by retailers and the information about what can be bought where, can be easily aggregated.
* Building up personal catalogs of plants, so I can have a customized view on my own plants that I grow, telling me more about them.

== Participants ==
* Mark Gibbons
== Real-World Examples ==

=== [http://www.crocus.co.uk/findplant/ Crocus] ===
Crocus is an plant catalog containing listings of plants available for purchase online. Many nurseries and garden centers now offer online purchasing possibilities. There are hundreds if not thousands of similar sites currently online, both big and small. Other examples are:

* [http://www.stokeseeds.com/cgi-bin/StokesSeeds.storefront Stokes Seeds]
* [http://www.gardenexpress.com.au/ Garden Express]
* [https://www.fernview.com.au/orderform.php Fernview]
* [http://www.ashridgetrees.co.uk Ashridge Hedging & Trees]
* [http://www.diggingdog.com/pages2/catalog.php Digging dog nursery]
* [http://www.bluegrassgardens.com/ Bluegrass Gardens Nursery]

=== [http://growstuff.org/ Growstuff] ===

Growstuff is one of a number of open source gardening and agriculture projects. You can find several others listed on [http://wiki.growstuff.org/index.php/Similar_projects Growstuff's similar projects list] and [http://www.openfoodfoundation.org/document/open-source-food-projects-list-wiki Open Food Foundation's list].

Growstuff has a [http://growstuff.org/crops crop database] of edible plants, and allows members to record what they have planted and harvested (like a garden journal), keep track of what seeds they have, etc. Each crop page has basic information about the crop (name, scientific name(s), etc) as well as planting and growing information aggregated from members' garden journals (eg. "plant in full sun or semi shade", "plant from seedling or root division"). Planting information, though at present global, is intended to be offered specifically for local environments -- a crop that grows in full sun in a cool temperate climate may require shade in a warmer one. Similarly, planting dates vary widely according to hemisphere and climate.

One important point to note is that species identifiers are highly problematic for gardeners, especially when it comes to food crops, as many food crops share a species. For instance, all varieties of lettuce are the same species, as are all varieties of tomato. All chilli/pepper varieties are just 4 species, all squashes (from zucchini to giant pumpkins) share just 3 species, etc. Even subspecies/varieties/etc don't work, as for instance kale and collard greens are both "Brassica oleracea var. acephela". These distinctions are important to food gardeners and cooks, though presumably not to biologists.

=== [http://www.paghat.com/garden.html Paghat's Garden] ===

Paghat's garden is an individual's site, documenting the plants grown in one garden. It is a good example of a gardener sharing useful information via the website. Currently the amount of information shared on the internet by individual gardener's on there own site or via a blog is limited. Given the right tools and incentives, the sharing of information in this way will increase.

=== [http://www.davesgarden.com/ Dave's Garden] ===

=== [http://www.bbc.co.uk/gardening BBC Gardening] ===

The BBC maintains a large database of plants for use in their gardening site. Information from the "[http://www.bbc.co.uk/gardening/plants/plant_finder/index.shtml plant finder]" contains:

*Common Name: Blue African lily
*Genus: Agapanthus
*Cultivar: 'Lilliput'
*Skill Level: Beginner
*Exposure: Full sun
*Hardiness: Hardy
*Soil type: Well-drained/light, Moist
*Height: 40cm
*Spread: 40cm
*Time to divide plants: March to April
*Flowering period: August to September

*Description:
Standing at only 40cm (16in) high, 'Lilliput'is perfect for smaller gardens and patio containers. Its trumpet-shaped rich blue flowers add a touch of the exotic to displays from mid- to late summer. Grow in moist but well-drained soil in a sunny spot. In colder areas, put on a dry mulch for winter.

([http://www.bbc.co.uk/gardening/plants/plant_finder/plant_pages/3553.shtml Blue African Lily example source])

== Existing Practices ==
* Botanical names are often used as the title. More on botanical names [http://www.rhs.org.uk/rhsplantfinder/plantnaming.asp here].
* Common attributes are readily identifiable. Such as
** water requirements
** light requirements
** temperature requirements
** plant type (tree, shrub, perrenial)
** soil requirements
* Some of the above attributes have been standardized already such as [http://www.usna.usda.gov/Hardzone/ushzmap.html temperature requirements], others vary more, but have common features.
* Plant appearance is often described as free text.
* Images are often associated with plants.
* ''Other attempts to solve The Problem''

== Proposal ==
* Early drafts
* ''Link to related pages as they become available''
** -brainstorming
** - proposal
** -microformat
== See Also ==
* ''Other microformats''
* ''Normative references for tags used''
* [[species]]
:Proposed scheme for marking up scientific names. If adopted, a plant microformat (with care regime, supplier, etc.), could contain a scientific name microformat, in the same way that an [[hCalendar]] can contain an [[hCard]].

faq

2017-08-01T14:52:00Z

Kevin Marks: /* Q. Why don't microformats use the HTML5 data- attributes to embed data? */ update refs; typo

<entry-title> Microformats FAQ </entry-title>

This page document frequently asked questions about microformats. For frequently asked questions from the [[press]], see [[press-faq]].

If you're looking for a microformat for marking up FAQs, see [[question-answer]].

== How To ==
=== What microformats should I use to markup my blog ===
''What microformats should I use to markup my blog?''

A: Use a classic [[microformat]] on the body of each page. For your index page, use an [[h-card]], since it's about you, and an [[h-feed]] for any recent updates you post there. For your individual permalink pages, use [[h-entry]].

For all of the data on your pages, use [[microformats2]].

From: http://indiewebcamp.com/faq#How_should_I_markup_my_blog

=== When should I use microformats2 over microformats1 ===
''On sites that don't currently have microformats, should microformats2 be utilized in favor over v1? E.g. for a rather large site.''

A: [[microformats2]] use less markup (are even simpler) than microformats1, so in general it's preferred for adding to sites.

However, you may want to add one v1 microformat for each page that describes the primary subject of the page.

You can easily use both:
* if a page is about a '''person''' or '''company''', add an '''[[hCard]]''' (and '''[[h-card]]''') to markup the info about the person/company.
* Or if the page is for an '''event''', add an '''[[hCalendar]]''' (and '''[[h-event]]''') about the event info.
* Similarly with a page that is a '''[[hReview|review]], [[hProduct|product]], [[hAtom|blog post]], or [[hRecipe|recipe]]'''.
See the [[Main_Page#Specifications|list of specs and drafts]] for more recommended top level microformats.

For all other references to things on the page, links to or mentions of [[h-card|people]]/[[h-event|events]]/[[h-cite|citations]]/products, etc. use microformats2.

=== What microformats should I use for backward compatibility ===
For backwards compatibility, e.g. with some [[search-engines]], it's sufficient to include one v1 microformat for each page that best describes what that page is about. See above '''When should I use microformats2 over microformats1''' for more details.

== Common Details ==
=== Can you mix properties and the root class name ===
''<span id="nesting-properties">Can you put properties on the same element as the root class for a microformat? E.g. span class="h-card p-org"?</span>''
* No, because property elements must be inside the root class name element.

It will result in more confusion for parsers which may be parsing nested microformats. In this case in the question, you need two elements:
* WRONG: <code><span class="h-card p-org"></code>
* RIGHT: <code><span class="h-card"><span class="p-org"></code>

The only time you can put a root class name (like "h-card") and a property class name on the same element, is when the root class name is providing an entire object as the embedded value of that property which then belongs to some other object higher up the tree.

E.g. using an h-card for the location of an h-event

<source lang=html4strict>
<span class="h-event">
<span class="p-name">HTML5 Developer Conference</span>,
<time class="dt-start">2013-04-01</time>...<time class="dt-end">2013-04-03</time>, at
<span class="p-location h-card">
<span class="p-name p-org">The Palace Hotel</span>,
<span class="p-locality">San Francisco</span>
</span>
</span>
</source>

Note the <code><span class="p-location h-card"></code> which specifies that the location of the outer [[h-event] is an entire [[h-card]] nested inside.

Another example, inside an [[h-entry]], specifying the author as an h-card: <code><span class="p-author h-card"></code>

Derived from: [[hcard-faq#Can_you_mix_properties_and_the_root_class_name]]

== Wiki specific questions ==
===Q: ''How do I create a username? Why won't it let me use my preferred username?''===

A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to capitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing.

== Email list ==
=== Why do I get You are not allowed to post to this mailing list ===
''' ''Q: I've tried sending email to the mailing list. Why do I get a bounce message stating: "You are not allowed to post to this mailing list. ..." ? '' '''

A: You must first subscribe to the microformats mailing list that you are trying to post to.

===Q: ''I've joined the discussion mailing list but am not seeing my replies anywhere. Why?''===

A: There is no moderation on microformats-discuss, but it only accepts posts from subscribers. You MUST post to microformats-discuss using the email address you used to subscribe.

===Q: ''What does "The message's content type was not explicitly allowed" mean?'' ===

A: Please go read [http://microformats.org/mailinglists-policies/ mailinglists-policies]. In particular note:
<blockquote>
'''No HTML or RTF e-mail''' period, end of story, full stop. Your mail client should let you configure it so you can send plain text messages. Make use of this ability or else there are no guarantees that anyone will be able to read your email.
</blockquote>
The mailing lists are set up to automatically reject email that is sent as text/html. Thus please configure your email client to send plain text (text/plain) email.

== Basic Microformat Questions ==
===Q: ''Who uses microformats?'' ===

A: See a list of [[examples-in-wild|sites using microformats]] and [[implementations|numerous tools]] that support microformats.

===Q: ''When should I use a microformat? What are they for?''===

A: You are writing some HTML that contains useful human-readable information (such as a piece of contact information). You say to yourself: I would like to mark this up with some classes now for styling. You look up the relevant microformat, and you
pull in the standard names. You don't have to make your own up, and now your page is machine-readable too. Bonus!

Microformats are designed to make the data you already publish for humans available to machines. It allows applications as simple as cut-and-paste or as complex as a search engine to use your data effectively.

===Q: ''Should I use microformats or microdata?'''===

A: '''microformats''' require less markup, are easier to learn for common cases like [[hcard-authoring|people]]/[[hcalendar-authoring|events]]/[[get-started|etc.]], and are supported by more [[tools]] including [[search-engines]].

If you're looking for minimal markup addition, just use microformats.

If you want to use both to cover all your bases, you can do so because they don't interfere.

===Q: ''Are microformats dependent upon (X)HTML?''===

A: Microformats are made to be embeddable. They can be embedded in (X)HTML, RSS, Atom or anywhere (X)HTML is allowed.

===Q: ''Microformats sound great. How can I help?''===

A: Take a look at [[get-started]] for how to implement microformats yourself, and the [[to-do]] list for things to help out with. See http://microformats.org/discuss to see some ways to join the conversations about microformats.

===Q: ''I'd like to make a donation to the microformat cause. How can I do this?''===

A: Thank you for your willingness to support microformats. microformats.org is an all volunteer unpaid organization, and sponsor contributions really help the community. There are several ways to support microformats with donations:
<div class="discussion">
* Donate to a microformats [[open source]] effort, e.g.
** [https://addons.mozilla.org/en-US/firefox/addon/4106/developers DONATE to Operator] - an essential [[Firefox]] extension
* Sponsor a microformats [[weekly meetup]].
** Watch the [[events]] page for a weekly meetup near you, participate and sponsor dinner and or drinks!
* Sponsor a microformatsDevCamp like the [[events/2009-07-25-dev-camp|recent devCamp in SF]].
** Watch the [[events]] page for upcoming devCamps, vEvents, and other similar opportunities to sponsor.
</div>

===Q: ''Which microformats have been implemented?'' ===

A: See the [[implementations]] page.

===Q: ''Which microformats should I implement?''===

A: Chances are you that your website already has data very similar to several microformats. For example, you probably have people and/or their contact information somewhere. That information could be marked up with [[hcard|hCard]], see the [[hcard-authoring|hCard authoring]] page for step by step instructions. If you are publishing press releases, try using [[hatom|hAtom]].

===Q: ''Do you have any link badges I can add to my website/blog?''===

A: There are some [[buttons]] but we can certainly use more! Please contribute what you come up with!

===Q. ''Are there any tools that support microformats?''===

A. Yes...tons... [[implementations]].

===Q. ''What is the 'h' for, in front of Calendar and Card?'' ===
''What's the meaning of the 'h' before the [[hCalendar]] and [[hCard]] microformats?''

A. hCard and hCalendar are the <strong>H</strong>TML versions of vCard and iCalendar, hence the replacement of the leading lowercase 'v' or 'i' with 'h'. Origins: <cite>[http://tantek.com/log/2004/09.html#d30t1725 Tantek's Thoughts: "Semantic XHTML" slides posted]</cite>.

See the [[hcard-faq|hCard FAQ]] and the [[hcalendar-faq|hCalendar faq]] for more specific questions on those microformats.

===Q. ''Is there a way to indicate that a given web page contains markup that conforms to one or more microformats?'' ===

A. The HTML HEAD element's '<code>profile</code>' attribute alerts applications to the potential presence of microformats. The [http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3 W3C HTML Specification] describes more about the profile attribute, and the [http://gmpg.org/xmdp/description XMDP description] documents how it is used.

===Q: ''What do these specific jargon terms mean?''===

A: See our [[glossary]].

===Q. ''What about using new URI schemes instead of class names, e.g. for geo information?''===

A. In general, it is more work, and less content-publisher friendly, to ask publishers to use URI schemes instead of class names.

Authors aren't publishing links to geo information.

They're publishing *visible text* of [[geo]] information.

So the easiest thing to do, for the author, is to leave it as visible text.

Thus, it makes the most sense to do the simple thing of just wrapping that
visible text with a little bit of markup, rather than asking the author to
move (or copy) it into an attribute, which may or may not require a
reformatting of the data as well.

It would make sense from a usability persepective to hyperlink geo information to a maps page or something, so that clicking it actually does something. If you forced them to use a hypothetical "geo:" protocol instead, then that would interfere, since you can only hyperlink something to one destination.

===Q: ''Who controls microformats?''===

A: An open community. Microformats are open standards originally licensed under Creative Commons Attribution, and placed into the [[Microformats_Wiki:Copyrights|public domain since 2007-12-29]]. Much of the work here was begun on [http://developers.technorati.com/wiki Technorati's Developer Wiki], and Technorati contributed the work done there to the microformats community when microformats.org was established. The microformats.org domain is registered to Rohit Khare (see [http://whois.uberdose.com/microformats.org Whois microformats.org]), CommerceNet is graciously hosting the servers, but claims no control over microformat standards. Anyone may follow the established [[process]] and contribute towards the development of microformat standards.

Any required [[governance]] (and very little ''has been'' required) of the microformats [[IRC]] channel, wiki, and [[mailing lists]] is discussed by a group of volunteer [[administrators]].

===Q: ''Who is the registrar for microformats?''===

A: There is no central registry. Microformats are registered in a distributed manner using profiles. For more information on profiles see http://microformats.org/wiki/profile-uris and http://gmpg.org/xmdp/

Conflicts and interoperability are managed through social processes rather than a formal registry. Current microformat profiles can be found at http://gmpg.org, http://w3.org, and http://microformats.org.

===Q: ''So multiple microformats with the same name can be valid?''===

A: Yes. The community at microformats.org can hopefully play a role in determining which is preferred by bringing interested folks together in one place and helping them resolve that question. As long as each microformat maintains a valid profile, each can be used effectively.

===Q: ''How do I validate my microformated content?''===

A: See [[validators]] for a list of microformats validators.

===Q: ''Why do microformats use English terms for property names?''===
A: Similar to how HTML uses English words like "class", "span" or "head", microformats re-uses English words for property names. As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats. See also [[internationalization]] and the [[en-us-faq#why_not_use_other_spellings_and_languages_for_properties|en-US FAQ: why not use other spellings and languages for properties]] regarding the question of alternate (non-English) names in other (natural) languages, and mappings.

===Q: ''How come microformats stay as drafts even though they seem usable?'' ===

A: This was discussed at the [http://2007.sxsw.com/interactive/programming/panels/?action=show&id=IAP060234 The Growth and Evolution of Microformats] panel at [http://en.wikipedia.org/wiki/South_by_Southwest SXSW] 2007. The basic answer is it was important to at least have a basic software implementation -- even an experimental one -- before moving a format from Draft to Specification. It can sometimes be hard to recognize subtle inconsistencies within a format by eye; however, in the process of implementing a format-reader in code, inconsistencies (if any) can become much more noticeable (due to [[dry | DRY / Don't Repeat Yourself]], among other programming best practices). Then, once such tools have been created (in effect, confirming both the programmability of the format, and interoperability across tools), it can be considered for transition to a Specification. Using interoperable implementations as a measure of format quality is a long-standing practice of IETF and W3C.

== Creating and Suggesting New Microformats ==

===Q. ''I would like to author a new microformats open standards specification for my site/business. How do I get started?''===

A. The first thing to do before attempting a new microformat open standard is to make as much use of [[POSH]] and existing [[microformats]] open standards as possible in whatever site you are looking to mark up with your new microformat, as a way of learning what is left to be done. That is, at a minimum first:
* Mark up all people and organizations as [[hcard|hCards]] and add those pages to [[hcard-examples-in-wild]]
* Mark up all events and time based things as [[hcalendar|hCalendar]] events and add those pages to [[hcalendar-examples-in-wild]]
* Mark up all reviews as [[hreview|hReviews]] and add those pages to [[hreview-examples-in-wild]]
* etc.
Then join the microformats [http://microformats.org/discuss IRC channel and discuss list], and ask folks what they think of your use of the microformats and if it can be improved.

From that experience you will then be able to figure out what is left to be specified. Otherwise it is too hard to approach the "whole problem".

Once you have completed that, take a look at the microformats [[process]] for how to walk through the steps of creating a new microformat, and note the specific problem you are trying to solve to the microformats-discuss list. This will help you find more people to help you solve the problems you are trying to solve.

===''Q How do I know if an idea for a Microformat has already been suggested in the past?''===

A. Check the list of proposed and rejected microformats.
* [[rejected-formats]]

===Q. ''What if I can't find real-world examples of a standard I'd like to propose?''===

A. If we can't find real-world examples of the '''types of data''' a proposal would address, it's probably not suitable for a microformat. If we only can't find real-world examples of the '''specific markup''' a proposal would use for that data, however, that's not really a problem. It's actually the lack of such standard markup in real-world publishing around a specific problem that suggests the need for increased consensus.

== Specific Microformat Questions ==
If you have a question regarding a specific microformat, you may want to check the FAQ specific to that microformat.
* [[hatom-faq]]
* [[hcalendar-faq]]
* [[hcard-faq]]
* [[hreview-faq]]
* [[rel-faq]]
* [[rel-tag-faq]]
* [http://gmpg.org/xfn/faq xfn-faq]
* [[xfolk-faq]]
* [[xmdp-faq]]
* [[xoxo-faq]]

== Class interactions ==
===Q. ''Are there issues with page styling when specific class values are used?''===

A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors.

===Q. ''How does the use of class values for semantics interact with the use of class values for attaching CSS styles?''===

A. The class attribute takes a space separated set of class names [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 HTML4 reference]. Thus both author and microformat defined class names may be used in the same class attribute. In addition, microformat class names provide the author with a consistent set of class names to use for styling. If the author is already using using specific class names, they can continue to do so, and include microformat class names. If the author is already using a class name that happens to also be a microformat class name, then the author may want to consider using contextual CSS class selectors to make sure that avoid any unintentional styling effects.

See also:
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://tantek.com/log/2004/07.html#classmeaningnotshow Class For Meaning Not For Show]
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute.

===Q. ''Are class names case sensitive?'' ===

A: Yes, HTML class names (i.e. as used in microformats) are case-sensitive.

By [[naming-principles#Some_Details|convention]], microformats use all lowercase classnames similar to CSS's approach. This way authors never have to guess about the capitalization of microformats properties - they're always all lowercase.

== <code><div></code> and <code><span></code> semantics ==

=== Q. ''Can microformats use other elements besides divs?'' ===
A. Yes. Markup with microformats should use the most appropriate semantic HTML. For example if the name of an organization hCard is a top level heading, then: <p><code><div class=vcard><br/><strong><h1 class="fn org">ACME Co.</h1></strong><br/></div></code></p> is more appropriate than <p><code><div class=vcard><br/><strong><div class="fn org">ACME Co.</div></strong><br/></div></code></p>

=== Q. ''Is it semantically meaningless to use divs?'' ===

A. Yes, both <code><div></code> and <code><span></code> have nearly no semantics. <code><div></code> can be used to represent a "division" of the page content. Similarly <code><span></code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code><span></code>.

=== Q. ''Does the use of <code><div></code> and <code><span></code> elements add any semantics to web pages?''===

A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 HTML 4 spec], <code><div></code> and <code><span></code> "offer a generic mechanism for adding structure to documents." Their only meaning is in dividing documents into sections, and as such, their presence implies that the content within has a specific, but undefined by the element markup, semantic. Thus they are nearly semantic-free.

=== Q. ''Why do the examples on the wiki use <code class="element"><span></code> and <code class="element"><div></code> for nearly everything?''===

A. <code class="element"><span></code> and <code class="element"><div></code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available for the semantics you are trying to express. You might, for example, apply <code>class="vevent"</code> to a <code><nowiki><tr></nowiki></code>, or <code>class="vcard"</code> to a <code><nowiki><p></nowiki></code>. Here is an example using more [[semantic HTML]] with a definition list to mark-up an hCard:
<source lang=html4strict>
<dl class="vcard">
<dt class="category">Restaurant</dt>
<dd class="fn org">
<a class="url" href="http://www.yelp.com/biz/crepes-n-more-fairfield">Crepes N More</a>
</dd>
<dt>Address</dt>
<dd class="adr">
<span class="street-address">620 Jackson st.</span>,
<span class="locality">Fairfield</span>,
<abbr class="region" title="California">CA</abbr>,
<span class="postal-code">94533</span>,
<abbr class="country-name" title="United States of America">USA</abbr>
</dd>
<dt>Phone</dt>
<dd class="tel">+1.707.428.2210</dd>
</dl>
</source>

== Class semantics ==

===Q. ''How will microformat class names impact page size?''===

A. You probably won't notice any impact on page size when authoring with microformats. Our experience is that people use comparably sized class names, and [[semantic-class-names|semantic class names]] are now considered an industry best practice. Some sites are successfully publishing millions of microformats, and we haven't heard any complaints yet. You are more likely to gain space savings by more fully adopting [[microformats#the_microformats_principles|the principles of microformats]], and eliminating tables for layout.
<span class="todo">''TODO: Consider creating a new section for web authoring tips? Or at least linking to another site that advocates good authorship.''</span>

===Q. ''Can an element have more than one class''===

A. Yes, the class attribute can contain a space delimited list of classes. For example:
<p class="todo idea">Write high quality and simple mark-up.</p>

See W3C HTML 4.01 Specification: [http://www.w3.org/TR/html401/struct/global.html#adef-class 7.5.2 Element identifiers: the id and class attributes]

===Q. ''Does the order of class names matter?'' ===
A. No. The HTML class attribute is an unordered space separated set of class names. The order of classes in an class attribute do affect their meaning or use. E.g. these two divs' class names are equivalent:
<source lang=html4strict>
<div class="a b">...</div>
<div class="b a">...</div>
</source>

===Q. ''Do (X)HTML class names have semantics?''===

A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ XMDP] is a format for defining meta data profiles for (X)HTML, and thus an XMDP profile can be used to define the meanings of class names.

See also:
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]

===Q. ''I thought one of the main goals of CSS was to separate data from presentation. Isn’t this sneaking presentation back into data?''===

A. This is a quite commonly expressed objection to the way microformats uses class, but it's based on a misunderstanding of the way the class attribute in HTML was designed. Yes, class is very commonly,and appropriately used by web designers in conjunction with CSS to style pages, and in truth, it is often overused for that, but despite this, class, according to the HTML specification "has several roles in HTML", including [http://www.w3.org/TR/html4/struct/global.html#h-7.5.2 "for general purpose processing by user agents"].

Microformats utilize this second aspect of the class (and id) attribute, and do so legitimately. It is not an abuse of the class or id attribute to use it to add semantic context to a document. Nor is the use of class in and of itself presentational - in fact, it is an important mechanism for separating presentation from structured content.

For some more on using class semantically, here are some articles

* [http://meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competent Classing by Eric Meyer]
* [http://www.w3.org/QA/Tips/goodclassnames Use class with semantics in mind, W3C]
* [http://tantek.com/log/2004/07.html#d20t2359 More about the class attribute, Tantek Çelik]

===Q. ''Should human readable data go into class names?'' ===

A. No. We should not put human readable data into the <code>class</code> attribute, because it puts human-readable data in a spot that's no longer visible. See the [[principles]].

Q. Follow-up. How is that different from putting human readable data into the <code>title</code> attribute?

A. The title attribute is displayed in tool-tips in the overwhelming majority of browsers in use and thus is quite semi-visible, and thus human verifiable by casual users. The class attribute is not displayed in a tool-tip or any other user interface (not withstanding developer interfaces like view source).

===<abbr title='Question'>Q.</abbr> Why don't microformats use the HTML5 <code>data-</code> attributes to embed data?===

<abbr title='Answer'>A</abbr>:
# The HTML5 <code>data-</code> attribute specification expressly forbids the microformats use-case:<blockquote cite='https://www.w3.org/TR/html5/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes'>Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements. These attributes are not intended for use by software that is independent of the site that uses the attributes. [...] It would be inappropriate, however, for the user to use generic software not associated with that music site to search for tracks of a certain length by looking at this data. This is because these attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata.</blockquote>— <cite>[http://www.w3.org/TR/html5/semantics.html#embedding HTML5 · Embedding custom-non-visible data]</cite>
# Microformats are designed around the principle that non-visible data is undesirable, harder to maintain, more prone to inaccuracy (as no-one will see the data on the page to notice errors). The <code>data-</code> attribute is explicitly designed for non-visible data.

== Hidden Content ==
Related to <span id="Microformats_and_Spam">microformats and spam</span>.

=== Q. ''Will crawlers get data from hidden content?'' ===
Q: ''If I markup some content inside of a block with display:none, will crawlers get data from it anyway?''

A. Crawlers and search engines frown upon hidden (e.g. display:none) content in general (e.g. see next FAQ about Google, hidden content, and spam). If some content doesn't fit into your visible design, then it's not worth microformatting it. Visible content is the only content you can reasonably trust/expect to be correct / up to date. Invisible content tends to rot, get out of date, fail to be checked etc., so don't waste any time publishing invisible content - it's going to die anyway.

=== Q. ''Given that Google now looks at hidden content as potential spam, will invisible microformats be considered spam?''===

;shortlink
:http://j.mp/gnohide

A. It is advisable not to hide information in your site, regardless of whether it is microformatted or not. Microformats provide a mechanism for marking up ''visible'' content. Any mechanism for embedding ''invisible'' or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data.

Google in particular have said: <blockquote><p>In general, Google won't display content that is not visible to the user. In other words, don't show content to users in one way, and use hidden text to mark up information separately for search engines and web applications. You should mark up the text that actually appears to your users when they visit your web pages.[http://support.google.com/webmasters/bin/answer.py?hl=en&answer=146897]</p></blockquote>

The only 'hidden' data they support according to that article is specific use of the [[value class pattern]] <code>value-title</code> empty span with machine-readable information adjacent to a human-readable equivalent.

== Design Patterns with Abbr & Title ==
=== Q. ''Why is ABBR being used when the title attribute is available on all HTML elements?''===

In the datetime design pattern the title attribute is used for the value of the property and the node value is used as the display value. <abbr title="value-here">Display-Here</abbr>.

A. The short answer is that <abbr> has the correct semantics.

The longer answer is that the value is often an abbreviated version of the formal value. Of course, if you don't want to use an <abbr>, you can use another element like this:

<abbr title="2006-12-31T12:59:59Z" class="dtstamp">New Year</abbr>

<span class="dtstamp">2006-12-31T12:59:59Z</span>

In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative. The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second. Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute.

=== Q. ''Can I include information within the HTML element itself?'' ===

Longer: ''Can I include information within the HTML element itself? e.g. <span class="org" title="Foobar, Inc."></span>?'' [http://twitter.com/szarka/status/109723996223840256]

A. You can't do that with the <code>span</code> element because there is no specific semantic connection between the element contents and its <code>title</code> other than being [http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 "advisory information about the element"]. In addition, it's bad form (and penalized by Google) to include invisible data on web pages.

Instead, you can use the <code>abbr</code> element and its <code>title</code> attribute to provide an expanded form of the information in cases where substituting the expanded form when reading the text in context reads correctly, e.g. inside an [[hCard]]:
<source lang=html4strict>
<abbr class="region" title="Connecticut">CT</abbr>
</source>

[http://twitter.com/microformats/status/112556548877844481]

== Nesting of elements ==
=== Q. ''It seems that <code><span class="vcard fn org" id="club">...</span></code> should work. Is this correct?''===

A. No. See [[hcard-faq#nesting-properties]].

== Usage/Verbiage ==
=== Q. ''Is '''Microformat''' a proper noun? Should it be capitalized?''===

A. Since the term "microformat" was established, it has been written in lowercase. This is a nod to its roots in the term "lowercase semantic web", in contrast to the uppercase "Semantic Web" which has long been tied to RDF and other technologies often viewed as impractical for the open web. In a few cases in the wild(citation needed), the term has been capitalized as "Microformat", perhaps due to proper noun capitalization conventions.

=== Q. ''Can you use microformat as an adjective or verb, as in "microformatted content" or "can you please microformat that page with an hCard?"===

A. Because the word ''microformat'' is derived from the word '''format''', it makes logical sense that one can use the term as an adjective or verb, just as one would use the word '''format'''.

== See Also ==
* [[misconceptions]]

h-feed

2017-05-19T13:57:13Z

Kevin Marks: /* Converters */ unmung

<entry-title>h-feed</entry-title>

<dfn style="font-style:normal;font-weight:bold">h-feed</dfn> is a [[microformats2]] draft for marking up a stream or feed of [[h-entry]] posts, like complete posts on a home page or archive pages, or summaries or other brief lists of posts.

h-feed is the [[microformats2]] update to [[hAtom]]'s "hfeed".

{{cc0-owfa-license}}

== Properties ==
h-feed properties, inside an element with class '''h-feed'''. All properties are optional.

root class name: h-feed

=== Core Properties ===
The following ''core'' h-feed properties have broad consensus:
* '''<code>p-name</code>''' - name of the feed
* '''<code>p-author</code>''' - author of the feed, optionally embed an [[h-card]] {{main|h-card}}
* '''<code>u-url</code>''' - URL of the feed
* '''<code>u-photo</code>''' - representative photo / icon for the feed

children:
* nested [[h-entry]] objects representing the items of the feed

=== Draft Properties ===
None currently.

=== Proposed Properties ===
The following properties are proposed additions based on various observed examples in the wild, but are awaiting at least one reader / real world consuming code example to become a draft property:
* '''<code>p-summary</code>''' - based on non-trivial actual content usage of "atom:subtitle" on Blogger and WordPress.com featured blogs's Atom feeds.
* '''<code>p-entry</code>''' - to be more consistent with the cascading of p-author or [http://microformats.org/wiki/comment-brainstorming#Proposal p-comment].

== Status ==
'''h-feed''' is a microformats.org draft specification. Public discussion on h-feed takes place on [[h-entry-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-feed is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-feed up as a classic [[hAtom]] "hfeed".

== Use Cases ==
* Named feeds
** IndieWeb Readers are consuming home page feeds marked up with h-feed and using the name of the h-feed in their user interfce.

* Generate an Atom feed
** This seems like a legacy use-case, not sufficient to actually justify h-feed.

* Feed per channel of content - needs a name
** "I will have a feed per tag (channel) so I want to name them." - Sandeep Shetty in #indiewebcamp
** It appears there is some desire to create separate feeds for an indieweb site for separate subsets of content, and name them <em>explicitly</em> accordingly. This presents a need for a container object for the h-entry elements, where the container itself can have a name. This is a potential interesting use-case for an explicit 'h-feed'.

== Examples in the wild ==
Add any examples in the wild that you find to the top of this list.
* ...
* http://sandeep.io/ uses h-feed with p-name and p-author properties and child h-entry posts. In particular using h-feed on the <html> element allows using p-name on the <title> element and re-using the visible window title of the HTML page as the name of the feed, neatly avoiding a [[DRY]] violation.
* http://tantek.com/ uses h-feed with p-name and p-author properties and child h-entry posts.

== Implementations ==
=== Readers ===
* Shrewdness
* http://notenoughneon.com/feed.php

=== Proxies ===
* Bridgy

=== Converters ===
* '''[http://unmung.com unmung]''' - will transform an RSS or Atom feed into an [[h-feed]] containing h-entries,
* '''[http://pipes.yahoo.com/pipes/pipe.info?_id=afc5568b4e8643bfb05436b1caaf91bc microformats to RSS]''' - a Yahoo! pipe that converts a URL containing an [[h-feed]] containing h-entries, into an [[RSS]] feed. ([http://waterpigs.co.uk/notes/4SeNi5/ 2013-10-21 blog post announcing])

== Parsing ==
When parsing a page for an h-feed, do so per [[microformats2]].

Fallback:

If there is no explicit "h-feed" element, implementations may:
* Treat the <code><title></code> of the page or the URL of the page as the p-name
* Use http://indiewebcamp.com/authorship to discover authorship of posts.
* Treat top level [[h-entry]] elements as items in the feed.

== FAQ ==
=== How do I avoid duplicating the page title ===
''I want to use the name (title) of my page as the name of my feed, how do I avoid duplicating the page title somewhere invisibly on the page as the feed name?''

If you want re-use the <title> of your page as the name of your feed, you can do so by putting the h-feed root class name on the <html> element, and the p-name property class name on the <title> element, e.g. here's a snippet showing how those tags would look:
<source lang=html4strict>
<html class="h-feed">
…
<title class="p-name">sandeep.io</title>
…
</source>

=== What should a subscriber do with a page with multiple feeds ===
''What do I do when a user subscribes to a URL with multiple distinct h-feeds?''

A feed reader should subscribe to the first h-feed it finds at a URL.

Related: http://indiewebcamp.com/reader

== See Also ==
* [[h-feed-issues]]
* [[h-entry]]
* [[microformats2]]
* [[hAtom]]

[[Category:Draft Specifications]]

rel-canonical

2017-03-28T10:58:18Z

Kevin Marks: /* The opposite of canonical */

<entry-title>rel-canonical</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Kevin Marks|Kevin Marks]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">rel=canonical</dfn> is a link relation to indicate the canonical URL of the current page, to avoid duplicate content.

{{cc0-owfa-license}}

== Abstract ==
<p class="entry-summary">By adding <code>rel="canonical"</code> to a hyperlink, a page indicates that the destination of that hyperlink {{should}} be considered the preferred or definitive version of the current page. This helps search engines avoid duplicate content, and is useful for deciding how to link to a page when citing it.</p>

== Discussion ==
There are many reasons for a site to serve the same content at multiple URLs, but duplicate pages are undesirable in search results. The [https://www.mattcutts.com/blog/seo-advice-url-canonicalization/ historic recommendation] was to use 301 redirects to the canonical page, but that can be jarring for users. There are many use cases for a URL to have additional information added as query parameters or fragments to indicate the navigation history for referral purposes, but would prefer a single main referent from searches. This was codified in February 2009 as rel=canonical, and [https://webmasters.googleblog.com/2009/02/specify-your-canonical.html adopted] by [http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ many] [https://blogs.msdn.microsoft.com/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx search] [https://web-beta.archive.org/web/20091008070823/http://blog.ask.com/2009/02/ask-is-going-canonical.html engines].

Search engines prefer <code>rel=canonical</code> on a <code><link></code> element, and will [https://www.mattcutts.com/blog/rel-canonical-html-head/ ignore it] on an <code><a></code> element.
=== Cross-domain links ===
Although the primary use case is links within the same domain, rel=canonical can be used [https://webmasters.googleblog.com/2009/12/handling-legitimate-cross-domain.html across domains] too. A common use case recently is from [https://www.ampproject.org/docs/guides/deploy/discovery cached AMP pages] to their original.
== The opposite of canonical ==
There are several ways of indicating non-canonical versions of a page, depending on what is intended. A non-comprehensive list
=== rel-syndication and u-syndication ===
[[rel-syndication]] and [http://microformats.org/wiki/h-entry#Core_Properties u-syndication] link to copies that the author has syndicated or shared onto other sites. The syndicated copies {{should}} have a rel-canonical link back to the original if the other site allows it.
=== rel-alternate===
[[rel-alternate]] is used to link to versions of the page in other forms, whether a different format with <code>type</code>, language with <code>hreflang</code> or presentation medium with <code>media</code>.
=== rel-amphtml ===
[[rel-amphtml]] is used to link to the Accelerated Mobile Pages version, a html subset limiting javascript, replacing built-in elements with custom elements and designed for caching. It is [https://www.ampproject.org/docs/guides/deploy/discovery recommended] to link back fromt he AMP version to the original with rel-canonical
=== rel-shortlink ===
[[rel-shortlink]] is used to link to a url shortened version designed for sharing and (often) tracking.
=== rel-me ===
[[rel-me]] is explicitly saying that another domain or page represents the same person or organisation as the current page. As such it is a different level of abstraction from rel-canonical, as it refers to the representation rather than the content.
=== rev-canonical ===
A deprecated way of linking to a short link, briefly [https://revcanonical.wordpress.com/ popular], [https://www.mnot.net/blog/2009/04/14/rev_canonical_bad disliked] and not recommended.

== Issues ==
* See https://github.com/whatwg/html/issues/2351

== See Also ==
* [[existing-rel-values]]
* https://en.wikipedia.org/wiki/Canonical_link_element
* [https://support.google.com/webmasters/answer/139066?hl=en Google's canonical advice page]
* [http://known.kevinmarks.com/2017/day-7-to-amp-or-not-to-amp-100daysofindieweb canonical bookmarklets]
* [[sharelink-formats]]
* [https://tools.ietf.org/html/rfc6596 RFC 6596 - The Canonical Link Relation]

rel-canonical

2017-03-28T10:35:26Z

Kevin Marks: /* See Also */ add RFC

rel-canonical

2017-03-28T10:31:05Z

Kevin Marks: /* Cross-domain links */ typo

rel-canonical

2017-03-28T10:30:33Z

Kevin Marks: /* See Also */ sharelink

rel-canonical

2017-03-28T10:29:56Z

Kevin Marks: /* Discussion */ cross-domain

rel-canonical

2017-03-28T10:24:25Z

Kevin Marks: /* Discussion */ a ignore

rel-canonical

2017-03-28T10:22:31Z

Kevin Marks: copypasta error

rel-canonical

2017-03-28T10:21:37Z

Kevin Marks: /* Abstract */ typo

<entry-title>h-card</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Kevin Marks|Kevin Marks]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">rel=canonical</dfn> is a link relation to indicate the canonical URL of the current page, to avoid duplicate content.

{{cc0-owfa-license}}

== Abstract ==
<p class="entry-summary">By adding <code>rel="canonical"</code> to a hyperlink, a page indicates that the destination of that hyperlink {{should}} be considered the preferred or definitive version of the current page. This helps search engines avoid duplicate content, and is useful for deciding how to link to a page when citing it.</p>

== Discussion ==
There are many reasons for a site to serve the same content at multiple URLs, but duplicate pages are undesirable in search results. The [https://www.mattcutts.com/blog/seo-advice-url-canonicalization/ historic recommendation] was to use 301 redirects to the canonical page, but that can be jarring for users. There are many use cases for a URL to have additional information added as query parameters or fragments to indicate the navigation history for referral purposes, but would prefer a single main referent from searches. This was codified in February 2009 as rel=canonical, and [https://webmasters.googleblog.com/2009/02/specify-your-canonical.html adopted] by [http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ many] [https://blogs.msdn.microsoft.com/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx search] [https://web-beta.archive.org/web/20091008070823/http://blog.ask.com/2009/02/ask-is-going-canonical.html engines].

Search engines prefer <code>rel=canonical</code> on a <code><link></code> element, and will ignore it on an <code><a></code> element.

== Issues ==
* See https://github.com/whatwg/html/issues/2351

== See Also ==
* [[existing-rel-values]]
* https://en.wikipedia.org/wiki/Canonical_link_element
* [https://support.google.com/webmasters/answer/139066?hl=en Google's canonical advice page]
* [http://known.kevinmarks.com/2017/day-7-to-amp-or-not-to-amp-100daysofindieweb canonical bookmarklets]

rel-canonical

2017-03-28T10:21:09Z

Kevin Marks: flesh out to be more spec-like

<entry-title>h-card</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Kevin Marks|Kevin Marks]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">rel=canonical</dfn> is a link relation to indicate the canonical URL of the current page, to avoid duplicate content.

{{cc0-owfa-license}}

== Abstract ==
<p class="entry-summary">By adding <code>rel="caconical"</code> to a hyperlink, a page indicates that the destination of that hyperlink {{should}} be considered the preferred or definitive version of the current page. This helps search engines avoid duplicate content, and is useful for deciding how to link to a page when citing it.</p>

== Discussion ==
There are many reasons for a site to serve the same content at multiple URLs, but duplicate pages are undesirable in search results. The [https://www.mattcutts.com/blog/seo-advice-url-canonicalization/ historic recommendation] was to use 301 redirects to the canonical page, but that can be jarring for users. There are many use cases for a URL to have additional information added as query parameters or fragments to indicate the navigation history for referral purposes, but would prefer a single main referent from searches. This was codified in February 2009 as rel=canonical, and [https://webmasters.googleblog.com/2009/02/specify-your-canonical.html adopted] by [http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ many] [https://blogs.msdn.microsoft.com/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx search] [https://web-beta.archive.org/web/20091008070823/http://blog.ask.com/2009/02/ask-is-going-canonical.html engines].

Search engines prefer <code>rel=canonical</code> on a <code><link></code> element, and will ignore it on an <code><a></code> element.

== Issues ==
* See https://github.com/whatwg/html/issues/2351

== See Also ==
* [[existing-rel-values]]
* https://en.wikipedia.org/wiki/Canonical_link_element
* [https://support.google.com/webmasters/answer/139066?hl=en Google's canonical advice page]
* [http://known.kevinmarks.com/2017/day-7-to-amp-or-not-to-amp-100daysofindieweb canonical bookmarklets]

rel-nofollow

2017-03-28T09:23:27Z

Kevin Marks: /* additional lists of issues */ archive link

<entry-title>rel="nofollow"</entry-title>
__TOC__
== Specification 2005-01-10 ==

=== Editors ===
* [http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati, Inc.])
* [http://epeus.blogspot.com/ Kevin Marks] ([http://technorati.com Technorati, Inc.])

=== Concept ===
* [http://www.google.com/googleblog/ Matt Cutts] ([http://google.com Google, Inc])
* [http://www.shellen.com/ Jason Shellen] ([http://www.blogger.com Blogger]/[http://www.google.com Google])

=== Copyright ===
{{MicroFormatCopyrightStatement2005}}
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
* [[User:Kevin Marks|Kevin Marks]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.
** When all authors/editors have done so, we can remove the MicroFormatCopyrightStatement template reference and replace it with the MicroFormatPublicDomainContributionStatement.

=== Patents ===
{{MicroFormatPatentStatement}}

== Abstract ==
<p class="entry-summary">RelNoFollow is an [[elemental-microformat|elemental microformat]], one of several [[microformats|microformat]] open standards. By adding <code>rel="nofollow"</code> to a hyperlink, a page indicates that the destination of that hyperlink {{should not}} be afforded any additional weight or ranking by user agents which perform link analysis upon web pages (e.g. search engines). Typical use cases include links created by 3rd party commenters on blogs, or links the author wishes to point to, but avoid endorsing. For more specific endorsement (or lack thereof) semantics, see [[vote-links|VoteLinks]].</p>

== XMDP profile ==
The following is an [http://gmpg.org/xmdp/ XMDP] profile for the [[rel-nofollow]] specification.

=== URLs ===
This profile is hosted as a separate XMDP file on microformats.org:
* http://microformats.org/profile/rel-nofollow
* shortURL: http://ufs.cc/x/rel-nofollow

=== Usage ===
Profiles are referenced in (X)HTML files in the <HEAD> tag, e.g.:
<source lang=html4strict>
<head profile='http://microformats.org/profile/rel-nofollow'>
</source>

=== Profile ===
<source lang=html4strict>
<dl class="profile">
<dt id="rel">rel</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value as defined in the
<a rel="help start" href="http://microformats.org/wiki/rel-nofollow">
rel-nofollow specification</a>
.</p>
<dl>
<dt id="nofollow">nofollow</dt>
<dd>Indicates that the referred resource was not necessarily linked to
by the author of the page, and thus said reference should not afford
the referred resource any additional weight or ranking by user agents.
</dd>
</dl>
</dd>
</dl>
</source>

== examples in the wild ==
This section is informative.
Note: There are numerous uses of rel-nofollow in the wild, this is very much an incomplete list. If your site marked up with rel-nofollow, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page ([[rel-nofollow-examples-in-wild]]).
* [http://www.netd.it/sviluppo/ Netdesign Developers Network] uses the rel-nofollow attribute to make search engines don't follow the "off-topic" links.
* [http://funadvice.com FunAdvice] supports using the rel-nofollow tag to prevent users posting content simply for the search engine benefit, to improve the quality of the advice giving community.
* [http://petfoodtalk.com/dogfoodcoupons/ Dog Food Coupons] provides a dog food coupon collection service for dog owners. rel-nofollow is used to instruct search engine agents to '''not''' further execute link analysis and avoid endorsement of the actual merchant coupon links.
* [http://petmoz.com/dogfoodcoupons Pet Food Coupons] While listing coupons in our Dog Food Coupons section why use the rel-nofollow tag to make sure that search engines specifically Google do not follow any links we believe have no value to the visitor.

== bad examples in the wild ==
This section is informative.
There are now numerous abuses of rel-nofollow, in particular, where it is used on *2nd party* links, rather than the original intention of *3rd party* links such as in blog comments. The primary abusers of rel-nofollow are content hosting / social network sites.
* [http://flickr.com/ Flickr] puts "nofollow" on comments by the content publisher themselves (should only be on 3rd party comments), e.g. http://www.flickr.com/photos/tantek/2344425887/ as well as on profile links e.g. website: http://www.flickr.com/people/microformats/
* [http://twitter.com/ Twitter] puts "nofollow" on account holders' profile links, in the "description" and "web site" fields, e.g. http://twitter.com/indiewebcamp (links in posts do not have "nofollow" yet are wrapped with "t.co" URLs).
* ... nearly every other content hosting / publishing site - please add more specific examples with direct URLs to pages abusing "nofollow".

=== exceptions ===
It may seem odd to explicitly list *non* examples in an examples in the wild section, but such non-examples may be useful to help convince the bad examples in the wild to change their behavior:
* [http://blogspot.com/ Blogspot] does NOT put "nofollow" on content publisher links, e.g. http://epeus.blogspot.com/2012/03/when-youre-merchandise-not-customer.html
* [http://tumblr.com/ Tumblr] does NOT put "nofollow" on content publisher links, e.g. http://adactio.tumblr.com/post/27135731578/the-web-unusually-came-with-a-view-source
* ... (let's hope we find more such non-examples)

== normative references ==
* [http://gmpg.org/xmdp/ XMDP]
* http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html

== informative references ==
* VoteLinks can be used by an author to explicitly state their support for or against, or neutrality toward the destination of a link. Implementers implementing rel="nofollow" and VoteLinks should similarly not afford any additional weight or ranking to links with either <code>rev="vote-abstain"</code> or <code>rev="vote-against"</code>.
* Contributed from http://developers.technorati.com/wiki/RelNoFollow

== open issues ==
These are open issues that have been raised about rel="nofollow" that have been raised in various forums, in particular, on the public [http://lists.w3.org/Archives/Public/www-html W3C www-html mailing list]. Once the list grows too big, we'll make a separate wiki page ([[rel-nofollow-issues]]). The issues have been grouped into four areas.

* '''Definition'''. nofollow indicates a behavior rather than a relationship from which the behavior should be inferred as appropriate for the useragent. rel values should be nouns that indicates what the resource being referenced is in relation to the source.
* '''Name'''. nofollow is a bad name.
** overloading. does not mean the same as robots exclusion standards (robots.txt, meta robots) nofollow.
** does not mean what it says. does not mean "do not follow this link", rather it means " do not add weight from this link". [http://www.w3.org/mid/opsk3cccj9lo81gp@quark Asbjørn Ulsberg]
** not a noun. see above.
** suggested alternatives:
*** noendorse - [http://lists.w3.org/Archives/Public/www-html/2005Jan/0046.html Micah Dubinko]
*** none
*** noweight
*** unendorsed - [http://lists.w3.org/Archives/Public/www-html/2005Jan/0057.html Lachlan Hunt]
*** unrelated - [http://lists.w3.org/Archives/Public/www-html/2005Jan/0049.html Jens Meiert]
*** untrusted
*** nonauth - [http://www.mnot.net/blog/2003/12/29/comment_spam_and_google Mark Baker]
*** norank - [http://www.digitalburg.com/ Ben Pierce]
*** notally - [http://www.eenmanierom.nl/google-penalty/ Patrick Mackaaij]
* '''Efficacy'''. nofollow will not affect spamming behavior.
* '''Collateral Damage'''. If tools automatically add nofollow to all 3rd party links, then many legitimate non-spam links will be ignored or given reduced weight, and thus the destination of such links will be unfortunate casualties.

=== additional lists of issues ===
Additional lists of issues raised against rel="nofollow" can be found at the following site(s):
* [https://web-beta.archive.org/web/20061205020420/http://nonofollow.net/index.php?title=Main_Page nonofollow.net]
Matt Cutts Says No to Nofollow On Internal Links:
* http://www.techzene.com/seo/rel-nofollow-seo-disadvantages/

[[Category:Specifications]]
[[Category:rel-nofollow]]

== articles ==
When this section gets too big, we can move it to [[rel-nofollow-articles]].
* [http://searchenginewatch.com/3633972 2009-06-03 Search Engine Watch: Google Changes Course on Nofollow]
* [http://reference.sitepoint.com/html/rel-mf#rel__nofollow SitePoint reference: rel- Microformats / nofollow] by Ian Lloyd
* Auto Chevrolet [https://giaxeotochevrolet.com/]

sharelink-formats

2017-01-21T02:45:08Z

Kevin Marks: /* examples */ atom rel-self

<entry-title>sharelink formats</entry-title>

Part of the Sharelink effort.

[https://twitter.com/cramforce/status/822184263172796416 Malte Ubl ‏@cramforce Jan 19]
*specifically we’d like to propose <link rel=share> (or similar name) to provide preference of shared URL for a given page.
Per the microformats [[process]] this page is here to document previous formats for pages publishing share links for themselves.

{{stub}}

== examples ==
* [[rel-canonical]]
** [https://twitter.com/adactio/status/822253267665252356 Jeremy Keith ‏@adactio]<br> @cramforce Is this not already covered by rel="canonical"?
** [https://twitter.com/cramforce/status/822254953985019904 Malte Ubl ‏@cramforce]<br> @adactio we’d fallback to that, but people want to override it for some legit and less legit reasons.<br>people sometimes use canonical to point to an entirely different publication that was the original source of the content.<br>and others want to do share tracking with #.1234 style URLs (see e.g. @Medium URLs).
** [https://twitter.com/kevinmarks/status/822257980049485824 Kevin Marks ‏@kevinmarks] <br> @cramforce @adactio @Medium or google inspired &utm_source things

*[http://microformats.org/wiki/h-entry#Draft_Properties u-repost-of]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?

* [[rel-bookmark]]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?<br>rel-bookmark is already in the [https://www.w3.org/TR/html51/links.html#link-type-bookmark html5 spec], and in lots of CMSs, including WordPress …
** [https://twitter.com/cramforce/status/822264992992927744 Malte Ubl ‏@cramforce] <br>@kevinmarks @adactio I think bookmark comes pretty close. Not quite the same, but close.

* [[rel-shortlink]]
** https://twitter.com/voxpelli/status/822378518902239233 [Pelle Wessman ‏@voxpelli] <br>@cramforce @kevinmarks @adactio There's also rel-shortlink which is often used for sharing + is widely supported

*rel=self
** the [https://tools.ietf.org/html/rfc4287#section-4.2.7.2 Atom Link element] defines rel="self" as
The value "self" signifies that the IRI in the value of the href
attribute identifies a resource equivalent to the containing
element.

== see also ==
* [[sharelink-examples]]

sharelink-formats

2017-01-21T02:33:49Z

Kevin Marks: /* examples */ link u-repost-of

<entry-title>sharelink formats</entry-title>

Part of the Sharelink effort.

[https://twitter.com/cramforce/status/822184263172796416 Malte Ubl ‏@cramforce Jan 19]
*specifically we’d like to propose <link rel=share> (or similar name) to provide preference of shared URL for a given page.
Per the microformats [[process]] this page is here to document previous formats for pages publishing share links for themselves.

{{stub}}

== examples ==
* [[rel-canonical]]
** [https://twitter.com/adactio/status/822253267665252356 Jeremy Keith ‏@adactio]<br> @cramforce Is this not already covered by rel="canonical"?
** [https://twitter.com/cramforce/status/822254953985019904 Malte Ubl ‏@cramforce]<br> @adactio we’d fallback to that, but people want to override it for some legit and less legit reasons.<br>people sometimes use canonical to point to an entirely different publication that was the original source of the content.<br>and others want to do share tracking with #.1234 style URLs (see e.g. @Medium URLs).
** [https://twitter.com/kevinmarks/status/822257980049485824 Kevin Marks ‏@kevinmarks] <br> @cramforce @adactio @Medium or google inspired &utm_source things

*[http://microformats.org/wiki/h-entry#Draft_Properties u-repost-of]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?

* [[rel-bookmark]]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?<br>rel-bookmark is already in the [https://www.w3.org/TR/html51/links.html#link-type-bookmark html5 spec], and in lots of CMSs, including WordPress …
** [https://twitter.com/cramforce/status/822264992992927744 Malte Ubl ‏@cramforce] <br>@kevinmarks @adactio I think bookmark comes pretty close. Not quite the same, but close.

* [[rel-shortlink]]
** https://twitter.com/voxpelli/status/822378518902239233 [Pelle Wessman ‏@voxpelli] <br>@cramforce @kevinmarks @adactio There's also rel-shortlink which is often used for sharing + is widely supported

== see also ==
* [[sharelink-examples]]

sharelink-formats

2017-01-21T02:30:48Z

Kevin Marks: /* examples */ copy in twitter discussion

<entry-title>sharelink formats</entry-title>

Part of the Sharelink effort.

[https://twitter.com/cramforce/status/822184263172796416 Malte Ubl ‏@cramforce Jan 19]
*specifically we’d like to propose <link rel=share> (or similar name) to provide preference of shared URL for a given page.
Per the microformats [[process]] this page is here to document previous formats for pages publishing share links for themselves.

{{stub}}

== examples ==
* [[rel-canonical]]
** [https://twitter.com/adactio/status/822253267665252356 Jeremy Keith ‏@adactio]<br> @cramforce Is this not already covered by rel="canonical"?
** [https://twitter.com/cramforce/status/822254953985019904 Malte Ubl ‏@cramforce]<br> @adactio we’d fallback to that, but people want to override it for some legit and less legit reasons.<br>people sometimes use canonical to point to an entirely different publication that was the original source of the content.<br>and others want to do share tracking with #.1234 style URLs (see e.g. @Medium URLs).
** [https://twitter.com/kevinmarks/status/822257980049485824 Kevin Marks ‏@kevinmarks] <br> @cramforce @adactio @Medium or google inspired &utm_source things

* u-repost-of
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?

* [[rel-bookmark]]
** [https://twitter.com/kevinmarks/status/822260255652397057 Kevin Marks ‏@kevinmarks]<br> @cramforce @adactio so the page has a link to the version it wants shared. Is it like u-repost-of https://indieweb.org/repost or rel=bookmark?<br>rel-bookmark is already in the [https://www.w3.org/TR/html51/links.html#link-type-bookmark html5 spec], and in lots of CMSs, including WordPress …
** [https://twitter.com/cramforce/status/822264992992927744 Malte Ubl ‏@cramforce] <br>@kevinmarks @adactio I think bookmark comes pretty close. Not quite the same, but close.

* [[rel-shortlink]]
** https://twitter.com/voxpelli/status/822378518902239233 [Pelle Wessman ‏@voxpelli] <br>@cramforce @kevinmarks @adactio There's also rel-shortlink which is often used for sharing + is widely supported

== see also ==
* [[sharelink-examples]]

sharelink-formats

2017-01-21T02:13:41Z

Kevin Marks: space for examples

sharelink-examples

2017-01-21T01:56:01Z

Kevin Marks: initial examples of sharelinks

<entry-title>sharelink examples</entry-title>

Part of the Sharelink effort.

[https://twitter.com/cramforce/status/822184263172796416 Malte Ubl ‏@cramforce Jan 19]
*specifically we’d like to propose <link rel=share> (or similar name) to provide preference of shared URL for a given page.
Per the microformats [[process]] this page is here to document existing real world visible web publishing examples of pages publishing share links for themselves.

{{stub}}

== examples ==
* Twitter has a "copy link" dropdown with javascript, no rel on the tweet link.
* Medium changes the address bar link
* giphy under the advanced tab has multiple links, displayed as text input fields to copy
<source lang="html4strict">
<div class="advanced-action-group">
<div class="action clearfix">
<p class="action-note">Giphy links preview in Facebook and Twitter. HTML5 links autoselect optimized format.</p>
<span class="action-label">Giphy Link</span>
<div class="action-field">
<input type="text" value="http://gph.is/2dmmt6J" data-copy="true">
</div>
</div>
<div class="action clearfix">
<span class="action-label">HTML5 Video</span>
<div class="action-field">

<input type="text" value="https://giphy.com/gifs/lC86xNTUs7CM0/html5" data-copy="true">

</div>
</div>
<div class="action clearfix">
<span class="action-label">Gif Download</span>
<div class="action-field has-button">
<input type="text" value="http://i.giphy.com/lC86xNTUs7CM0.gif" data-copy="true">
<a class="action-button button blue" href="https://media.giphy.com/media/lC86xNTUs7CM0/giphy.gif" download="giphy.gif" target="_blank">Download</a>
</div>
</div>

</div>
</source>
* svgshare has multiple URLs to copy as well:
<source lang="html4strict">
<ul id="shares">
<li><h3>Image Link (chat, IM, email)</h3>
<input readonly value="http://svgshare.com/s/Xe" type="text" >
<li><h3>Direct Link (chat, IM, email)</h3>
<input readonly value="http://svgshare.com/i/Xe.svg" type="text" >
<li><h3>HTML (website, blog)</h3>
<input readonly value="<a href='http://svgshare.com/s/Xe' ><img src='http://svgshare.com/i/Xe.svg' title='' /></a>" type="text" >
<li><h3>HTML iframe (website, blog)</h3>
<input readonly value="<iframe src='http://svgshare.com/f/Xe' width=100% height=100% ></iframe>" type="text" >
<li><h3>Hash resolver</h3>
<input readonly value="http://svgshare.com/getbyhash/sha1-S0gBndRX/ONq105EfF1/tF8h9Lo=" type="text" >
</ul>
</source>
* …
== see also ==
* [[sharelink-formats]]

block-list-formats

2016-12-14T01:09:43Z

Kevin Marks: /* Block Chain list */

<h1>block list formats</h1>
{{TOC-right}}
Previous attempts at [[block list]] formats. Part of the effort to enable greater [[social network portability]].

== formats ==
=== rn kill file ===
Usenet/netnews [http://en.wikipedia.org/wiki/Kill_file kill files]. For details of the kill file implemented by the "rn" news reading program, see the [http://www.faqs.org/faqs/killfile-faq/ killfile faq].
<blockquote><pre><nowiki>
Rn and trn
==========
5. What is the general syntax of a KILL file entry?
The general style for building a kill line is:

/pattern/modifiers:command

The <pattern> is the pattern to use to pick articles. This is a regular
expression, like those used in grep. You can use any case in the pattern;
t won't matter, unless you use a modifier to make rn case-sensitive.
The <modifiers> tell rn where to look for the pattern - the subject
(default), one of the other header lines, or the entire article, as examples
of the usual modifiers used.
The command tells what to do with the article once it's been selected.
This is usually either to kill it or to mark it unread.

If no modifier appears before the colon, only the subject line of the
article is searched. More than one command can be performed by using
the style:

/pattern/modifier:command:command

Thus, for instance, you can use j and = together to see the exact subject
lines being killed. (See below for the explanation of j and =.)

6. What are the available modifiers and commands?

The modifiers and commands are all explained in the rn man page, but here
are some of them:
Modifiers:
a: all, look through the entire article for the pattern
h: look through the header of the article for the pattern
f: look at only the 'From:' header (trn 3.0)
c: Make the pattern case sensitive
H: added in trn 3.1, this expands the f: above to any header
Commands:
m mark as unread
j mark as read
= show subject line

...
7. How do I kill a specific subject?

The easiest way to kill a subject line is to kill it from within the
newsgroup. When the subject line comes up that you want to kill, instead
of using 'n' to skip that article or 'k' to kill the subject for that
session, type 'K'. The subject line will then be entered into your KILL
file for that group. If you want to put that line into your global KILL
file, you'll have to do that yourself.

To kill a general subject, ie any 'test' messages, put in the pattern:

/test/:j

This will kill anything with the word 'test' in the subject line.

8. How do I kill postings from a specific person?

To kill articles from a single poster, you need to know the userid and
nodename of the poster; for this example we'll use noone@anywhere.all.

/^From:.*noone@anywhere\.all/h:j

This searches the entire header for any line starting with 'From:', anything
at all, and then 'noone@anywhere.all' in it. This is faster than if the
beginning-of-line character (^) had been left out:

/From:.*noone@anywhere\.all/h:j

If this were used, something like 'Subject: Re: Articles from:
noone@anywhere.all' would also get killed.

9. How do I kill articles from a specific site?

For articles from a particular site, just remove the 'noone' from the
previous lines, and articles from the machine 'anywhere.all' will be killed.
So, the line would be:

/^From:.*@anywhere\.all/h:j

10. How do I kill followups?

To kill anything that is a followup to any article, use this pattern:

/Re:/:j

This kills anything with 'Re:' in it. (This includes articles of the form
'Subject: X (Was Re: Y)'.)

If you just want to kill the direct followups, without the changes in
subject, you have to make it clear where the Re: is in the line:

/^Subject: Re:/:j
</nowiki></pre></blockquote>

=== trn kill file features ===
Again from the [http://www.faqs.org/faqs/killfile-faq/ killfile faq].
<blockquote><pre><nowiki>
Trn
===
15. What's different about trn?

Trn, being a threaded version of rn, has a few extra enhancements to
deal with those. Because rn is no longer being improved, there are also
extensions that have been made that could, but are not, be integrated into
the base rn killfiles.
One of the additions to trn is the f modifier, meaning the From: line.
This line gets used so much it seemed appropriate to add a modifier in
specifically for it.
So, now, killing or marking articles can be done on the basis of the
From: line quite easily, now:

/noone@anywhere\.all/f:j
/noone@anywhere\.all/f:m

It looks just like the Subject: line, except with the addition of the 'f'
in the modifier position.

However, the `f' modifier *may* not work exactly in the same manner as
the subject-based criteria if trn is configured to use thread files.
Specifically, if thread files are used only the 'Real Name' portion of the
from line can be guaranteed to be matched. To ensure that your match will
work on an address, you need to change the above lines to:

/noone@anywhere\.all/Hfrom:j
/noone@anywhere\.all/Hfrom:m
</nowiki></pre></blockquote>

=== Score file ===

Many USENET newsreaders including [http://gnus.org Gnus], slrn and others implement score-file functionality, which lets you provide scoring rules that end up giving a post an integer value from -9999 to 9999. Here are some examples from [User:TomMorris|Tom Morris]' score file that was generated by slrn:
<blockquote><pre><nowiki>
[*]
Score: =-9999
%Expires:
Subject: =\?windows-1252*
%EOS

%BOS
%Score created by slrn on Fri Nov 7 16:24:33 2008

[*]
Score: =-9999
%Expires:
Subject: CREDIT CARD SERVISES
From: MEGAL <megal47@yahoo\.com>
References: <43cd6752-09e2-4284-a296-b9f7eb4d1b98@a29g2000pra\.googlegroups\.com>
% Xref: uni-berlin\.de comp\.lang\.ruby:298844 comp\.lang\.php:173405 comp\.soft-sys\.sas:281663 comp\.lang\.lisp: 261578 comp\.arch\.embedded:269623
% Newsgroup: comp\.lang\.ruby
%EOS

%BOS
%Score created by slrn on Fri Nov 7 20:26:07 2008
</nowiki></pre></blockquote>
The rules have the following features:
* the first line (with the '*') is where the rule applies - the asterisk refers to it being applicable to all newsgroups
* the Expires: line allows you to specify a yyyy-mm-dd expiry date for the rule. In slrn, you are prompted with:
:: "Expires (MM/DD/YYYY, DD-MM-YYYY, +NN (days) or leave blank):"
:which is, of course, not ISO 8601 and needs to be rejiggled. ;)
* all the headers can be marked using wildcards. If you just want to filter one conversation, the References: allows you to do so. You can also filter messages originating with particular servers (googlegroups being one that is particularly spammy) by using a filter like "References: *googlegroups*"

[http://gnus.org/ Gnus], the Emacs newsreader, supports scoring posts both positively and negatively -- as such, its [http://gnus.org/manual/gnus_234.html#SEC234 scoring functionality] is a superset of just killing. The file format is an emacs lisp expression, described in the [http://gnus.org/manual/gnus_238.html#SEC238 score file format] section of the Gnus manual.

See [http://slrn.sourceforge.net/docs/slrn-FAQ-4.html slrn FAQ] and [http://en.wikipedia.org/wiki/Scorefile Scorefile on Wikipedia].

=== Block Chain list ===

The [https://chrome.google.com/webstore/detail/twitter-block-chain/dkkfampndkdnjffkleokegfnibnnjfah browser plugin Block Chain] exports Twitter [https://github.com/satsukitv/twitter-block-chain/blob/master/js/blockchain.js#L179 followers] in a JSON list of
<blockquote><pre>{id: user_id, name: user_name}</pre></blockquote>

== see also ==
* [[block-list]]
* [[block-list-examples]]
* [[block-list-brainstorming]]
* [[social-network-portability]]

== references ==
* [http://www.faqs.org/faqs/killfile-faq/ killfile faq]

microformats2-parsing-brainstorming

2016-07-19T01:50:25Z

Kevin Marks: /* img alt thoughts */ specific alt makes sense

<entry-title>microformats2 parsing brainstorming</entry-title>

This page is for brainstorming, discussion, and other questions and explorations about [[microformats2]] parsing.

For the microformats2 parsing algorithm, see:
* [[microformats2-parsing]]

For filing issues / problems with microformats2-parsing, see:
* [[microformats2-parsing-issues]]

__TOC__

== Parse img alt ==
Per https://github.com/microformats/microformats2-parsing/issues/2 currently any u-* property (e.g. u-photo, u-featured) that extracts a 'src' attr from an img tag loses any associated 'alt' text alternative, and if at some point the consuming application wants to display that u-* property as an img, they have to either omit or synthesize a fake text alternative.

It is desirable to somehow maintain that image src and alt association from the original markup, through the parsing process, up until a consuming application wishes to re-present the image with the text alternative.

There are a number of possibilities / approaches here worth brainstorming:

=== Include alt property in parent object ===
# explicit authoring: require the author to use a new 'p-alt' property on the image to cause parsing and extraction of the text alternative.
#* Problem(s): fails for multiple images, some of which may or may not have alt attrs or corresponding p-alt properties (and fragile, forgetting one p-alt throws off the parallel lists of u-* and p-alt).
# implicit p-alt: for every img that is parsed for a u-* property, the parse could generate a p-alt property with value.
#* Problem(s): fragile again for similar reasons, not all u-*s may be on img elements, or may not have alt attrs for all imgs in the source.
# implicit p-alt only for implied u-photo
#* This is better since there can only be one implied u-photo, and thus if there is a p-alt, it must be associated with the one u-photo
#* Problem(s): does not work for other u-* image properties e.g. u-featured

<code><nowiki><div class="h-entry"><img src="http://example.com/photo.jpg" alt="Example" class="u-photo p-alt"></div></nowiki></code>

<code><nowiki>{"type":["h-entry"],"properties":{"photo":["http://example.com/photo.jpg"],"alt":["Example"]}</nowiki></code>

=== Make photo property an object ===
1. use "h-image" on any u-* on img elements to imply a structure with paired photo and 'name' text alternative, e.g. <blockquote><code><img src="a.jpg" alt="text about a" class="u-featured h-image"/></code></blockquote> which would result in a u-featured property with one value, a structure of an h-image with itself having implied properties of a u-photo of "a.jpg" and a p-name of the "text about a". Similarly the author can use the object tag for the same result: <blockquote><code><object data="a.jpg" class="u-featured h-image">text about a</object></code></blockquote> In either case, the same microformats JSON would be generated, which is correct, as in both cases, there is an image with a fallback text alternative. The specific HTML used should not matter. The semantic of pairing the image with the text alternative is communicated the same way for both.

* Challenge: requires author use of additional classname "h-image".
* Benefit: does not require a change to the parsing algorithm

<source lang=html4strict>
<div class="h-entry">
<img src="http://example.com/eg.jpg" alt="Photo of an example" class="u-featured h-image">
</div>
</source>

<source lang=javascript>
{
"type":["h-entry"],
"properties":{
"featured":[{
"type":["h-image"],
"properties":{
"photo":["http://example.com/eg.jpg"],
"name":["Photo of an example"]
}
}]
}
</source> [http://pin13.net/mf2/?id=20160719001154920]

2. have u-* on an <img> automatically create an object if there is a non-empty 'alt' attribute. <br/>If a u-* property is parsed on an <img> element with a 'alt' attribute, then: <br/>
Create a structure similar to the e-content nested structure that provides the "value" as the URL, and an "alt" as the text alternative.

* Advantage: no additional microformats markup needed from author
* Challenge: Many (most?) existing published u-photo properties will now return an object instead of a string, and consuming applications may not be expecting an object for a photo
** Mitigation: If this is done as an explicit parser library upgrade, consuming applications may decide when to take this parser upgrade and thus fix their u-photo handling to look for string or object before upgrading their microformats2 parsing library instance.

<source lang=html4strict>
<div class="h-entry">
<img src="http://example.com/eg.jpg" alt="Photo of an example" class="u-featured">
</div>
</source>

<source lang=javascript>
{
"type":["h-entry"],
"properties":{
"featured":[{
"value":"http://example.com/eg.jpg",
"alt":"Photo of an example"
}]
}
</source>

... more brainstorming needed

=== img alt thoughts ===
Thoughts about img alt brainstorm proposals. Feel free to offer counterpoints with nested items and/or alternative preferences/opinions with (potentially multiple) top level items!

<div class="discussion">
* Tantek: I am '''leaning towards "Make photo property an object" brainstorm "2."''' because it feels more "automatic" and thus provides lower friction to more accessibility. Less (author) work for "alt" information to get passed through to the JSON result, and thus more potentially re-usable by consuming applications that want to preserve or re-emit the pairing of a photo and its fallback text alternative. -- [[User:Tantek|Tantek]] 00:53, 19 July 2016 (UTC)
* Aaron: I am leaning towards ''2'' because it takes less work on the part of publishers as well as consumers. From the publisher POV, if they add the alt attribute, that should be all they need to do, it seems odd to make them do additional work to make that show up in the parsed result. From the consumer side, some implementations will not need changing since when looking for a string value, they already use either the string directly or look for the "value" of the property if it's an object. Making consumers handle a new h- object just to read alt text seems overkill.
* Kevin: 2 makes sense to me as well, as this is a very specific need. If we want an image object with more substructure as 1 implies, that should be a new object type that follows the [[process]] - there is a case for that based on usage of figure/figcaption etc. but caption is not alt, and using name for it implies that it is. [[User:Kevin Marks|Kevin Marks]] 01:50, 19 July 2016 (UTC)
* ...

</div>

When it looks like thoughts are naturally converging, we should take that emergent convergence back to the github thread for proper back/forth discussion and figuring out of details.

https://github.com/microformats/microformats2-parsing/issues/2

== Parse language information ==
Raised by [[User:VoxPelli|VoxPelli]] 18:04, 23 July 2015 (UTC)
* 2016-060: Update: and parse "id" attribute. [[User:Tantek|Tantek]] 16:39, 29 February 2016 (UTC) (see Additionally below)
* 2016-07-13: Update: created [https://github.com/microformats/microformats2-parsing/issues/3 GitHub issue] for this brainstorm [[User:VoxPelli|VoxPelli]] 14:34, 13 July 2016 (UTC)

Currently there’s no way to tell the language of parsed microformats even if those microformats has been marked up with HTML "lang"-attributes.

There are examples in the wild of people marking up pages in such a way:

* [http://voxpelli.com/ VoxPelli.com] has a "lang"-attribute on the h-entry of his [http://voxpelli.com/2011/03/sista-dagen-p-good-old/ swedish articles] to signify that the article is swedish even though the rest of the site is english.
* Stephanie [http://climbtothestars.org/archives/2013/09/17/basic-bilingual-1-0-plugin-for-wordpress-blog-in-more-than-one-language/ uses a WordPress plugin] that adds summaries of other languages at the start of her content.

Proposal is to add a new "lang" keyword to h-* and e-* objects so that the following example:

<source lang=html4strict>
<div class="h-entry" lang="sv">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

This was [http://indiewebcamp.com/irc/2015-07-23#t1437667712078 brainstormed on the IndieWebCamp IRC-channel] where the mentioned example came up.

* Pull request for implementation in microformat-node added 2015-07-23 https://github.com/glennjones/microformat-node/pull/23
** Closed 2015-09-08 because the library has changed and parsing is now handled by microformat-shiv. New issue opened there: https://github.com/glennjones/microformat-shiv/issues/22
* Issue around implementation in php-mf2 added 2016-05-07 https://github.com/indieweb/php-mf2/issues/96

Additionally: consider the same for "id" attributes (use-case: rel=feed local discovery of a nested h-feed on the home page), specifically, parsing the first instance of any "id" attribute (ignoring latter duplicate id attribute values on any subsequent elements).

And alternatively: consider parsing as "html-id" and "html-lang" prefixed properties in the parsed result, e.g.

<source lang=html4strict>
<div class="h-entry" lang="sv" id="postfrag123">
<h1 class="p-name">En svensk titel</h1>
<div class="e-content" lang="en">With an <em>english</em> summary</div>
<div class="e-content">Och <em>svensk</em> huvudtext</div>
</div>
</source>

Would be parsed into something like:

<source lang=javascript>
{
"type": ["h-entry"],
"html-id": "postfrag123",
"html-lang": "sv",
"properties": {
"name": ["En svensk titel"],
"content": [
{
"html-lang": "en",
"html": "With an <em>english</em> summary",
"value": "With an english summary"
},
{
"html": "Och <em>svensk</em> huvudtext",
"value": "Och svensk huvudtext"
}
]
}
}
</source>

=== Language inheritance ===

If the "lang" attribute is not specified for a particular element, it is inherited from the nearest parent (or from the HTTP Content-Language header)

HTML5: https://www.w3.org/TR/html5/dom.html#the-lang-and-xml:lang-attributes<br>
HTML4: https://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2

Proposal: Determine and include the inherited "lang" value on *every* microformat object that directly specifies a lang or that has an ancestor that does, e.g. if <html lang="en">, then every object in the output will have "lang": "en".

=== Pronouns in different languages ===

Language is also useful context when defining [[pronouns]], discussed a bit here[https://github.com/idno/Known/pull/1426#issuecomment-217626923].

<source lang=html4strict>
<div class="h-card" lang="en">
<span class="p-x-pronoun-nominative">he</span> /
<span class="p-x-pronoun-possessive">him</span> /
<span class="p-x-pronoun-oblique">his</span>
</div>
</source>

would parse as

<source lang=javascript>
{
"type": ["h-card"],
"lang": "en",
"properties": {
"x-pronoun-nominative": ["he"],
"x-pronoun-possessive": ["him"],
"x-pronoun-oblique": ["his"]
}
}
</source>

It could also be useful to specify multiple languages within a single h-card (pardon me if I butcher Swedish pronouns)

<source lang=html4strict>
<div class="h-card">
<span lang="en" class="p-x-pronoun-nominative">he</span> /
<span lang="en" class="p-x-pronoun-possessive">him</span> /
<span lang="en" class="p-x-pronoun-oblique">his</span>
<span lang="sv" class="p-x-pronoun-nominative">han</span> /
<span lang="sv" class="p-x-pronoun-possessive">hans</span> /
<span lang="sv" class="p-x-pronoun-oblique">honom</span>
</div>
</source>

which might parse as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun-nominative": [{"lang": "en", "value": "he"}, {"lang": "sv", "value": "han"}],
"x-pronoun-possessive": [{"lang": "en", "value": "him"}, {"lang": "sv", "value": "hans"}],
"x-pronoun-oblique": [{"lang": "en", "value": "his"}, {"lang": "sv", "value": "honom"}]
}
}
</source>

or alternatively, we could introduce a new microformat h-x-pronoun to wrap a set of pronouns

<source lang=html4strict>
<div class="h-card">
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">he</span> /
<span class="p-possessive">him</span> /
<span class="p-oblique">his</span>
</div>
<div class="p-x-pronoun h-x-pronoun" lang="en">
<span class="p-nominative">han</span> /
<span class="p-possessive">hans</span> /
<span class="p-oblique">honom</span>
</div>
</div>
</source>

parsed as

<source lang=javascript>
{
"type": ["h-card"],
"properties": {
"x-pronoun": [{
"type": ["h-x-pronoun"],
"lang": "en",
"properties": {
"nominative": ["he"],
"possessive": ["him"],
"oblique": ["his"]
}
}, {
"type": ["h-x-pronoun"],
"lang": "sv",
"properties": {
"nominative": ["han"],
"possessive": ["hans"],
"oblique": ["honom"]
}
}]
}
}
</source>

<div class="discussion">
Discussion:
* [[User:Kylewm|Kylewm]] Including the "lang" attribute in h- and e- properties makes a ton of sense to me.
* [[User:Kylewm|Kylewm]] I like the idea of introducing an h-x-pronoun container that can define all the different pronoun forms for a particular language
* ...

</div>

== Canonicalization of datetime output ==
Status: resolved, awaiting implementation attempt/experience.

It would be useful to choose a (more) uniform output format for datetimes to make it easier for users of the parser to consume datetimes. Microformats2 parsers already do sophisticated pattern matching to recognize date vs. time vs. datetimes, so converting this to any specific format should not add overhead.

<div class="discussion">
Specifically:
* Choose either 'T' or space as the date/time separator.
** Prefer space as it is more human friendly/readable, which matters even for syntaxes/formats, as human still develop, debug them. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* Choose either +XXYY or +XX:YY as the timezone specification (and convert 'Z' to +0000).
** Would appreciate some study / input here as to which timezone offset syntax is more human friendly. I lean slightly toward +/-NNNN (without the colon) because in the context of seeing a time, leaving out the colon makes it less likely the offset will be confused for a time. E.g. "07:00-08:00" looks like 7-8am, even if it meant 07:00 in PST. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** Space is fine - consensus [[2015-01-20]] meetup.
* Parsers should ''not'' attempt make datetimes more exact than specified. They should not add time, seconds, or timezone if omitted in the original. [[User:Kylewm|Kylewm]] 04:02, 14 May 2014 (UTC)
** Agreed. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** or month, day per Tom Morris
** consensus [[2015-01-20]] meetup

* Counterpoint: PHP's builtin date parsing does not require strict formatting. And the equivalent functionality for Python is provided by the widely used python-dateutil library. [[User:Kylewm|Kylewm]] 19:02, 14 May 2014 (UTC)
** However we cannot (must not) depend on either PHP or Python's "smart" "fixing" or Postelian "liberal handling", or any other language/framework's for that matter, as they all differ in how "intelligent" they are. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
</div>

Perhaps just provide a guideline for these based on the above consensus.

== Add meta http-equiv to microformats2 parsing model ==
Status: disagreement, awaiting implementation attempt/experience.

Similar to document level parsing of <code>rel</code> attributes, it makes sense simultaneously to parse <code><meta http-equiv></code> elements, perhaps treating "Status" in a special way (only using first number (sequence of digits) for its "value").

Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes.
* http://indiewebcamp.com/deleted#HTML_meta_http-equiv_for_status

HTTP Header example:
* <samp>Content-Type: text/html; charset=utf-8</samp>
HTML equivalent:
* <code><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></code>

Related:
* https://www.w3.org/International/O-HTTP-charset

<div class="discussion">
* Interesting thought. Are you suggesting a top level "http-equivs:" collection similar to "rels:" in the parsed output? Should we consider "metas:" instead or in addition? [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
* What's the use case for this? Also, http-equiv on its own is useless. http-equiv is only a supplement to the data stored in headers. And headers aren't always there: what happens in the context of someone debugging a page who pastes the source into the textarea of an mf2 parser? Without a compelling use case for including headers (and then over-riding some of them with http-equivs), I'm not sure why an implementor want to do this. —[[User:TomMorris|Tom Morris]] 00:25, 8 May 2015 (UTC)
</div>

E.g. from https://gist.github.com/aaronpk/10297489

<source lang="html4strict">
<meta http-equiv="Status" content="410 GONE"/>
</source>

<source lang="javascript">
{
"items": [],
"rels": {},
"http": {
"status": 410
}
}
</source>

<div class="discussion">
* Maybe make this an optional pass in the parser? - Tom Morris [[2015-01-20]]
* For now, don't bother with metas until someone provides a use-case. Tom Morris
* Agreed on both counts. [[User:Tantek|Tantek]] 06:56, 21 January 2015 (UTC)
</div>

==MIME type==
See [[microformats2-mime-type]]

----

==Other Interpretation Parsing Notes==
Note: most of these need to be written up as separate [[microformats2-parsing-issues]]

Author: [[User:BenWard|Ben Ward]]

[[microformats-2|Microformats 2]] proposes a new, all encompassing syntax modification of [[microformats-2-prefixes|prefixes]] that will allow microformats to be parsed from pages by processors without prior knowledge of a vocabulary. The core components of this model are quite simple, are quite simple to implement, but there are a number of conflicts that emerge with the functionality of existing microformats parsers that need to be handled. This page documents a proposed model to separate these concerns clearly in a way that can be applied to the documentation of generic microformats parsing rules, and the documentation of individual vocabularies.

Collection of other unresolved parsing issues in a generic model:

This is good material for documenting as [[microformats-2-issues]], [[microformats-2-faq]], and perhaps some of the more technical details in [[microformats-2-parsing-faq]].

* The include pattern references other elements from elsewhere in a document. A generic parser needs to track IDs and fill them in after walking the DOM. (also, <code>itemref</code> if adopted.)
** The current thinking per [[microformats-2-brainstorming]] is to adopt <code>itemref</code> and drop the [[include-pattern]]. [[User:Tantek|Tantek]]
* Will <code>itemref</code> always map to an <code>item</code> property name?
** No, <code>itemref</code> maps to one or more elements by ids, and their children. Those referenced elements may have property class names themselves, or they may contain elements that do. [[User:Tantek|Tantek]]
* [[hAtom]] implies <code>author</code> from an hCard in a page that uses an <code>address</code> element. This requires format knowledge, but a generic parser does not currently track the element type of a property node. Should it?
** It should not. element-specific handling (e.g. using "alt" from img, and "title" from abbr) is completely done at parse time. The JSON data model does not reflect which element type or attribute the value came from. Additionally, [[hAtom]] is an example where we created far too many vocabulary-specific rules, in practice they're not necessary, and only complicate the microformat for both publisher understanding and parser implementation. [[User:Tantek|Tantek]]
* [[hAtom]] defines that the highest level heading within an entry implies <code>entry-title</code>. This particular optimisation might be better off dead.
** Agreed, this is gone in microformats 2. [[User:Tantek|Tantek]]
* [[hAtom]] defines that permalinks be parsed from <code>rel</code> attributes, not <code>class</code>
** In practice this has been one of the more problematic/error prone aspects of hAtom implementations, and it's also inconsistent with other microformats (although [[hReview]] tried to use both rel permalinks and "url"). The dependence upon [[rel-bookmark]] for permalinks is dropped in h-atom in preference to re-using "u-url" and "u-uid". [[User:Tantek|Tantek]]
* [[XFN]] is entirely built on <code>rel</code> (although, has various other differences from structural microformats, as do vote-links, so perhaps are excluded from this discussion and will always be handled by dedicated parsers/queries regardless?)
** The best (easiest and most reliable) use of 'rel' microformats in practice is when they are orthogonal to 'class' microformats. This is true both with [[XFN]] and some newer [[existing-rel-values|rel values]] like [[rel-author]]. In addition, it was very clear at the recent [[schema.org]] workshop's syntax session that RDFa's decision to apparently arbitrarily mix use of 'rel' and 'property' attributes for specifying different types of properties (it wasn't clear to people in the room when you use which for what) has caused a high degree of confusion among publishers and thus high error-rates. Thus if anything we should learn from both the mistakes of RDFa and our own experiences with even very deliberate/specific mixing of rel microformats in class microformats, and keep them defined as separate orthogonal building blocks that work together, but don't depend on each other. [[User:Tantek|Tantek]]
*** Relatedly to this: <code>rel-tag</code> in hAtom. --[[User:BenWard|BenWard]] 06:50, 5 October 2011 (UTC)
**** Yes, and two related things here. First, despite my (and others') objection and (past) interoperable post/entry-specific treatment by Technorati and Ice Rocket, Hixie has redefined rel-tag in [[HTML5]] to mean applying to the whole page, not a single post. Second, I've explicitly added 'p-category' to the draft 'h-atom' vocabulary in [[microformats-2]]. [[User:Tantek|Tantek]] 07:12, 5 October 2011 (UTC)
* HTML's <code>time</code> element includes an optional <code>pubdate</code> attribute. Simply: We should parse this as <code>dt-published</code>. --[[User:BenWard|BenWard]] 06:12, 10 October 2011 (UTC)
** *If* there is even some reasonable data on actual use of the "pubdate" attribute (I don't think there is, frankly, especially with the removal of the algorithm to produce Atom from HTML5), then we could consider parsing "pubdate" as backwards compatible option for "dt-published". As a general rule, however, it is bad (demonstrably/experienced) design to depend on additional attributes (c.f. RDFa confusion over "property" vs. "rel"), especially for an instance where no additional attribute is necessary. I would leave this out for now until there is non-trivial (more than just test pages or folks who've written HTML5 books, ahem) use in the wild. When there is such use in the wild, it should be documented on a wiki page. We don't want to encourage more complex (additional attribute) publishing as a result of supporting it. [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)
* [[value-class-pattern]]: In microformats-2, since there are no sub-properties, there will presumably no-longer be a 'value' property in any parsed model. Properties such as 'tel > type' in hCard are, as I recall, deprecated due to underuse anyway, so 'tel > value' becomes redundant. (There's also potentially some clarification around 'price > value' in hListing, whereby value was used in a pattern. So, what does this mean for value class parsing, with regard to value-title patterns and date separation patterns. Are we looking for a 'p-value' and 'p-value-title' classname, but treating them specially (excluding them from regular property parsing.) Or, are we giving them a special prefix (v-text, v-title? That seems confusing, but could be a concept.) I'm fine with p- for both, and just having the parser ignore them since they're special, but need clarification and naming confirmation. --[[User:BenWard|BenWard]] 09:35, 10 October 2011 (UTC)
** A few things:
*** 1. Yes, no more subproperties. 'tel' becomes just 'p-tel'. If there is demand for a structured 'tel' value, then we can use that demand (and research into publishing in practice) to brainstorm and create an 'h-tel' structured telephone number (with perhaps fields like 'type', 'extension', some indication of it being local dialing (an extra 0 in some countries) or international dialing, etc.) Or, we address the different 'tel' types as their own flat properties (again as justified by research), e.g. perhaps 'p-tel-fax', or 'p-tel-mobile'. Something for hcard-2-brainstorming.
*** 2. For prices, e.g. hListing, either we're going to need to encode how to parse monetary amounts including monetary symbols, or consider creating an 'h-price' structured price. Not sure what the right answer is here, again, will need to be informed by analysis of documented actual price publication practices.
*** 3. We should avoid introducing a new prefix 'v-' just for value-class-pattern. As we've noted elsewhere, each new prefix adds complexity and should be avoided without substantial advantage.
*** 4. Using 'p-value-title' is strange, as it would be an exception to 'p-' parsing, since it would get the value from the 'title' attribute whereas 'p-' properties don't normally do that (exception: abbr).
*** 5. Using 'p-value' is also strange, as it wouldn't generate a 'value' property in the JSON data model.
*** 6. Class name 'value-title' is already sufficiently prefixed - we've found or even heard of no collisions in practice.
*** 7. Class name 'value' can, by its simpler naming nature, be expected to potentially collide with other web designer class name usage though we have no documentation/mention thereof. We could consider a renaming, or providing of alternative, such as 'value-string', or 'value-content', etc. However, let's keep that as a backup plan to use only if/when evidence is presented that we need to.
** Conclusions: for now, in microformats-2, keep using 'value' and 'value-title' as defined in the [[value-class-pattern]], and add the additional (obvious) interpretation that [[value-class-pattern#Date_and_time_parsing|value class pattern: date and time parsing]] applies to all 'dt-' properties. - [[User:Tantek|Tantek]] 12:12, 10 October 2011 (UTC)

== incorporated 2015-05-28 ==
The following brainstorms were incorporated 2015-05-28.

== more information for alternates ==
Raised 2015-04-24 by [[User:Kevin Marks|Kevin Marks]]

The existing <code>alternate</code> parsing is omitting <code>title</code> - that should be added. The <code>text</code> would make sense to add here too.

Use-case: labels for presenting alternates

<div class="discussion">
* +1 Makes sense. [[User:Tantek|Tantek]] 03:41, 25 April 2015 (UTC)
</div>

== more information for rel-based formats ==
Raised 2015-04-18 by [[User:Kevin Marks|Kevin Marks]]

Related github test suite issue: https://github.com/microformats/tests/issues/16

Several rel-based formats have additional information that is useful beyond the link itself, which is all we capture at the moment. As I am trying to update the Universal feedparser to support mf2 based I will show examples from the [https://github.com/kevinmarks/feedparser/tree/365623a9470e99246f393a8c1f49a0db567826b8/feedparser/tests/microformats testcases] there.

The main change is to add a <code>rel-urls</code> entry for more information about the attributes and text of the urls pointed to by rel's in the document

A fork of mf2py that implements these changes is at https://github.com/kevinmarks/mf2py
=== rel-tag ===

<code><a rel="tag" href="http://del.icio.us/tag/tech">Technology</a> </code>

currently parses to:

<code>{"rels": {"tag": ["http://del.icio.us/tag/tech"]}, "items": []} </code>

This loses the link text, which is useful as a label.

We add a <code>rel-urls</code> element to the parsed output with this extra data that can be looked up from the rels, which doesn't break backward compatibility and works better with xfn (see below)

<code><pre>
{
"rels": {
"tag": [
"http://del.icio.us/tag/tech"
]
},
"items": [],
"rel-urls": {
"http://del.icio.us/tag/tech": {
"rels": [
"tag"
],
"text": "Technology"
}
}
}
</pre></code>

=== xfn ===

<code><a rel="coworker" href="http://example.com/johndoe">John Doe</a></code>

currently parses to:

<code>{"rels": {"coworker": ["http://example.com/johndoe"]}, "items": []}</code>

This loses the link text, which is the person's name. Suggested output using the urls object:

<code><pre>
{
{
"rels": {
"coworker": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker"
],
"text": "John Doe"
}
}
}
</pre></code>

with multiple xfn values

<code><a rel="coworker friend" href="http://example.com/johndoe">John Doe</a></code>
we get this:

<code><pre>
{
"rels": {
"coworker": [
"http://example.com/johndoe"
],
"friend": [
"http://example.com/johndoe"
]
},
"items": [],
"rel-urls": {
"http://example.com/johndoe": {
"rels": [
"coworker",
"friend"
],
"text": "John Doe"
}
}
}
</pre></code>

=== rel-enclosure ===

<code><a rel="enclosure" href="http://example.com/movie.mp4" type="video/mpeg" title="real title">my movie</a></code>

currently parses to:

<code>'{"rels": {"enclosure": ["http://example.com/movie.mp4"]}, "items": []}'</code>

This loses the link text, which is the title and the attributes which give type. Suggested output:

<code><pre>
{
"rels": {
"enclosure": [
"http://example.com/movie.mp4"
]
},
"items": [],
"rel-urls": {
"http://example.com/movie.mp4": {
"rels": [
"enclosure"
],
"text": "my movie",
"type": "video/mpeg",
"title": "real title"
}
}
}
</pre></code>

This generalises to other rel's too, such as [[rel-feed]] and [[rel-alternate]] that have type, lang etc attributes.

(updated to include changes from feedback below) [[User:Kevin Marks|Kevin Marks]] 22:13, 26 April 2015 (UTC)

=== attributes parsed ===
Attributes currently parsed are:
* <code>hreflang</code> for alternate and enclosure
* <code>media</code> for alternate and enclosure
* <code>title</code> for alternate and enclosure
* <code>type</code> for alternate and enclosure

Attributes we may consider parsing if we have a use case are
* <code>sizes</code> for icon - need use-case documentation
* <code>coords</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats
* <code>shape</code> for area - possibly for people tagging - no examples yet, and unnecessary as people-tagging requires using h-* microformats

In addition there is a special attribute <s><code>name</code> </s><code>text</code> which is the text contents of the link, which is useful in rel-tag rel-enclosure and xfn, and in alternate when used for feeds. It's also clarifying for rel-me links.

Tantek [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79057 suggests] we use <code>textContent</code> for this instead, and make it a single string, not a list as <code>name</code> is elsewhere in mf2 parsing
* Update: "text" is good enough, and "textContent" is ugly camelCase. [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)

=== feedback on more rel info ===
<div class="discussion">
# "name" is bad because it misleadingly conflates with use of "name" elsewhere in microformats2.
#* Suggested alternative: [https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent textContent] - since that's literally what is being returned there. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** as all other mf2 keys are lowercase-with-hyphens, [http://logs.glob.uno/?c=freenode%23microformats&s=today#c79101 Tantek suggests] 'text' as that isn't going to be an html [[User:Kevin Marks|Kevin Marks]] 07:28, 25 April 2015 (UTC)
# no need for array for "name"/textContent - since there is always only one at most
#* E.g. should be "textContent": "my movie" [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#* Update: "text": "my movie" [[User:Tantek|Tantek]] 04:39, 29 May 2015 (UTC)
# "urls" key is misleading - implies all URLs in the document, which is neither true, nor desired (takes much more parsing time and work and code)
#* Suggested alternative: "rel-urls". And open to better alternatives too. [[User:Tantek|Tantek]] 02:35, 25 April 2015 (UTC)
#** If we are trying to extend the number of properties retuned from a rel without breaking the old structure why don't we call the new structure something like "rels-extended" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#*** Extension is not the point, but rather to use them complementary. One structure for look-up of any rel value, hence "rels", which returns you a list of URLs. Then you can lookup those URLs in the new mapping, by URL, hence it is called "rel-urls" - that's the point to use them in conjunction and that's why rel-urls is named what it is. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

# Why is the structure of "rel-urls" different to the "alternates" structure. Should the "url" not just be added as a property and not as a key. Creating two data structures for one type of object seems inconsistent. It adds cognitive load to anyone trying to understand the JSON structure [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* I was trying to avoid breaking the existing <code>rels</code> structure and use of it - I did implement a variant that put the structure inside rels, and it became cumbersome and repetitive where there were multiple rels on a url (xfn cases). Denormalising as properties of the URL made more sense. It also dedupes if there is repetitive linking to the same URL, eg a series of posts with rel-author on each. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
# If the rel is a "tag" then the main value we need to return should be the last path component of the URL, not the link text? Should we add another output property ie "tag" [[User:GlennJones|Glenn Jones]] 12:29, 1 June 2015 (UTC)
#* No need to return last path segment of the URL, because the URL is already there - and that's just a library/framework utility function to get the last path segment of a URL. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)
# As currently described, the URL from <code>alternates</code> is repeated in the <code>rel-urls</code> structure. If we are doing this, surely <code>alternate</code> should be in <code>rels</code> too? I assumed a mapping between them. [[User:Kevin Marks|Kevin Marks]] 20:05, 1 June 2015 (UTC)
## edit showing this variant: http://microformats.org/wiki/index.php?title=microformats2-parsing&oldid=65021#parse_a_hyperlink_element_for_rel_microformats
</div>
#* Yes it makes sense to drop "alternates" assuming the backcompat impact is low, put alternates in "rels" along with everything else, and direct people to use rels and rel-urls for alternates functionality. Evidence this is an acceptable even preferable approach.[http://indiewebcamp.com/irc/2015-06-01/line/1433195247005] Will add an issue accordingly. [[User:Tantek|Tantek]] 22:03, 1 June 2015 (UTC)

== Incorporated 2015-06-06 ==

== Nested h-* objects' "value" property ==
Status: resolved, resolution iterated, one real world implementation proven implementability, incorporated
* 2015-06-06 incorporated into [[microformats2-parsing]]

Raised 2015-01-06 by [[User:Kylewm]];

If a child element has a microformat (h-*) and is a property element (p-*, u-*, dt-*, e-*), the parser will add a "value" property to the resulting object. The value should attempt to be a useful representation of the object for consumers that do not have semantic knowledge of the particular h-* type. Ref: [[microformats2-parsing#parse_an_element_for_class_microformats]].

To determine the "value", we parse the property element simply (as if it did not have a h-* class), which works well for simple h-* objects, e.g. <code><a class="u-like-of h-cite" href="...">...</a></code>

<div class="discussion">
* To handle more complex microformats, I propose that "value" for a p-* property element take on the first explicit "name" property of the nested microformat, and for a u-* property, the first explicit "url" property. Parsing will fall back on the current rules if an explicit property does not exist.
** This makes sense to me, and fits with the use-cases and examples I've seen. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** A similar (possibly simpler?) formulation would use the implied name and url rules to determine the "value" for p-* and u-* properties respectively
*** I don't think that's needed, as there are already implied rules on a property that should handle that. I'd start with just the "first explicit" scoping to be more conservative, and then see if we find any use-cases that (and existing implied rules) don't/doesn't catch. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
**** Agreement at [[2015-01-20]] meetup.
</div>

For example:

<code><pre>
<div class="h-entry">
<div class="u-in-reply-to h-cite">
<a class="p-author h-card" href="http://example.com">Example Author</a>
<a class="p-name u-url" href="http://example.com/post">Example Post</a>
</div>
</div>
</pre></code>

The nested u-in-reply-to object would parse as

<code><pre>
...
"in-reply-to": [{
"type": ["h-cite"],
"properties": {
"name": ["Example Post"],
"url": ["http://example.com/post"],
"author": [{
"type":["h-card"],
"properties": {
"url": ["http://example.com"],
"name": ["Example Author"]
},
"value": "Example Author"
}],
},
"value": "http://example.com/post"
}]
...
</pre></code>

where the outer "value" gets the in-reply-to h-cite's u-url property, and the inner "value" gets the author's p-name property.

<div class="discussion">
* Because there are no implied properties of the dt-* and e-* types, and no obvious defaults, the value rules for these types would not change.
** A possibility for dt-* h-*: The dt-* could take either the first dt-* of the h-*, or (perhaps if no dt-* in the h-*,) the first <code><time></code> element inside. [[User:Tantek|Tantek]] 19:31, 6 January 2015 (UTC)
** First dt-* seems reasonable, predictable, and usable. Consensus at [[2015-01-20]] meetup.
** Update 2015-05-29: no known use-cases for first dt-* or first e-*, and implementing that "would require some refactoring" (in mf2py at least per kylewm), thus until there's a use-case for first dt-*/e-* inside, let's treat "dt-* h-*" and "e-* h-*" as before. [[User:Tantek|Tantek]] . In particular:
*** p-* h-* - value from first "name" as proposed above
*** u-* h-* - value from first "url" as proposed above
*** e-* h-* - value is already defined for e-* parsing, nothing special here
*** dt-* h-* - value from normal dt-* parsing - nothing special.
*** +1 totally agree, let's wait for use cases of e-* dt-* [[User:Kylewm|Kylewm]] 19:44, 29 May 2015 (UTC)
</div>

* Implemented in mf2py 2015-06-01 https://github.com/tommorris/mf2py/commit/edc895ef5a780bcee654e6644a688688934517b0
* Added to microformats test suite (experimental) 2015-06-01 https://github.com/microformats/tests/commit/90c8a7d8e96c7160036a298e13f16d9ddaec218e

== see also ==
* [[microformats2]]
* [[microformats2-brainstorming]]
* [[microformats2-prefixes]]
* [[microformats2-faq]]
* [[microformats2-issues]]
* [[microformats2-parsing-faq]]

h-card

2016-06-27T23:10:16Z

Kevin Marks: /* dt-bday */

<entry-title>h-card</entry-title>
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML/HTML5.

h-card is the [[microformats2]] update to [[hCard]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal person example:

<source lang=html4strict>
<a class="h-card" href="http://example.com">Joe Bloggs</a>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Joe Bloggs"
],
"url": [
"http://example.com"
]
}
}
]
}
</source>

And a slightly more complete example:

<source lang=html4strict>
<p class="h-card">
<img class="u-photo" src="http://example.org/photo.png" alt="" />
<a class="p-name u-url" href="http://example.org">Joe Bloggs</a>
<a class="u-email" href="mailto:joebloggs@example.com">joebloggs@example.com</a>,
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
</p>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"photo": [
"http://example.org/photo.png"
],
"name": [
"Joe Bloggs"
],
"url": [
"http://example.org"
],
"email": [
"mailto:joebloggs@example.com"
],
"street-address": [
"17 Austerstræti"
],
"locality": [
"Reykjavík"
],
"country-name": [
"Iceland"
]
}
}
]
}
</source>

Nested h-card example

<source lang=html4strict>
<div class="h-card">
<a class="p-name u-url"
href="http://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="http://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["http://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["http://mozilla.org/"]
}
}]
}
}]
}
</source>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

=== Get started ===
The class '''<code>h-card</code>''' is a ''root class name'' that indicates the presence of an h-card.

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

For more complex examples, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

See [[microformats2-parsing]] to learn more about property classnames.

== Properties ==
h-card properties, inside an element with class '''h-card''':
* '''<code>p-name</code>''' - The full/formatted name of the person or organisation
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other/middle name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organisation
* '''<code>u-photo</code>'''
* '''<code>u-url</code>''' - home page
* '''<code>u-uid</code>''' - universally unique identifier, typically canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>'''
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

All properties are optional.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card takes place on [[h-card-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-card is ready to use and implemented in the wild, but for backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

== Property Details ==
(stub, to be expanded)

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<source lang=html4strict>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr h-adr">
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
</p>
</div>
</source>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, it helps to cluster which properties go with which address, e.g. home vs. work.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== dt-bday ===
Using truncated representations of dates for birth date is often good practice as noted in [https://tools.ietf.org/html/rfc6350#section-4.3.1 the vcard spec] eg
* 1985-04 for April 1985
* 1985 for the year 1985
* --0412 for April 12th without specifying a year.

=== Reserved properties ===
Reserved properties (not used much, if at all, in practice):

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' - timezone offset, e.g. <code><data class="p-tz" value="-0800">PST</data></code>
* '''<code>dt-rev</code>'''

== Examples in the wild ==
Real world in the wild examples:

* ... add uses of h-card you see in the wild here.
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Brett Comnes marks up his posts with h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([sandeep.io/101 example])
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [http://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [http://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [http://tantek.com/ Tantek Çelik] uses h-card on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [http://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with and h-card markup for people and organizations.
* [http://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-card markup
* WebMaker by Mozilla has [[microformats2]] h-card on event search (e.g. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]) and event pages (e.g. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* WebFWD by Mozilla has [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [http://indiewebcamp.com IndieWebCamp] has [[microformats2]] h-event markup with embedded h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats2]] h-event markup with attendees marked up with h-card.
* [https://tristanthomas.me Tristan Thomas] uses h-card on his home page
* [http://cold32.com/about-the-author-and-contact.htm Cold32.com] uses h-card (and h-geo) on its about-the-author-and-contact page
* [https://workfrom.co/ Workfrom.co] renders h-cards for venues (e.g. [https://workfrom.co/palio-dessert-and-espresso-house])
* [http://www.pcwdld.com/ PCWDLD.com] renders h-cards for download pages(e.g. [http://www.pcwdld.com/solarwinds-network-topology-mapper-review Download page example])

=== offline ===
* spreadly marks up share permalink pages with minimal h-cards inside h-entry

== Validating ==
* '''[http://indiewebify.waterpigs.co.uk/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hCard]] classnames in addition to the more future-proof h-card properties, for example:

<source lang=html4strict>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</source>

The class '''<code>vcard</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hCard]].

'''fn''', '''org''', and all the other backward compatibility hCard property class names are listed below.

=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: <code id="vcard">vcard</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== Additions ==
We've tried very hard with h-card to stay compatible with vCard4, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:
* [[h-card-brainstorming]]

== See Also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]

microformats2-parsing-issues

2016-04-12T19:09:01Z

Kevin Marks: /* issues */ add img fallback issue

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== img fallback in p- ===
Trying to make an author h-card without too many extra elements I first did:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" >mention.tech</a>
</div></pre>

rather than:
<pre><div class="p-author h-card">
<a href="/" class="p-org p-name"><img class="u-logo" src="/static/logo.jpg" alt="">mention.tech</a>
</div></pre>

I was surprised that the p-name and p-org took the src and the plaintext and concatenated them giving <code>http://mention-tech.appspot.com/static/logo.jpgmention.tech</code>, though that is the current spec (a separate php-mf2 bug ignored the empty alt when I added it).

While this is what the spec says, I can't think of a scenario where concatenating a string to a URL gives a useful result. Instead, if we fallback on the src of an img due to it having no alt I propose we put a space on beginning and end. As whitespace is stripped from beginning and end of p- values, this should still give the url in the simplest case, but avoid creating nonsensical URLs in cases like this.

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: [http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on this twitter markup]

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
** +1 I like the revised proposal and am happy to change my vote to this [[User:Aaronpk|Aaronpk]] 21:16, 13 March 2016 (UTC)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* +1 [[User:Barnabywalters|Barnaby]] agreed with Glenn, this would be a nice thing to have, but IMO it’s out of scope for the parser and should be specified separately. Personally I would probably implement it separately too, depending on how much work it is.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.
* 0 [[User:Barnabywalters|Barnaby]] to me this should be treated the same as the script/style contents — removed completely from all plaintext properties, but left unaltered in raw HTML.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* [[User:Barnabywalters|Barnaby]] in theory, as the video and audio data by default can’t be included in plaintext properties, and the fallback content (much like img alt attributes) should be somehow human-readable and useful, I would suggest keeping it in plaintext properties. I’d like to see some real-world examples of what fallback content people are using — if it’s links or plaintext descriptions this approach could work well, if people are writing instructions saying “install flash” or “update your browser” it’s not going to produce very pretty results
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided?

Should "p-name" still be implied if another explicit class is already provided?

Here is a somewhat contrived "u-url" related example, taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** -0 failed consensus, this proposal is rejected. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo
**** though if there is an img with u-featured but not u-photo, it's likely that was an explicit author decision (e.g. for an article) - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** Especially difficult to make a case for name.
**** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
**** Yet over-implied p-names appear to cause problems with many Bridgy webmention consuming use-cases[https://indiewebcamp.com/irc/2016-04-01/line/1459530869915], that's a good case - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
**** may need a broader rule, like any explicit p-* property on an element stops implied p-name. - [[User:Tantek|Tantek]] 22:11, 1 April 2016 (UTC)
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-20T23:59:56Z

Kevin Marks: /* dedupe URLs? */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== de-dupe URLs? ===
Currently, Known templates end up linking to the author's url in the h-card twice. This leads to duplicate URLs in the parsed output, which make jf2 conversion insert a children element.
Should we be deduping URLs? Or is this a GIGO issue?

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: [http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on this twitter markup]

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
** +1 I like the revised proposal and am happy to change my vote to this [[User:Aaronpk|Aaronpk]] 21:16, 13 March 2016 (UTC)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* +1 [[User:Barnabywalters|Barnaby]] agreed with Glenn, this would be a nice thing to have, but IMO it’s out of scope for the parser and should be specified separately. Personally I would probably implement it separately too, depending on how much work it is.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.
* 0 [[User:Barnabywalters|Barnaby]] to me this should be treated the same as the script/style contents — removed completely from all plaintext properties, but left unaltered in raw HTML.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* [[User:Barnabywalters|Barnaby]] in theory, as the video and audio data by default can’t be included in plaintext properties, and the fallback content (much like img alt attributes) should be somehow human-readable and useful, I would suggest keeping it in plaintext properties. I’d like to see some real-world examples of what fallback content people are using — if it’s links or plaintext descriptions this approach could work well, if people are writing instructions saying “install flash” or “update your browser” it’s not going to produce very pretty results
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-19T07:33:20Z

Kevin Marks: /* ignore u-camelCase properties */ hide too-long URL

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: [http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on this twitter markup]

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
** +1 I like the revised proposal and am happy to change my vote to this [[User:Aaronpk|Aaronpk]] 21:16, 13 March 2016 (UTC)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* +1 [[User:Barnabywalters|Barnaby]] agreed with Glenn, this would be a nice thing to have, but IMO it’s out of scope for the parser and should be specified separately. Personally I would probably implement it separately too, depending on how much work it is.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.
* 0 [[User:Barnabywalters|Barnaby]] to me this should be treated the same as the script/style contents — removed completely from all plaintext properties, but left unaltered in raw HTML.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* [[User:Barnabywalters|Barnaby]] in theory, as the video and audio data by default can’t be included in plaintext properties, and the fallback content (much like img alt attributes) should be somehow human-readable and useful, I would suggest keeping it in plaintext properties. I’d like to see some real-world examples of what fallback content people are using — if it’s links or plaintext descriptions this approach could work well, if people are writing instructions saying “install flash” or “update your browser” it’s not going to produce very pretty results
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2016-03-19T07:32:22Z

Kevin Marks: /* add unicode generation issue */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== unicode generation in JSON ===
Currently we will convert HTML entities into unicode as part of the parsing process. However, these and other non-asciicharacters can be output as escaped unicode in the generated JSON
Broadly this is OK, as we assume JSON parsers should be able to handle this accordingly.
However, it does mean the text is somewhat ambiguous, and unclear, especially when complex unicode codepoints like emoji are involved.

Secondarily, when the parsed output of an e- element is presented, having \u escaped text in the HTML is not really valid, and utf8 would be preferred. That way the JSON output could safely pass through a naive string concatenation model as well as a valid unicode decoder (some languages do not cope with astral plane unicode well, yet utf8 safely encodes them).

See https://github.com/tommorris/mf2py/issues/65 for further discussion of this.

I have tweaked unmung to output utf8 instead for inline data entry, eg: [http://www.unmung.com/?url=&html=%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3EEntity+%26mdash%3B+emdash%3C%2Fspan%3E%3C%2Fdiv%3E%0D%0A%3Cdiv+class%3D%22h-entry%22%3E%3Cspan+class%3D%22e-name%22%3Eunicode+%E2%80%94+emdash+%E2%AD%90%EF%B8%8F%E2%9A%A1%EF%B8%8F%3C%2Fspan%3E%3C%2Fdiv%3E&pretty=on this case]

=== ignore u-camelCase properties ===
Due to Suit CSS (and others? citations?) recent (2015-?) use of "u-*" class names for so-called "[http://davidtheclark.com/on-utility-classes/ utility classes]", we are seeing some false positives in a few very rare instances, e.g.: http://www.unmung.com/mf2?url=http%3A%2F%2Fwww.kevinmarks.com%2Ftwitterutils.html&html=&pretty=on

(Nearly) all these "utility classes" use camelCase for the class name suffixes, thus we can filter them out by looking for camelCase (since microformats class name conventions are always all lowercase and hyphenated), or even just looking for (and rejecting) *any* capital letters.

Proposal:
* microformats2 parsers MUST IGNORE u-* classnames where the * has any uppercase letter(s).

<div class="discussion">
* +1 [[User:Tantek|Tantek]] Let's get this fix rolling quickly to avoid further pollution.
* +1 [[User:Barnabywalters|Barnaby]] php-mf2 already ignores classnames with capitalised prefixes, ignoring any classnames with capital letters seems totally reasonable
* ...
</div>

=== exclude style elements before parsing ===
[http://logs.glob.uno/?c=freenode%23microformats#c85457 2016-01-25 raised in #microformats]

Ran into an issue of a <style> element being parsed as plain text in a p-name. Should [[microformats2-parsing]] be updated to indicate <style> should be excluded when parsing? Appears to implicitly fall under [[microformats2-parsing#note_HTML_parsing_rules]]

Sample link: http://veganstraightedge.com/notes/2016/01/16/tonight-s-dinner-tacocleanse-beverly-hills-c

The <script> tag can be similarly problematic.

Proposal: Drop both <script> and <style> elements completely when parsing any property (including e-* HTML values). [[User:Tantek|Tantek]] 01:01, 29 February 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Aaronpk|aaronpk]] as a consumer of HTML from an e-* property, I will always be sanitizing the HTML and removing <script> and <style> anyway
* +1 [[User:Kylewm|kylewm]]
* 0 [[User:Barnabywalters|Barnaby]] +1 to removing the contents of <script> and <style> from all plaintext properties (and 'value' property in HTML dicts), -1 to removing <script> and <style> from HTML. That’s a job for a sanitization stage. As aaronpk points out, sanitization will have to be done anyway if the content is to be reposted, so doing so in the parser doesn’t actually save anyone any work, but removes information which could be useful to people (example use cases: publishing posts with embedded per-post styling, publishing interactive HTML documents with embedded javascript)
** +1 this seems like reasonable feedback to make a new refined proposal. [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)
** +1 I like the revised proposal and am happy to change my vote to this [[User:Aaronpk|Aaronpk]] 21:16, 13 March 2016 (UTC)
** +1 Totally agree with narrowing the proposal. All the problems I've had with script and style tags come from plaintext properties, and agree that they may even be useful to some consumers of the HTML properties (e.g. an embedded YouTube video) [[User:Kylewm|Kylewm]] 23:40, 13 March 2016 (UTC)
</div>

Proposal 2: Drop both <script> and <style> elements completely when parsing any property (except for e-* HTML values, which preserve all markup). [[User:Tantek|Tantek]] 20:37, 13 March 2016 (UTC)

<div class="discussion">
Please discuss and/or give +1/0/-1 feedback
* +1 [[User:Tantek|Tantek]] as proposer
* +1 [[User:Barnabywalters|Barnaby]]
* ...
</div>

=== use poster if no src on video for u props ===
[https://indiewebcamp.com/irc/2015-12-13#t1450035721661 2015-12-13 raised in #indiewebcamp]

There is a use-case of marking up the "poster" of a video element as the u-featured of an [[h-entry]], to do that, we need to change [[microformats2-parsing#parsing_a_u-_property|u- property parsing]] to look at the poster attribute of the video element, after it's looked for the src attribute.
<blockquote>" else if video.u-x[poster], then get the poster attribute "</blockquote>

Real-world example of markup in the wild:
* http://veganstraightedge.com/videos/2013/5/31/1/backyard-squirrel-buddy
** and likely all other videos posted there.

Background discussion that led to this proposal:
* https://indiewebcamp.com/irc/2015-12-13#t1450035721661

This seems very straightforward so I've added it as PROPOSED directly in the parsing spec. This issue is for tracking the discussion.

Feedback from parser implementers please!
<div class="discussion">
* +1 [[User:Barnabywalters|Barnaby]] easy to implement and based on real-world markup, no objections
* ...
</div>

=== uf2 children on backcompat properties ===
[http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632 2015-11-24 raised by Calli] in #microformats

Related but different from [[#uf2_children_inside_a_classic_microformats_root_class_name]], when there is a uf2 child directly on a backcompat property, what should happen? E.g.

<source lang=html4strict>
<div class="vcard">
<div class="adr h-adr">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

What is the expected behavior and parser output?

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-adr"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

<div class="discussion">
* Proposal: the nested "adr h-adr" child is treated as an mf2 object, not backcompat, and thus the resulting parsed "locality" property has a single value of "MF2". Proposed by Calli, noting that Glenn Jones's microformatshiv gets that result currently, and it would be easier for him (Calli) to implement this way.
** +1 Tantek, seems reasonable and the reasoning provided is good (we have one implementation this way already)
** +1 Kyle, this is consistent with the resolution to the related issue
** +1 Calli, yes, this is easier for me to implement (than taking both MF1 and MF2 properties) because it is consistent - for me, consistency is the controlling factor in favor rather than ease of parser implementation
** +1 Barnaby, php-mf2’s mf1 backcompat produces this exact result, and it makes a lot of sense to me
** ...
</div>

Another example:

<source lang=html4strict>
<div class="vcard">
<div class="adr h-custom">
<div class="locality">MF1</div>
<div class="p-locality">MF2</div>
</div>
</div>
</source>

<source lang=javascript>
"items": [{
"type": ["h-card"],
"properties": {
"adr": [{
"value": "MF1MF2",
"type": ["h-custom"],
"properties": {
"locality": ["MF2"],
"name": ["MF1MF2"]
}
}]
}
}]
</source>

Per the [[#any_h-_root_class_name_overrides_and_stops_backcompat_root]] resolution, the class name "h-custom" overrides the use of "adr" as a backcompat root.

=== default generated HTML ===
2015-09-08 raised by Tantek in #indiewebcamp

Should there be a default (perhaps not quite "canonical") way to map/generate HTML+microformats2 from a parsed mf2 JSON output?

E.g. straw proposal:
* JSON/mf2 -> [[XOXO]]+mf2

Existing work / mappings:
* https://github.com/snarfed/granary/blob/master/granary/microformats2.py#L295

Related to:
* https://github.com/snarfed/granary/issues/31

Use-cases:
* default webview / presentation for a site that stores mf2 JSON output
* possibly a way to implement a distributed HTTP webcache retrieval protocol

Thoughts?
<div class="discussion">
* +1 [[User:Tantek|Tantek]] I think we should have this, but am open to proposals on specifics!
* +1 [[User:GlennJones|Glenn]] Also think this is worth looking at, but I am not sure it should be part of the parser spec. Feels like it should be built as a separate library and have it own spec on the microformats wiki.
* +1 [[User:Barnabywalters|Barnaby]] agreed with Glenn, this would be a nice thing to have, but IMO it’s out of scope for the parser and should be specified separately. Personally I would probably implement it separately too, depending on how much work it is.
* ...
</div>

=== Noscript skip/parse ===
2015-07-28

Should mf parsers skip <code><noscript></code> tag in the HTML, like the <code><template></code> tag mentioned in http://microformats.org/wiki/microformats2-parsing#note_HTML_parsing_rules ?

mf2py skips <code><noscript></code> when using the html5lib DOM parser but no when using lxml parser. Example use of <code><noscript></code> https://kartikprabhu.com/ featured images have a no javascript fallback image inside <code><noscript></code> with <code>class='u-featured'</code> markup.
* html5lib actually HTML-escapes the contents of <code><noscript></code>, so to mf2py it just looks like plain text with no tags. In Woodwind, I've resorted to using regex to strip out <code><noscript></code> tags before parsing (very hacky). [[User:Kylewm|Kylewm]] 15:52, 25 August 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] skip noscript (and inside) because in today's typical browsing contexts, nothing in noscript is displayed, thus we should discourage marking up effectively invisible content.
** Proposed change to [[microformats2-parsing#parse_a_document_for_microformats]]:
*** from: "follow the HTML parsing rules"
*** to: "follow the HTML parsing rules (including skipping/omitting <code><noscript></code> elements, e.g. like the html5lib DOM parser)
* -1 [[User:GlennJones|Glenn]] This subject does need to be address, but differently to proposed change. My personal view is that e-* html should be passed through raw and then the consumer can process it in a way they feel fit. Its a case for helper libraries. I am about to build a helper library to do this based on the Readability code to post process e-* html. Other people may want to take different approaches, defining this in the spec feels like move into a whole area of new functionally.
* 0 [[User:Barnabywalters|Barnaby]] to me this should be treated the same as the script/style contents — removed completely from all plaintext properties, but left unaltered in raw HTML.

As a separate new point we need to consider "exclude tags" lists for parsed text from html. We should consider <code><noscript></code>, <code><noframe></code> and <code><template></code> there maybe other I have not gone through all the tags in current HTML spec. Also we should consider what to do about the more common pattern of fallback text within media tags <code><video></code>, <code><audio></code> etc. This should be explicitly discussed in the parsing rules. At the moment my experimental text normalisation does exclude tags, but the default text parse does not. Currently the fallback content in media tags like <code><video></code> is added to the parse text. 12:56, 25 Septemeber 2015 (UTC)
* [[User:Barnabywalters|Barnaby]] in theory, as the video and audio data by default can’t be included in plaintext properties, and the fallback content (much like img alt attributes) should be somehow human-readable and useful, I would suggest keeping it in plaintext properties. I’d like to see some real-world examples of what fallback content people are using — if it’s links or plaintext descriptions this approach could work well, if people are writing instructions saying “install flash” or “update your browser” it’s not going to produce very pretty results
* ...
</div>

=== Standard datetime format ===
2015-07-28

http://microformats.org/wiki/microformats2-parsing#parsing_a_dt-_property does not specify any standard format to use for datetimes. e.g. <pre>2015-07-28T12:55:33</pre> vs <pre>2015-07-28 12:55:33</pre>
Would be good to standardize this to compare various parser outputs.

2015-07-29: This subject is (somewhat) covered in http://microformats.org/wiki/iso-8601 As it stands the JavaScript parsers support output in the 3 main profiles, 'W3C Note', 'RFC 3339' and 'HTML5' plus 'auto' which keeps authors format. The default date output for the JavaScript parsers is the same format as the date was originally authored in. This can be changes by setting the options.dateFormat switch to any of the other profiles mentioned. It would be good if other parser also had a switch to force output to a common profiles so we could compare various parser outputs, but I think the default should be how a date was authored. All output whatever profile should also keeps the authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string. This is important if you want to compare parser outputs.

The only exception to this where date and times are combined such as the implied h-event rule for dt-start and dt-end where I output in the HTML5 style 2015-07-29 12:55:33 as there is no predefined author preference and HTML5 profile is more human readable. [[User:GlennJones|Glenn Jones]] 11:02, 29 July 2015 (UTC)

<div class="discussion">
* +1 [[User:Tantek|Tantek]] output more human readable <code>2015-07-28 12:55:33</code> canonically, with authored level of specificity, i.e. not adding minutes or seconds if they are not in the input date string.
** Let's update any test cases as needed for this. - [[User:Tantek|Tantek]]
* ...
</div>

=== implied date for dt properties both mf2 and backcompat ===
The [[value-class-pattern#microformats2_parsers|value class pattern dt-* date proposal]] should apply to both mf2 dt-* properties, and backcompat classic microformats, to preserve the hAtom / hCalendar optimizations noted on that page, but in a generic way.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] 16:12, 18 August 2015 (UTC)
* +1 [[User:Glenn Jones|Glenn Jones]] 20 August 2015
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)
*** +1 this seems reasonable, if a publisher is going to add an mf2 class, it is unlikely they want other classes automatically implied from the same value [[User:Aaronpk|Aaronpk]] 23:19, 29 November 2015 (UTC)
*** -1 for now. To my knowledge, this has only been observed in artificially constructed unit tests and examples, and it adds some weird edge cases that are hard to reason about. [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** ... provide input on this proposal here
** Refined: Or should this be refined by per parsing prefix? [[User:Tantek|Tantek]] 22:59, 18 September 2015 (UTC)
*** Any explicit "p-*" property means no implied "p-name" from that element
*** Any explicit "u-*" property means no implied "u-url" nor "u-photo" from that element.
*** ... provide input on this refined proposal here
** Suggestion: split this issue up per property. I think it makes sense for u-url and can be easily added to the spec as e.g. ".h-x>a[href]:only-of-type:not[.h-*<strong>,.u-*</strong>]". [[User:Kylewm|Kylewm]] 00:46, 1 December 2015 (UTC)
*** Obviously wrong to assume a link explicitly pointing elsewhere is our "url"
*** More difficult to make a case for photo and especially for name.
*** "name" is implied at least by [.h-x textContent], so often the excluded element would end up included anyway.
*** ... provide input on this refined proposal here
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform to the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== Empty properties overridden by implied rules against user expectation ===
Status: resolved, existing behavior correct, no changes to parsing spec.

2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* <strike>+1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
* -1 I agree with the other -1s. This would break some of the simplicity of the model. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* <strike>-1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)</strike>
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* +1 We already have interop on this between mf2py and phpmf2, as well as people depending on it to explicitly set empty property values. [[User:Tantek|Tantek]] 05:12, 14 July 2015 (UTC)
* +1 As we already have interop with two parsers and solid user issue from Emma we should take this approach. [[User:GlennJones|Glenn Jones]] 11:51, 29 July 2015 (UTC)</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== uf2 children inside a classic microformats root class name ===
Status: incorporated into [[microformats2-parsing]]

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* +1 I think this is the best option I will implement it and update the wiki once its in the JavaScript parser. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names on that same element. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
* I don't think I understand this rule. If I was stop all parsing of of classic microformats in the presence of any h-* root in a document then some of the other rules such as "uf2 children inside a classic microformats root class name" do not make sense. Could this item be expanded and explained a bit more? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** added "on that same element" as that was what we were discussing/implying in this issue. [[User:Tantek|Tantek]] 22:49, 18 September 2015 (UTC)
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behaviour was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== microformats2 root class names should only see microformats2 properties ===
Status: incorporated into [[microformats2-parsing]]

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* +1 I think this will help backcompat parsing, I will implement it and update the wiki once its in the JavaScript parser. The test suite will also need updating. [[User:GlennJones|Glenn Jones]] 11:55, 29 July 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Block overlapping properties from different microformat versions"

=== implied properties on backcompat parsing unlikely to be intended ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** +1 I think this will help backcompat parsing, but there are two major things to consider. It may well break some consumer code as the output for a microformats currently always has the name property, there may not be the defences code to check this is true when we remove the implied name rule for classic microformats. The test suite will also need major updating as all the test output for classic microformats will have. I will look into implementing this and report back to the wiki. [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
** Also it should be made clear that we are only removing the implied rules from classic microformats parsing and not the value property? [[User:GlennJones|Glenn Jones]] 12:13, 29 July 2015 (UTC)
*** The "parsing for implied properties" section only references name, photo, url properties. Where (in the spec) is the confusion about "value" coming from? [[User:Tantek|Tantek]]
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

2015-08-21: [[User:Glenn Jones|Glenn Jones]]
Now implemented in microformat-shiv can be tested at http://microformatshiv.com/editor.html Currently you need to switch on the option "Set implied properties by microformat version"

=== link elements and u- parsing ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

rel-webmention

2015-11-25T23:47:30Z

Kevin Marks: link to webmention spec

{{stub}}

<code>rel=webmention</code> is a way to link to a [[webmention]] endpoint.

[https://indiewebcamp.com/Webmention Webmention] is a simple way to notify any URL when you link to it on your site. From the receiver's perspective, it's a way to request notifications when other sites link to it. Webmention is a modern update to Pingback, using only HTTP and x-www-form-urlencoded content rather than XMLRPC requests. Webmention supersedes Pingback.

existing-rel-values

2015-11-25T23:44:56Z

Kevin Marks: /* HTML5 link type extensions */ fix webmention spec url

<entry-title> existing rel values </entry-title>

This page contains tables of known HTML rel values from specifications, formats, proposals, brainstorms, and non-trivial [[POSH]] usage in the wild. In addition, dropped and rejected values are listed at the end for comprehensiveness.

<span id="usage">usage</span>: see [[rel-faq#How_is_rel_used|how is 'rel' used]]. Regarding <span id="rev">rev</span>, see: [[rel-faq#Should_rev_even_be_used|should 'rev' even be used]].

This page is also the official rel registry ([http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types][http://www.w3.org/TR/html5/links.html#other-link-types]). Add new and proposed rel values to the following section:
* [[existing-rel-values#HTML5_link_type_extensions|HTML5 link type extension]]

== formats ==
These rel values are defined formats from specifications (HTML 4, microformats) are thus are <strong>recommended for general use</strong>. Alphabetically ordered by value.

Note:
* <strong>Do not</strong> add proposed rel values for HTML5 here, add them to the [[#HTML5_link_type_extensions|HTML5 link type extensions]] table.
* <strong>Do not</strong> add rel values you find in the wild to this table of rel formats, instead add them to the table in the [[existing-rel-values#POSH_usage|POSH section]].
* <strong>Do not</strong> add non-HTML rel values you find to this table of rel formats, instead add them to the table in the [[existing-rel-values#non_HTML_rel_values|non HTML rel values section]].
* <strong>Do not</strong> add rel values from obsolete/superceded proposals or drafts, instead add them to the table in the "dropped" section.

Sources:
* W3C Recommendations:
** [http://www.w3.org/TR/html401/types.html#h-6.12 HTML 4.01 section 6.12 Link types] (HTML4 Link types)
** [http://www.w3.org/TR/grddl/ Gleaning Resource Descriptions from Dialects of Languages] (GRDDL)
* [[microformats]] specifications
** [[xfn]]
** [[rel-license]]
** [[rel-nofollow]]

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description <br />(from the relevant specification where possible)
! Link to defining specification

|-
| [[rel-acquaintance|acquaintance]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance
| [[XFN]]

|-
| [[rel-alternate|alternate]]
| external resource
| external relation
| Designates substitute versions for the document in which the link occurs. When used together with the <code>lang</code> attribute, it implies a translated version of the document. When used together with the <code>media</code> attribute, it implies a version designed for a different medium (or media).
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-appendix|appendix]]
| allowed
| allowed
| Refers to a document serving as an appendix in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-bookmark|bookmark]]
| not allowed
| allowed
| Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The <code>title</code> attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-chapter|chapter]]
| allowed
| allowed
| Refers to a document serving as a chapter in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-child|child]]
| not allowed
| external relation
| the referenced person is a child of the person represented by the current document
| [[XFN]]

|-
| [[rel-colleague|colleague]]
| not allowed
| external relation
| the referenced person is a colleague of the person represented by the current document
| [[XFN]]

|-
| [[rel-contact|contact]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a contact
| [[XFN]]

|-
| [[rel-contents|contents]]
| allowed
| allowed
| Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from "Table of Contents").
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-copyright|copyright]]
| allowed
| allowed
| Refers to a copyright statement for the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-co-resident|co-resident]]
| not allowed
| external relation
| the referenced person lives in the same residence as the person represented by the current document
| [[XFN]]

|-
| [[rel-co-worker|co-worker]]
| not allowed
| external relation
| the referenced person is a co-worker of the person represented by the current document
| [[XFN]]

|-
| [[rel-crush|crush]]
| not allowed
| external relation
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)
| [[XFN]]

|-
| [[rel-date|date]]
| not allowed
| external relation
| this person considers the referenced person to be a date (i.e. is dating the referenced person)
| [[XFN]]

|-
| [[rel-friend|friend]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a friend
| [[XFN]]

|-
| [[rel-glossary|glossary]]
| allowed
| allowed
| Refers to a document providing a list of terms and their definitions that pertain to the current document.||[http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-help|help]]
| allowed
| allowed
| Refers to a document offering help (more information, links to other sources information, etc.)
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-its-rules|its-rules]]
| allowed
| not allowed
| Refers to a document with external ITS rules.
| [http://www.w3.org/TR/its20/#selection-global-html5 Internationalization Tag Set (ITS) Version 2.0]

|-
| [[rel-kin|kin]]
| not allowed
| external relation
| the referenced person is part of the extended family of the person represented by the current document
| [[XFN]]

|-
| [[rel-license|license]]
| allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is a license for the current page.
| [[rel-license]]

|-
| [[rel-me|me]]
| external relation
| external relation
| the referenced document represents the same person as does the current document
| [[XFN]]

|-
| [[rel-met|met]]
| not allowed
| external relation
| this person has met the referenced person
| [[XFN]]

|-
| [[rel-muse|muse]]
| not allowed
| external relation
| the referenced person inspires the person represented by the current document
| [[XFN]]

|-
| [[rel-neighbor|neighbor]]
| not allowed
| external relation
| the referenced person lives nearby the person represented by the current document
| [[XFN]]

|-
| [[rel-next|next]]
| external relation
| external relation
| Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-nofollow|nofollow]]
| not allowed
| external relation
| indicates that the destination of that hyperlink {{should-not}} be afforded any additional weight or ranking by user agents which perform link analysis upon web pages (e.g. search engines).
| [[rel-nofollow]]

|-
| [[rel-parent|parent]]
| not allowed
| external relation
| the referenced person is a parent of the person represented by the current document
| [[XFN]]

|-
| [[rel-prev|prev]]
| external relation
| external relation
| Refers to the previous document in an ordered series of documents. Some user agents also support the synonym "Previous".
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-previous|previous]]
| external relation
| external relation
| Synonym of <code>prev</code>
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-section|section]]
| allowed
| allowed
| Refers to a document serving as a section in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sibling|sibling]]
| not allowed
| external relation
| the referenced person is a sibling of the person represented by the current document
| [[XFN]]

|-
| [[rel-spouse|spouse]]
| not allowed
| external relation
| the referenced person is a spouse of the person represented by the current document
| [[XFN]]

|-
| [[rel-start|start]]
| allowed
| allowed
| Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-stylesheet|stylesheet]]
| external resource
| not allowed
| a style sheet for the current document<br /> used with the invisible <link href> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <a href> are strongly preferred. Unfortunately the use of stylesheet in user visible content like <a href> appears to be strictly theoretical.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-subsection|subsection]]
| allowed
| allowed
| Refers to a document serving as a subsection in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sweetheart|sweetheart]]
| not allowed
| external relation
| this person considers the referenced person to be their sweetheart
| [[XFN]]

|-
| [[rel-tag|tag]]
| not allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is an author-designated "tag" (or keyword/subject) for the current page.
| [[rel-tag]]

|-
| [[rel-toc|toc]]
| allowed
| allowed
| Synonym of <code>contents</code> (from "Table Of Contents")
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-transformation|transformation]]
| allowed
| allowed
| Relates a source document to a transformation, usually represented in XSLT, that relates the source document syntax to the RDF graph syntax. Used in [[grddl|GRDDL]]
| [http://www.w3.org/TR/grddl/#transformation GRDDL]

|}

=== notes ===
*<code>rel="alternate"</code> can take further meaning from additional attributes, such as
** <code>rel="alternate" lang="fr"</code> (French language version of this page)
** <code>rel="alternate" media="print"</code> (printable version of this page)
** <code>rel="alternate" media="handheld"</code> (version of the page intended or better for handheld/portable devices like PDAs, cell phones, etc.)

*Synonyms such as "previous", "toc" are not as widely supported as the main term.

== proposals ==
A few rel values have been developed as drafts as a result of going through most of the microformats [[process]], and are thus listed here for your serious consideration. You <strong>may use these values</strong>, and if you find any problems with them please point them out on the respective "issues" page for the rel value.

{| border="1"
|+
! rel value !! summary !! proposed in !! external spec (if any)
|-
| [[rel-pronunciation|pronunciation]] || …indicates that the destination of the 'link' element is a document providing a pronunciation lexicon for speech-synthesis purposes. || [[rel-pronunciation]]
|-
| [[rel-directory|directory]] || …indicates that the destination of the hyperlink is a directory listing containing an entry for the current page. || [[rel-directory]]
|-
| [[rel-enclosure|enclosure]] || …indicates that the destination of that hyperlink is intended to be downloaded and cached. || [[rel-enclosure]] || [http://www.apps.ietf.org/rfc/rfc4287.html RFC4287]
|-
| [[rel-home|home]] || …indicates that the <nowiki>[referenced document]</nowiki> is the homepage of the site in which the current page appears. || [[rel-home]]
|-
| [[rel-payment|payment]] || …indicates that the destination of the hyperlink provides a way to show or give support (e.g. financial) for the current page|| [[rel-payment]]
|}

== HTML5 link type extensions ==

The following values are registered as link type extensions per the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types requirements in the WHATWG HTML spec] and the [http://www.w3.org/TR/html5/links.html#other-link-types requirements in the W3C HTML5 spec].

Before you register a new value:
* '''Please check the [[#formats|Formats table]] and DO NOT re-register''' rel values that are already there. Please note that the W3C HTML WG has made a [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Decision] to drop <code>index</code>, <code>up</code>, <code>first</code> and <code>last</code> from the HTML5 spec itself.
* '''Please check the [[#dropped|Dropped table]] and DO NOT register''' values that are already there. If you believe a rel value was dropped from another specification without prejudice, please provide link/cite to explicit text/decision stating as such, e.g. the value was merely postponed, or perhaps expected to be spun-out into its own spec from the group developing that specification.

Note that entries in the [[#formats|Formats table]] and entries that are already in HTML5 as built-in keywords are also considered extensions with the "Ratified" status.

Please make sure that registrations added here have all the required data filled in ''including'':
* "Effect on link"
* "Effect on a and area" and
* a link to a spec that documents the keyword ''as an HTML <code>rel</code> keyword''. (A spec that merely defines the file format of the link target but does not define the <code>rel</code> keyword for use in HTML is not the kind of spec that is being required here.)

Entries lacking any of the above required data will likely be removed.

Changes to this registry will not be reflected in validators in real time. But validators will typically get automatically updated with the changes within one week or so

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description
! Link to specification
! Synonyms
! Status

|-
| [[rel-apple-touch-icon|apple-touch-icon]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-icon-precomposed|apple-touch-icon-precomposed]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-startup-image|apple-touch-startup-image]]
| External Resource
| Not allowed
| Specify a splashscreen for Web apps on iOS Safari
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| maybe redundant with rel=icon with the sizes attribute?
| proposed

|-
| [[rel-archived|archived]]
| External Resource
| Hyperlink Annotation
| The target resource is archived and kept largely or solely for historical purposes.
| [http://www.sitemorse.com/rel-archived.html rel="archived" description]
|
| proposed

|-
| [[rel-attachment|attachment]]
| Hyperlink
| Hyperlink
| The resource linked to is "attached" to this document, similar to email attachments. Used in WordPress.
| No formal specification
|
| proposed

|-
| [[WPVL_PRETTYPHOTO_REL]]
| Hyperlink
| Hyperlink
| Open lightbox with video
| No formal specification
|
| proposed

|-
| [[rel-authorization_endpoint|authorization_endpoint]]
| External Resource
| Not allowed
| Specify a hosted authorization server
| [http://indiewebcamp.com/distributed-indieauth distributed IndieAuth documentation]
|
| proposed

|-
| [[rel-canonical|canonical]]
| Hyperlink
| Hyperlink
| Specifies the canonical URL for the current document in order to help avoid duplicate content.
| [http://en.wikipedia.org/wiki/Canonical_meta_tag Canonical meta tag] [http://www.Google.com/support/webmasters/bin/answer.py?answer=139066#2 Canonicalization at Google Webmaster Central] [http://www.Bing.com/community/site_blogs/b/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft Webmaster Center] [http://www.YSearchBlog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo! Search Blog]
|
| proposed

|-
| [[rel-category|category]]
| Hyperlink
| Hyperlink
| Refers to a category assigned to the current document or post. Implemented by WordPress for indicating a relation between a blog post and a category.
| [[rel-category]]
|
| proposed

|-
| [[rel-clearbox|clearbox]]
| Not allowed
| Img Pop-Up
| Images (or any other content, depending on href link) with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked (with installed "Clearbox v3"). When adding [gallery] to rel="clearbox" all images get a clickable button for next/prev; insert into <code><a rel="clearbox[gallery=Name of the gallery comes here]"> href="http:example.com/img.jpg"><img src="http:example.com/img.jpg"></a></code>
| [http://www.kreaturamedia.com/clearbox/ Clearbox 3]
|
| proposed

|-
| [[rel-component|component]]
| External Resource
| Not allowed
| Specify an HTML document that is treated as a component of this document.
| [https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Web Components]
|
| proposed

|-
| [[rel-chrome-webstore-item|chrome-webstore-item]]
| External Resource
| Not allowed
| Link tag to declare for app and extensions inline installations hosted in the Chrome Web Store.
| [https://developers.google.com/chrome/web-store/docs/inline_installation Using Inline Installation]
|
| proposed

|-
| [[rel-dcterms.(property)#conformsTo|DCTERMS.conformsTo]]
| External Resource
| Not allowed
| An established standard to which the described resource conforms. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.conformsTo" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#contributor|DCTERMS.contributor]]
| External Resource
| Not allowed
| An entity responsible for making contributions to the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.contributor" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#creator|DCTERMS.creator]]
| External Resource
| Not allowed
| An entity primarily responsible for making the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.creator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#description|DCTERMS.description]]
| External Resource
| Not allowed
| An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.description" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#hasFormat|DCTERMS.hasFormat]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the pre-existing described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasPart|DCTERMS.hasPart]]
| External Resource
| Not allowed
| A related resource that is included either physically or logically in the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasVersion|DCTERMS.hasVersion]]
| External Resource
| Not allowed
| A related resource that is a version, edition, or adaptation of the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isFormatOf|DCTERMS.isFormatOf]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isPartOf|DCTERMS.isPartOf]]
| External Resource
| Not allowed
| A related resource in which the described resource is physically or logically included. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReferencedBy|DCTERMS.isReferencedBy]]
| External Resource
| Not allowed
| A related resource that references, cites, or otherwise points to the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReplacedBy|DCTERMS.isReplacedBy]]
| External Resource
| Not allowed
| A related resource that supplants, displaces, or supersedes the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isRequiredBy|DCTERMS.isRequiredBy]]
| External Resource
| Not allowed
| A related resource that requires the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isVersionOf|DCTERMS.isVersionOf]]
| External Resource
| Not allowed
| A related resource of which the described resource is a version, edition, or adaptation. <br />Changes in version imply substantive changes in content rather than differences in format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#license|DCTERMS.license]]
| External Resource
| Not allowed
| A legal document giving official permission to do something with the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.license" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#mediator|DCTERMS.mediator]]
| External Resource
| Not allowed
| An entity that mediates access to the resource and for whom the resource is intended or useful. In an educational context, a mediator might be a parent, teacher, teaching assistant, or care-giver. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.mediator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#publisher|DCTERMS.publisher]]
| External Resource
| Not allowed
| An entity responsible for making the resource available. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.publisher" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#references|DCTERMS.references]]
| External Resource
| Not allowed
| A related resource that is referenced, cited, or otherwise pointed to by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#relation|DCTERMS.relation]]
| External Resource
| Not allowed
| A related resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#replaces|DCTERMS.replaces]]
| External Resource
| Not allowed
| A related resource that is supplanted, displaced, or superseded by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#requires|DCTERMS.requires]]
| External Resource
| Not allowed
| A related resource that is required by the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#rightsHolder|DCTERMS.rightsHolder]]
| External Resource
| Not allowed
| A person or organization owning or managing rights over the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.rightsHolder" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#source|DCTERMS.source]]
| External Resource
| Not allowed
| A related resource from which the described resource is derived. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#subject|DCTERMS.subject]]
| External Resource
| Not allowed
| The topic of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-disclosure|disclosure]]
| Not allowed
| External Resource
| The 'disclosure' Link Relation Type designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation type is specified.
| [http://tools.ietf.org/html/draft-yevstifeyev-disclosure-relation The 'disclosure' Link Relation Type]
|
| proposed

|-
| [[rel-discussion|discussion]]
| Hyperlink
| Hyperlink
| Refers to discussion of the current document or post.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-dns-prefetch|dns-prefetch]]
| External Resource
| Not allowed
| Tells the browser to perform dns lookup for host names ahead of use.
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla documentation] [http://dev.chromium.org/developers/design-documents/dns-prefetching Google documentation]
|
| proposed

|-
| [[rel-edit|edit]]
| Hyperlink
| Not allowed
| Tells the browser where the current page can be edited
| [http://universaleditbutton.org/Registered_MIME_type#Alternate_Linking_Scheme Universal Edit Button Alternate Linking Scheme]. Implemented in at least [http://mediawiki.org MediaWiki].
|
| proposed

|-
| [[rel-edituri|EditURI]]
| External Resource
| Not allowed
| A blogging auto discovery value, commonly used by WordPress
| [http://bitworking.org/projects/atom/draft-gregorio-09.html#Edit AtomAPI]
|
| proposed

|-
| [[rel-enclosure|enclosure]]
| External Resource
| External Resource
| Indicates that the referred resource is intended to be downloaded and cached.
| [[rel-enclosure]]
|
| proposed

|-
| [[rel-entry-content|entry-content]]
| Not allowed
| External Resource
| Indicates that the referenced document is an alternative display source for an Internet Explorer Web Slice.
| [http://msdn.microsoft.com/en-us/library/cc304073(VS.85).aspx#_alternative Web Slice format specification 0.9]
|
| proposed

|-
| [[rel-external|external]]
| Not allowed
| Hyperlink
| Indicates that the referenced document is not part of the same site as the current document.
| [[rel-external]]
|
| proposed

|-
| [[rel-home|home]]
| Hyperlink
| Hyperlink
| Refers to the top level document for the current document. It can be combined with 'alternate' to indicate a feed for the site of the current page.
| [[rel-home]]
|
| proposed

|-
| [[rel-hub|hub]]
| Hyperlink
| Hyperlink
| Refers to a hub that enables registration for notification of updates to the current page.
| [http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#discovery PubSubHubbub Spec]
|
| proposed

|-
| [[rel-in-reply-to|in-reply-to]]
| Hyperlink
| Hyperlink
| Refers to an original post that the current page is a comment on or reply to.
| [[rel-in-reply-to]]
|
| proposed

|-
| [[rel-index|index]]
| Hyperlink
| Hyperlink
| Refers to a document providing a list of topics with pointers that pertain to the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
|
| proposed

|-
| [[rel-indieauth|indieauth]]
| External Resource
| Not allowed
| the IndieAuth server for the relying party to contact for IndieAuth authentication
| [http://spec.indieauth.com/ IndieAuth specification]
|
| proposed

|-
| [[rel-issues|issues]]
| Hyperlink
| Hyperlink
| Refers to issues regarding the current document or specification.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-jslicense|jslicense]]
| Hyperlink
| Hyperlink
| Refers to a document with JavaScript source code and license information (also called a [http://www.gnu.org/licenses/javascript-labels.html JavaScript License Web Labels] page). We might want choose a keyword for this that is more general -- there are many situations besides JavaScript in which it is desirable or required by license agreements (e.g., GNU GPL) to make an offer of both the source code and a copy of a license when distributing object code versions of a given work.
| [[rel-jslicense]]
|
| proposed

|-
| [[rel-lightbox|lightbox]]
| Not allowed
| Img Pop-Up
| Images with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked (e.g. with installed "Lightbox 2"-Plugin). When adding [group] to rel="lightbox" all images get a clickable button for next/prev; insert into <code><a rel="lightbox[group]"><img src="http:example.com/img.jpg"></a></code>
| [http://lokeshdhakar.com/projects/lightbox2/ Lightbox 2] (needs actual specification to be kept in this list, this link is just documentation of one implementation)
|
| proposed

|-
| [[rel-manifest|manifest]]
| External Resource
| Not allowed
| Imports or links to a manifest
| [http://w3c.github.io/manifest/#linking W3C Manifest for web application]
|
| proposed

|-
| [[rel-mask-icon|mask-icon]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Pinned Tabs” on Safari 9.
| [https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html#//apple_ref/doc/uid/TP40014305-CH9-SW20 What is new in Safari 9.0]
| probably redundant with rel=icon
|
| proposed

|-
| [[rel-meta|meta]]
| External Resource
| Not allowed
| External metadata about the HTML document
| [http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-rdf-in-HTML W3C's RDF/XML Syntax Specification]
|
| proposed

|-
| [[rel-indieauth|micropub]]
| External Resource
| Not allowed
| the micropub endpoint for creating new posts
| [http://indiewebcamp.com/micropub Micropub scecification]
|
| proposed

|-
| [[rel-openid.delegate|openid.delegate]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 1.1 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid.server|openid.server]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 1.1 authentication
| [http://openid.net/specs/openid-authentication-1_1.html#anchor4 OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid2.local_id|openid2.local_id]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 2.0 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-openid2.provider|openid2.provider]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 2.0 authentication
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-p3pv1|p3pv1]]
| External Resource
| Not allowed
| References a machine-readable privacy policy description in the P3P format
| [http://www.w3.org/TR/P3P/#syntax_link P3P spec]
|
| proposed

|-
| [[rel-pgpkey|pgpkey]]
| External Resource
| Not allowed
| Associates a PGP key with a Web page so that the Web page URL can be used as the commenter's URL in PGP-signed blog comments and the blogging system receiving the comment can fetch the key and verify the signature as belonging to the owner of the URL.
| [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html PGP-Signed Comments]
|
| proposed

|-
| [[rel-pingback|pingback]]
| External Resource
| Not allowed
| gives the address of the pingback server that handles pingbacks to the current document
| [http://www.hixie.ch/specs/pingback/pingback Pingback]
|
| proposed

|-
| [[rel-preconnect|preconnect]]
| External Resource
| Not allowed
| Indicates an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high costs of connection establishment latency.
| [http://www.w3.org/TR/resource-hints/ Resource Hints Working Draft]
|
| proposed

|-
| [[rel-prerender|prerender]]
| External Resource
| External Resource
| Prerenders the Web page targeted by the link including running it scripts.
| [[rel-prerender]]
|
| proposed

|-
| [[rel-prettyPhoto|prettyPhoto]]
| Not Allowed
| Img Pop-Up
| Images with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked
| [http://www.no-margin-for-errors.com/projects/prettyphoto-jquery-lightbox-clone/documentation/ PrettyPhoto]
|
| proposed

|-
| [[rel-profile|profile]]
| External Resource
| Contextual External Resource
| indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof. See also [[xmdp-brainstorming]].
| [http://microformats.org/wiki/rel-profile rel-profile]
|
| proposed

|-
| [[rel-publisher|publisher]]
| External Resource
| External Resource
| Indicates that the referenced document is a metadata profile (e.g., a social-media/real-name profile such as a Google+ profile) for the publisher of the current page, or some portion of the current page.
| [https://support.google.com/plus/answer/1713826?hl=en Google help page]
|
| proposed

|-
| [[rel-rendition|rendition]]
| External Resource
| External Resource
| Indicates some example rendering, interpretation, or depiction of the source. User agents may choose to execute, display, or render the target in-place; or navigate to the target.
| [http://www.globalmentor.com/specs/html-rel-rendition/ HTML rel rendition]
|
| proposed

|-
| [[rel-reply-to|reply-to]]
| External Resource
| Hyperlink
| indicates any mailbox(es) (i.e. email addresses) to which responses are to be sent. ''Note: this is distinct from the 'in-reply-to' value which refers to the originating document, not to the address where comments should be sent.
| [http://tools.ietf.org/html/rfc2822 RFC2822] (originally [http://tools.ietf.org/html/rfc822#section-4.4.3 RFC822])
|
| ratified

|-
| [[rel-service|service]]
| External Resource
| Not allowed
| Atom Publishing Protocol editing service autodiscovery.
| [http://wiki.whatwg.org/wiki/ServiceRelExtension Documentation on the WHATWG wiki]
|
| proposed

|-
| [[rel-shortlink|shortlink]]
| External Resource
| Not allowed
| Specifies the preferred shortened URL for the page.
| [http://code.google.com/p/shortlink/wiki/Specification shortlink spec]
|
| proposed

|-
| [[rel-sidebar|sidebar]]
| Hyperlink
| Hyperlink
| Indicates that the referenced document is intended to be shown in a secondary browsing context.
| [[rel-sidebar]]
|
| proposed

|-
| [[rel-sitemap|sitemap]]
| External Resource
| Not allowed
| Provides a link to an XML document describing the layout of the site.
| [[rel-sitemap]]
|
| proposed

|-
| [[rel-subresource|subresource]]
| External Resource
| Not allowed
| An external resource intended for use within the current page.
| [http://www.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource Chromium documentation]
|
| proposed

|-
| [[rel-syndication|syndication]]
| Hyperlink
| Hyperlink
| Refers to a page which is a syndicated copy of the current page.
| [[rel-syndication]]
|
| proposed

|-
| [[rel-timesheet|timesheet]]
| External Resource
| Not allowed
| Applies a timesheet to the document.
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet non-normative section in the Timesheet spec]
|
| proposed

|-
| [[rel-token_endpoint|token_endpoint]]
| External Resource
| Not allowed
| Specify an HTTP endpoint that micropub clients can use to obtain an access token given an authorization code
| [http://indiewebcamp.com/token-endpoint token endpoint documentation]
|
| proposed

|-
| [[rel-webmention|webmention]]
| External Resource
| Hyperlink
| gives the address of the webmention endpoint that handles webmentions to the current document
| [https://indiewebcamp.com/Webmention WebMention specification]
|
| proposed

|-
| [[rel-widget|widget]]
| External Resource
| External Resource
| Autodiscovery for W3C widgets
| [http://dev.w3.org/2006/waf/widgets/Overview.html#linking-to-a-widget-package-from-a-html- non-normative section in the Widget packaging spec]
|
| proposed

|-
| [[rel-wlwmanifest|wlwmanifest]]
| External Resource
| Not allowed
| Windows Live Writer manifest autodiscovery
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx documentation on MSDN]
|
| proposed

|-
| [[rel-image_src|image_src]]
| External Resource
| Not allowed
| Specify a Webpage Icon for use by Facebook, Yahoo, Digg, etc.
| Unknown, but see for instance [http://www.niallkennedy.com/blog/2009/03/enhanced-social-share.html this]
| probably redundant with rel=icon
| proposed

|-
| [[rel-cmis-acl|http://docs.oasis-open.org/ns/cmis/link/200908/acl]]
| External Resource
| External Resource
| Identifies the resource containing a CMIS ACL document for the link context
| [http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html#_Toc243905525 CMIS 1.0, Section 3.4.3.4]
|
| proposed

|-
| [[rel-stylesheet/less|stylesheet/less]]
| External Resource
| Not allowed
| Less CSS framework stylesheets.
| [http://lesscss.org/#-client-side-usage Less CSS usage]
|
| proposed

|-
| [[rel-yandex-tableau-widget|yandex-tableau-widget]]
| External Resource
| Not allowed
| Lets webmasters configure the appearance of their own site widgets in Yandex.Browser
| [https://api.yandex.com/tableau/ Yandex's Tableau API]
|
| proposed
|}

== brainstorming ==
Several rel values are being brainstormed as potential microformats and are thus listed here. If you find you have a use for such semantics in real world examples, <strong>consider trying out</strong> these values and provide feedback on the respective brainstorming page(s) with your results and experiences.

You may list new proposed rel values here, and even better if you can list and link to POSH uses in the wild.

{| border="1"
|+
! rel value !! summary !! brainstormed in and usage in the wild

|-
| [[rel-accessibility|accessibility]] || indicate[s] that the destination of that hyperlink contains accessibility information for the current page. || [http://www.brucelawson.co.uk/2009/rel-accessibility/ blog post] which itself uses the rel value in a <link> tag in the head of the document.

|-
| [[rel-author|author]] || indicate[s] that the destination of that hyperlink represents the author of the current page. Combines with [[rel-me|rel-me]] to chain authorship information. || Google has said it will index rel-Author in this [http://googlewebmastercentral.blogspot.com/2011/06/authorship-markup-and-web-search.html blog post], with further [http://www.google.com/support/webmasters/bin/answer.py?answer=1229920 discussion of the rel-me connection] See also [http://dev.w3.org/html5/spec/Overview.html#link-type-author the HTML5 spec]

|-
| [[rel-bibliography|bibliography]] || indicate[s] that the destination of that hyperlink is a bibliography for the current page. || [http://microformats.org/discuss/mail/microformats-discuss/2007-October/010863.html mailing list post, 2007-10-15]

|-
| [[rel-cite|cite]] || indicate[s] that the destination of that hyperlink is an authoritative source or a precedent to the current page. || [[distributed-conversation-brainstorming]]

|-
| [[rel-group|group]] || the referenced document represents a group to which the person represented by the current document belongs || [[group-brainstorming]]

|-
| <span id="longdesc">[[rel-longdesc|longdesc]]</span> || Alternative to the img longdesc attribute, for use on visible links || [http://www.google.com/search?q=rel%3D%22longdesc%22 Google search for rel=longdesc in the wild] shows many sources of proposals. Please edit this to list the earliest and perhaps most recent/comprehensive proposal. No known real world POSH usage in the wild yet.

|-
| [[rel-map|map]] || Link to a map. Possibly embedded within an adr, hCard, geo or hCalendar. Parsers {{may}} attempt to parse the URL if it is a link to a known map site (e.g. Geohash, Google Maps, Multimap) and extract co-ordinates and other useful data. || (to [[User:TobyInk|TobyInk]] by email)

|-
| [[rel-member|member]] || the referenced document represents a member of the group represented by the current document || [[group-brainstorming]]

|-
| [[rel-m_PageScroll2id|m_PageScroll2id]] || JS to scroll to a defined ID || [[group-brainstorming]]

|-
| [[rel-prefetch|prefetch]] || indicates the URL and content-type of a resource that is likely to be a required resource when the next action or navigation is triggered. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#prefetch resource hints draft]

|-
| [[rel-preload|preload]] || indicates the URL and content-type of a resource that should be fetched as early as possible by the user agent. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#preload resource hints draft]

|-
| [[rel-prerender|prerender]] || indicates the URL of the next navigation target. Initiating a prerender allows the user agent to deliver an instant navigation experience: the user agent downloads the top-level resource and its assets, and performs all of the processing steps required to show the page without actually showing it to the user.|| [https://igrigorik.github.io/resource-hints/#prerender resource hints draft]

|-
| [[rel-profile|profile]] || indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof || [[xmdp-brainstorming]]

|-
| [[rel-shortlink|shortlink]] || the referenced document represents the current document but with a shorter URL || [http://samj.net/2009/04/introducing-relshort-better-alternative.html blog post]
|-
| source || the referenced document represents the source code for the current document or project || [[source-brainstorming]] [http://adactio.com/journal/6667/ blog post]

|-
| vcalendar-parent || link from an event to a containing event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-child || link from an event to a contained event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-sibling || link from an event to a related event with the same container || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]

|-
| [[rel-status|status]] || the referenced document represents the status (or source of status updates) for the author of this document || [http://monkinetic.com/2009/11/24/status-autodiscovery-relstatus.html blog post]

|}

=== more brainstorming ===
See also:
* [[genealogy-brainstorming]] for some thoughts on possible additional values for family relationships (use existing [[XFN]] [[rel-parent|parent]], [[rel-child|child]], [[rel-sibling|sibling]], [[rel-spouse|spouse]], [[rel-kin|kin]] values first though)
* [[xpn-brainstorming]] for some thoughts on possible additional values for professional relationships (use existing [[XFN]] [[rel-co-worker|co-worker]], [[rel-colleague|colleague]] values first though)

== POSH usage ==
There are numerous rel values used as [[POSH]], both in the wild, whose origins are not necessarily known, nor are their meanings consistent. There are also numerous rel values from external proposals of varying degrees of merit. It is useful to document their existence and summarize their implied meanings/usage intent as research that may be used to perhaps take one or more of them thru the microformats [[process]] if there is both sufficient interest and sufficient in the wild usage.

Note: If a value is missing from this table, it may have either already been promoted by writing it up as a proposal, or demoted by being explicitly dropped. Please check the other tables first before adding to this table.

Note: this list is incomplete, please help complete it from the following sources:

External sources:
* [http://developer.mozilla.org/about/meta Meta Information in DevMo Docs] (DevMo)
* [http://wiki.mozilla.org/Microsummaries Microsummary]
* [http://lachy.id.au/dev/markup/specs/wclr/ Web Communication Link Relationships] (WCLR)
* [http://www.w3.org/MarkUp/Relationships.html W3C Link Relationship values draft] (LRdraft) - from a draft of the HTML spec circa 1991.
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes HTML5 draft] '''Liable to change'''
* [http://wiki.foaf-project.org/Autodiscovery FOAF Project Wiki: Autodiscovery] (FOAF)
* [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]
* [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google Blog]

{| border="1"
|+
! rel value !! summary !! origin !! proposal(s)

|-
| [[rel-archive|archive]] || index of archived entries || unknown, perhaps Wordpress open source blogging software || WCLR

|-
| [[rel-archives|archives]] || Provides a link to a collection of records, documents, or other materials of historical interest. || || HTML5

|-
|[[rel-author|author]]||see brainstorming above for suggested use by google||unknown || DevMo / HTML5

|-
| [[rel-canonical|canonical]] || To help search engines disambiguate the same page with multiple representations || Google || [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google]/[http://www.bing.com/community/blogs/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft]/[http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo!], [http://blog.ask.com/2009/02/ask-is-going-canonical.html Ask Jeeves]

|-
| [[rel-comment|comment]] || … || … || WCLR

|-
| [[rel-contribution|contribution]] || … || … || WCLR

|-
| [[rel-edituri|EditURI]]
| Location of the xml-rpc gateway for a Wordpress install that allows external programs to add, edit and delete posts. Used by "[http://codex.wordpress.org/Weblog_Client WordPress blog client]" software for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. || Description stubbed in [[rel-edituri]].

|-
| [[rel-endorsed|endorsed]] || … || … || WCLR

|-
| [[rel-fan|fan]] || xxxx. || … || [[hcard-user-profile-authoring]]

|-
| [[rel-feed|feed]] || Gives the address of a syndication feed for the current document. || … || WCLR/ HTML5

|-
| [[rel-footnote|footnote]] || Location of the footnote on a link to a footnote. || Markdown preprocessors such as [http://maruku.rubyforge.org/ Maruku] || HTML5

|-
| [[rel-icon|icon]] || Imports an icon to represent the current document. (Allowed in <code>link</code> only) || [http://dev.w3.org/html5/spec-LC/links.html#rel-icon HTML5] || WCLR/HTML5

|-
| [[rel-kinetic-stylesheet|kinetic-stylesheet]] || Imports a [http://kssproject.org/ KSS] 'kinetic stylesheet' to bind dynamic behavior to elements || Used in the [http://plone.org Plone] Content Management System || …

|-
| [[rel-lightbox|lightbox]] || Hook - Indicates that following the link will trigger a "lightbox" script (Allowed in <code>link</code> only) || ([http://www.google.co.uk/search?q=rel%3D%22lightbox%22 Google search for rel=lightbox in the wild]) || …

|-
| [[rel-lightbox|lightbox[group_name]]] || Used by lightbox scripts to group different sets of images together. Images from one group will not appear in another group's lightbox. See also "lightbox". || [http://lokeshdhakar.com/projects/lightbox2/#how Lightbox 2] || …

|-
| [[rel-prettyPhoto|prettyPhoto]] || See also "lightbox" || ([http://www.google.fr/search?q=rel%3D%22prettyphoto%22 Google search for rel="prettyphoto" in the wild]) || …

|-
| [[rel-clearbox|clearbox]] || See also "lightbox" || ([http://www.google.fr/search?q=rel%3D%22clearbox%22 Google search for rel="clearbox" in the wild]) || …

|-
| [[rel-made|made]] || … || … || LRdraft

|-
| [[rel-meta|meta]] || … || [http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#transport 1999 W3C RDF syntax REC] || FOAF

|-
| [[rel-microsummary|microsummary]]|| … || … ||[http://wiki.mozilla.org/Microsummaries Microsummary], be aware of: [[page-summary-formats#Issues_2|microsummary issues]]

|-
| [[rel-noreferrer|noreferrer]] || indicates that no referrer information is to be leaked when following the link. || [http://dev.w3.org/html5/spec-LC/links.html#rel-noreferrer HTML5] || HTML5

|-
| [[rel-openid-delegate|openid.delegate]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-openid-server|openid.server]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-permalink|permalink]] || … || … || WCLR

|-
| [[rel-pgpkey|pgpkey]] || (see also rel-publickey) || … || [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html], [http://golem.ph.utexas.edu/~distler/blog/archives/000325.html]

|-
| [[rel-pingback|pingback]] || Gives the address of the pingback server that handles pingbacks to the current document. (Allowed in <code>link</code> only) || … || WCLR/ HTML5

|-
| [[rel-popover|popover]] || Used by a JS widget to display a large, descriptive tooltip. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#popovers Popover.js] || …

|-
| [[rel-prefetch|prefetch]] || Specifies that the target resource should be pre-emptively cached. (Allowed in <code>link</code> only) || … || HTML5

|-
| [[rel-privacy|privacy]] || Specifies that the target resource is the privacy policy. || … || …

|-
| [[rel-publickey|publickey]] || (see also rel-pgpkey) || … || [http://rasterweb.net/raster/2002/12/12/20021212072812/]

|-
| [[rel-referral|referral]] || … || … || WCLR

|-
| [[rel-related|related]] || … || … || WCLR

|-
| [[rel-replies|replies]] || indicates a continued thread || unknown || [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]

|-
| [[rel-respond-proxy|respond-proxy]] || Working with respond.js - proxy on external server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-respond-redirect|respond-redirect]] || Working with respond.js - redirect location on local server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-resource|resource]] || … || … || WCLR

|-
| [[rel-search|search]] || … || unknown || unknown

|-
| [[rel-sitemap|sitemap]] || Links to a site map document. || … || http://www.sitemaps.org/

|-
| [[rel-sponsor|sponsor]] || … || … || WCLR

|-
| [[rel-tooltip|tooltip]] || Used by a JS widget to display a tooltip similar (though more customizable) to what is shown by browsers if the 'title' attribute is present. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#tooltips Tooltip.js] (and likely other JS tools) || …

|-
| [[rel-trackback|trackback]] || … || unknown, perhaps open source Movable Type blogging software || WCLR

|-
| [[rel-unendorsed|unendorsed]] || (probably redundant to [[rel-nofollow|nofollow]]) || … || WCLR

|-
| [[rel-user|user]] || … || … || WCLR
|-
| [[rel-wlwmanifest|wlwmanifest]] || Used by "[http://explore.live.com/windows-live-writer Windows Live Writer]," a Microsoft [http://codex.wordpress.org/Weblog_Client blog client] for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. Similar values are probably used by other blog content management systems as well. || …

|}

=== WCLR ===

The WCLR proposal is described by its author (in e-mail, 2007-09-25) as:

<blockquote>
<p>…now effectively obsolete, since HTML5 and Microformats cover all the worthwhile relationships in that already.</p>

These are [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes covered by HTML5 already]:

* permalink -> bookmark
* archive -> archives
* feed
* pingback
* unendorsed -> nofollow

The rest now seem unnecessary.
</blockquote>

Nonetheless, there may be some mileage in using them in microformats, at least until HTML5 is widely available.

== Dublin Core ==
In the past, Dublin Core values have been added to this page in the table about HTML5 features, but no examples, nor an actual specification explicitly stating how the value(s) should be used in HTML could be found. The linked specifications below have been updated so we should start considering Dublin Core values accordingly.

{| border="1"
|+
! rel value !! summary !! source
|-
| schema.DC || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, with regard to the fifteen terms of the Dublin Core Metadata Element Set already published || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]

|-
| schema.DCTERMS || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, reflecting the changes described more fully in the 2012 document "Maintenance changes to DCMI Metadata Terms" [http://dublincore.org/usage/decisions/2012/dcterms-changes/] || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]
|-
|}

'''Issues need updating given new information from linked resources.'''

Notes:
* Dublin Core. This search may help: [http://www.google.co.uk/search?as_q=rel%3Dschema.*&hl=en&num=10&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=http%3A%2F%2Fdublincore.org&as_rights=&safe=images].
** '''examples from that search only use invisible <code><link href></code> element'''. At first glance it appears the results from the search show only uses with the invisible <code><link href></code> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <code><a href></code> are strongly preferred.
*** [http://www.ietf.org/rfc/rfc2731.txt RFC2731] defines <code>rel="schema.AC"</code> and <code>rel="schema.RC"</code> with the pattern <code>rel="schema.PREFIX"</code> as a syntax for defining namespaces for use in meta[@name], *[@rel], *[@rev] and (as per eRDF) *[@class] attributes. A link to a Dublin Core metadata schema is generally not suitable for end users, so <code><link href></code> appears to be more appropriate than <code><a href></code> for those that use Dublin Core metadata schemas.
*** The scheme proposed above provides metadata namespace declarations. As described by DCMI specifications, such indications '''cannot''' be provided w/o a suitable namespace. In order to give complete pieces of information, the correct description set must be: <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> (for the namespace declaration, followed by) <code><meta name="DCTERMS.<nowiki>[element]</nowiki>" content="<nowiki>[element.value]</nowiki>"></code> for related elements.
**** Note: [http://purl.org/dc/terms/ schema.DCTERMS] is conventionally related to an upgraded elements list than [http://purl.org/dc/elements/1.1/ schema.DC] and should be preferred as rel values. Both are discussed here for subject completeness)
** '''proposal to use in content currently only theoretical'''. Thus unfortunately the use of Dublin Core in user visible content like <code><a href></code> appears to be strictly theoretical. See [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011445.html microformats-discuss/2008-January/011445.html] for a proposal to use Dublin Core in user visible content.
*** '''recent improvements'''. DCMI solves some trouble concerning metadata through the ''description set model''. Some of these informations cannot currently be provided in any standard ways other than DC, namely dates, validity and periodicity. Following this public bug report ([https://www.w3.org/Bugs/Public/show_bug.cgi?format=multiple&id=22520]), the correct namespace declaration for DC and DCTERMS metadata are now considered valid HTML code. We '''must''' encourage this practice both for internal usefulness and for shared practices.

* The Dublin Core document [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] is a specification for, and gives examples of, both <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> and <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/">. Note that Dublin Core encourages the use of DCTERMS elements over DC. A list of projects which use Dublin Core metadata is maintained [http://dublincore.org/projects/ here].
* [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] also includes examples of <link rel="DCTERMS.[element]" href="">, where [element] = subject, isReferencedBy, creator, and publisher. The <link> tag is used instead of the <meta> tag whenever the content is a URL. (Note that this use is different from, but related to, <link rel="schema.DCTERMS" href="">.) Potentially, ''any'' of the 55 DCTERMS elements could be used in this way, and this could include use in HTML 5.
** As said before, HTML5 validators now allow the use of <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> for namespace declarations.

* According to DCMI specification linked above, as well as [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] documentation, HTML5 @rel attribute proposed values table has been updated. It now includes a subset of DCMI ''/terms/'' namespace properties, more specifically those whose value can (or must) be logically expressed by a resource, so that the "href" attribute value becomes a non-literal value surrogate referring to the resource itself.
** Elements from ''/elements/1.1/'' namespace have not been included on purpose. According to [http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces "FAQ/DC and DCTERMS Namespaces"], the old namespace is maintained for legacy purposes only and it is not as suitable for non-literal values as the ones denoted by <code><link></code> elements.

== Use with HTTP Link Header ==
You can also use any of the rel values (that are allowed for link elements) with HTTP Link Headers,

Example: returning a Javascript file with a license (since JS itself has no way to indicate a license)
<source lang=text>
Link: <http://creativecommons.org/publicdomain/zero/1.0/>; rel="license"
</source>

For multiple licenses (e.g. CC-SA and GPL), simply use multiple <code>Link:</code> headers.
<source lang=text>
Link: <http://creativecommons.org/licenses/by-sa/3.0/>; rel="license"
Link: <http://www.gnu.org/licenses/gpl.html>; rel="license"
</source>

Example: similarly, linking to a copyright statement for an image:
<source lang=text>
Link: <http://example.org/copyright.html>; rel="copyright"
</source>
or providing a brief inline copyright statement:
<source lang=text>
Link: <data:text/plain;charset=utf-8,Copyright 2013 ExampleCo, All Rights Reserved.>; rel="copyright"
</source>

== unspecified ==
Some rel values have been added to this page perhaps in one of the tables above, but no examples, nor an actual specification explicitly stating that the value(s) should be used in the HTML 'rel' attribute could be found. They are listed here in the hopes someone can discover more specific/precise URLs to examples or specifications about them (preferably both). Until such precise URLs to examples/specs are provided, the values can be treated as they are purely theoretical and thus of little interest.

A simple list here is sufficient.

== non HTML rel values ==
There are markup languages other than HTML that also have a rel attribute, often based upon the HTML rel attribute.
It is useful to document some of these other languages and their rel values for both reference purposes, and to provide background research for the possible development and re-use of these values in HTML, as [[poshformats]] or [[microformats]]

Sources:
* [[Atom]] [[RFC4287]] specification.
* See http://www.iana.org/assignments/link-relations.html for more.
* See [http://amundsen.com/media-types/maze/format/#link-relations Maze+XML]
* See [http://amundsen.com/media-types/collection/format/#link-relations Collection+JSON]
* See [http://www.opensearch.org/Specifications/OpenSearch/1.1#Url_rel_values OpenSearch]
* See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]
* See [http://rels.messages.io Workflow-Related Link Relations at Messages.io]

{| border="1"
|+
! rel value !! summary<br />(from the relevant specification where possible)) !! defining specification

|-
| self
| From http://www.ietf.org/rfc/rfc4287.txt : <blockquote>The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.</blockquote>
| [[Atom]] http://www.ietf.org/rfc/rfc4287.txt

|-
| http://gdata.youtube.com/schemas/2007#in-reply-to || See http://code.google.com/apis/youtube/2.0/developers_guide_protocol_comments.html || YouTube extension to Atom

|-
| collection || Refers to a resource which represents a collection of which the current resource is a member.

When used in the Maze+XML media type, the associated URI returns the available collection of mazes.
|| Maze+XML, Collection+JSON, OpenSearch

|-
| compensatingtx || Link to a resource representing information about a compensating transaction for each member transaction of a [http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf Long-Lived Compensating Transaction] || See [http://rels.messages.io/#compensatingtx Compensating Transaction Link Relation]

|-
| east || Refers to a resource to the "east" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the east in the active maze.

|| Maze+XML

|-
| events || Link to a collection resource representing a list of subscribe-able events. || See [http://rels.messages.io/#events Events Link Relation]

|-
| exit || Refers to a resource that represents the exit or end of the current client actvity or process.

When used in the Maze+XML media type, the associated URI points to the final exit resource of the active maze.

|| Maze+XML

|-
| north || Refers to a resource that is "north" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the north in the active maze.

|| Maze+XML

|-
| south || Refers to a resource that is "south" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the south in the active maze.

|| Maze+XML

|-
| [[rel-via|via]] || Identifies a resource that is the source of the information in the context. || Atom 1.0 Syndication format (RFC 4287)

|-
| west || Refers to a resource that is "west" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the west in the active maze.

|| Maze+XML

|-
| item || The target IRI points to a resource that is a member of a collection represented by the context IRI. || Collection+JSON

|-
| create-form || When included in a resource, the "create-form" link relation MAY identify a target resource that represents the form to append a new member to the link context. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| edit-form || When included in a resource, the "edit-form" link relation identifies a target resource that represents the form for editing associated resource. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| lightframe || Opens the target in a lightbox. On inclusion it provides a simple target the lightframe and loads the content in a lightbox effect || Lightbox

|-
| superbox[image] || jQuery Superbox! is a script which allows you display windows with the lightbox effect. || superbox

|-
| wp-video-lightbox || wp-video-lightbox! is a rel to anchor tag script display videos with the lightbox effect. || wp-video-lightbox

|-
| youtube || Opens the target youtube video in using the Swipebox Plugin || Swipebox

|-
| shadowbox || shadowbox is a jQuery script for images displaying with the "lightbox" effects. || shadowbox

|-
| permission || When included in a resource, the "permission" link relation MAY identify a target resource that represents the list of entities that can access or modify the resource in the link context. || See [http://cdoc.io/spec.html#permission-link-relation Collection Document Media Type Specification]

|-
| sub || When included in a resource representation of an event, the "sub" (subscription) link relation MAY identify a target resource that represents the ability to subscribe to the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#sub Subscription Link Relation]

|-
| unsub || When included in a resource representation of an event, the "unsub" (subscription cancellation) link relation MAY identify a target resource that represents the ability to un-subscribe from the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#unsub Subscription Cancellation Link Relation]

|-
| version-history
| When included on a versioned resource, this link points to a resource containing the version history for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| latest-version
| When included on a versioned resource, this link points to a resource containing the latest (e.g., current) version.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy
| When included on a versioned resource, this link points to a working copy for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy-of
| When included on a working copy, this link points to the versioned resource from which this working copy was obtained.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| predecessor-version
| When included on a versioned resource, this link points to a resource containing the predecessor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| successor-version
| When included on a versioned resource, this link points to a resource containing the successor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| ... || ... || ...

|}

== dropped ==
The following rel values were in earlier version(s) of specification(s) and it is presumed by their absence from the most recent version of the respective specification(s) that they have been deprecated or obsoleted.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

In particular:
* if a rel value was in a draft and is missing (without explanation) from the final spec, or
* if a rel value was in a previous version of and is missing (without explanation) from an update to the specification (even a draft update)

Then absent any other information or explanation, it is presumed that the group/editors working on that specification decided to explicitly drop it (either in development, or in the updated version) and thus it should be obsoleted (not re-registered).

If you wish to add them, please research <em>why</em> such values were omitted from latter specifications before doing so. If you do discover the reasoning, please add a short statement or link to thereof into the appropriate place in the following table.

If there is more data, e.g. a link to an email of discussion of the spec development that explains ''why'' the rel value was dropped, and it explicitly states, e.g. it was without prejudice, or merely post-poned, or perhaps expected to be spun-out into its spec (or some other explicit positive reason), then it makes to link/cite that explicit text as part of a proposal.

Sources:
* [http://www.w3.org/MarkUp/html3/ HTML3] (HTML3) / has been superceded by [http://www.w3.org/MarkUp/Wilbur/ HTML 3.2] - which itself has been superceded by [http://www.w3.org/TR/REC-html40 HTML 4.0] - which itself has been updated by [http://w3.org/TR/html401 HTML 4.01], commonly referred to as "HTML 4" in this wiki and other places.)
* [http://www.w3.org/TR/relations.html Proposed HTML 4.0 link types] (HTML4dropped) - obsoleted/superceded by the HTML 4.0 Recommendation. Any values that were in the "Proposed HTML 4.0 link types" document but didn't make it into the HTML 4.0 Recommendation were thus explicitly dropped and should be avoided.

{| border="1"
|+
! rel value !! summary !! defining specification !! why dropped

|-
|[[rel-banner|banner]]||Was used to reference another document to be used as banner for this document (i.e. a form of "include" statement).|| HTML3 ||unknown

|-
| [[rel-begin|begin]] || identifies the author-defined start of a sequence of documents of which the current document is a node.
|| HTML4dropped||unknown

|-
| [[rel-biblioentry|biblioentry]] || identifies a bibliographic entry || HTML4dropped||unknown

|-
| [[rel-bibliography|bibliography]] || identifies a bibliography || HTML4dropped||unknown

|-
| [[rel-child|child]] (obsolete/superceded) || the target document is a hierarchical child, or subdocument, of the current document|| HTML4dropped||unknown

|-
| [[rel-citation|citation]] || the target is a bibliographic citation || HTML4dropped||unknown

|-
| [[rel-collection|collection]] || the target document is an collection that contains the current document || HTML4dropped||unknown

|-
| [[rel-definition|definition]] || identifies a definition of a term || HTML4dropped||unknown

|-
| [[rel-disclaimer|disclaimer]] || identifies a hypertext link to a legal disclaimer || HTML4dropped||unknown

|-
| [[rel-editor|editor]] || identifies a hypertext link to an editor || HTML4dropped||unknown

|-
| [[rel-end|end]] || identifies the author-defined end of a sequence of documents of which the current document is a node. || HTML4dropped||unknown

|-
| [[rel-footnote|footnote]] || the anchor is a footnote marker and the target is a footnote || HTML4dropped||unknown

|-
| [[rel-navigate|navigate]] || the target document contains information such as a image map that will help users to gain a sense of how and where to found information || HTML4dropped||unknown

|-
| [[rel-origin|origin]] || synonym for <code>top</code> || HTML4dropped||unknown

|-
| [[rel-parent|parent]] (obsolete/superceded) || the target document is the hierarchical parent, or container, of the current document|| HTML4dropped||unknown

|-
| [[rel-pointer|pointer]] || the target is a pointer to the real target. This value can be used by a user agent to perform a pre-fetch of the specified target for evaluation until the real target is reached || HTML4dropped||unknown

|-
| [[rel-publisher|publisher]] || identifies a hypertext link to a publisher || HTML4dropped||unknown

|-
| [[rel-sibling|sibling]] (obsolete/superceded) || the target document is a child of a common parent, or a hierarchical peer of the current document|| HTML4dropped||unknown

|-
| [[rel-top|top]] || the target document is the logical top node of the tree (see also <code>begin</code>) || HTML4dropped||unknown

|-
| [[rel-trademark|trademark]] || identifies a hypertext link to a trademark notice || HTML4dropped||unknown

|-
| [[rel-translation|translation]] || the target is a translation to another language || HTML4dropped||unknown

|-
| [[rel-urc|urc]] || identifies a Universal Resource Citation || HTML4dropped||unknown

|-
|}

== dropped without prejudice ==
In one known instance (from HTML4 to HTML5), some rel values were in an earlier version of a specification (or a proposal) and were dropped from a latter (draft) version, and it was noted that these values were dropped with the intent that they could still be proposed in a registry and thus they explicitly were not deprecated or obsoleted. This section documents such values as separate from the [[#dropped|dropped]] section.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

Rel values that were dropped without prejudice from a specification will be considered similar to new values that have never been specified.

If you know of additional rel values that were dropped without prejudice from an update to a specification, please cite a URL and quote from the group developing the specification that officially states from that group that the dropping of the values was done without prejudice, or equivalent statement (such as explicit allowance of external registration, proposal, and/or development).

This table serves a historical purpose. If you wish to propose a value from this table, please copy it and leave it in place.

Sources:
* Several rel values were [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7475#c15 explicitly dropped from HTML5]. Per: [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Issue 118 Decision] ('''emphasis''' added): <blockquote><p>"The final proposal argues for the removal of some relation values, to wit, it suggests removal of '''index, up, first and last'''. It was pointed out in survey comments that these relations are already registered in the IANA link relation registry. Presumably, '''these relations could also be entered in whatever other registry or registries HTML5 adopts for this purpose'''.</p>...<p>"Next Steps</p>...<p>"Since the relations to be removed are already registered at the IANA link relation registry, no further action is needed to include them there. WG members are '''free to register or record these relations elsehwere''' [sic], as well."</p></blockquote>

{| border="1"
|+
! rel value
! summary
! defining specification
! why dropped

|-
| [[rel-first|first]]
| synonym for <code>begin</code>
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-index|index]]
| Refers to a document providing an index for the current document.
| was in [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-last|last]]
| synonym for <code>end</code>
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-up|up]]
|When the document forms part of a hierarchy, this link references the immediate parent of the current document.
| was in [http://www.w3.org/MarkUp/html3/dochead.html HTML3] - but [http://www.w3.org/TR/html401/types.html#type-links dropped in HTML4]
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
|}

See related [http://dev.w3.org/html5/spec/links.html#linkTypes HTML5: Link types] for existing HTML5 specified rel values.

== rejected ==
Some rel values have been proposed and rejected. They are listed here to make that explicit. Authors {{must not}} use rejected rel values.

Source: [[rejected-formats]].

{| border="1"
|+
! rel value !! origin / proposal !! why rejected
|-
| [[rel-logo|logo]]
| [http://relogo.org Relogo.org]
| [[rejected-formats#Logo]]
|-
|[[rel-pavatar|pavatar]] || [http://pavatar.com/ pavatar] || [[rejected-formats#Pavatar]]
|-
|}

== tools ==
See [[implementations]].

== addtional external research ==
Here are some additional historical references to the development or rel-values which may be useful when researching values, especially why specific values may have been proposed but abandoned.
* 1996-06-07 [http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt Hypertext links in HTML] (copies: [http://ftp.ics.uci.edu/pub/ietf/html/draft-ietf-html-relrev-00.txt ftp.ics.uci.edu])
* 1996-11-13 [http://www.w3.org/Architecture/NOTE-link Describing and Linking Web Resources]
* 1997-01-23 [http://lists.gnu.org/archive/html/lynx-dev/1997-01/msg00537.html LYNX-DEV Lynx and the LINK tag]
* 1997-01-24 [http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jan/0357.html Taxonomy list]
* 1997-03-28 [http://www.w3.org/TR/WD-htmllink-970328 W3C Working Draft: Hypertext Links and Meta Information in HTML]

=== previous attempts at documenting ===
There have been previous attempts at documenting known rel values, most of which fell out of date due to being dependent on a single author maintaining them. They're listed here purely for historical reasons, and are not sufficient to be references of their own (since they're just individual curations of other references)
* [http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html Link Type Definitions Glossary] by fantasai
* ...

== related ==
{{rel-related-pages}}
* [[elemental-microformats]]
* [[existing-rev-values]]
* [[existing-class-names]]

== copyright ==

{{cc-pd-license}}

jf2

2015-10-29T19:43:08Z

Kevin Marks: /* Name Candidates */ typo

{{stub}}

'''<dfn>jf2</dfn>''' is a working name for a simplified more minimal JSON representation of [[microformats2]].

== Basic Example ==
<source lang="javascript">
{
"type": "entry",
"author": {
"type": "card",
"name": "Tantek Çelik",
"url": "http:\/\/tantek.com\/",
"photo": "http:\/\/tantek.com\/photo.jpg"
},
"published": "2015-10-21T12:34-0700",
"category": ["simple", "example"],
"content": "Example of a simple note"
}
</source>

== Prior Work ==
* [[microformats2]] JSON

== Prior Simplifications ==
Output from:

=== [http://webmention.io webmention.io] ===
This service outputs a list of webmentions received for a post. It recognizes when a post is a reply, like, repost, invitation, RSVP, and mention. Example JSON output:

<source lang="javascript">
{
"source": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback",
"verified": true,
"verified_date": "2013-04-25T17:09:33-07:00",
"id": 900,
"data": {
"author": {
"name": "Tantek Çelik",
"url": "http://tantek.com/",
"photo": "http://tantek.com/logo.jpg"
},
"name": "Another milestone: @eschnou automatically shows #indieweb comments with h-entry sent via pingback http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html",
"content": "Another milestone: <a class=\"auto-link h-x-username\" href=\"https:\/\/twitter.com\/eschnou\">@eschnou<\/a> automatically shows #indieweb comments with h-entry sent via pingback <a class=\"auto-link\" href=\"http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html\">http:\/\/eschnou.com\/entry\/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html<\/a>",
"published": "2013-04-22T15:03:00-07:00",
"published_ts": 1366668180,
"url": "http://tantek.com/2013/112/t2/milestone-show-indieweb-comments-h-entry-pingback"
}
}
</source>

=== webmention.herokuapp.com ===
This site outputs in multiple formats, based on receiving webmentions, parsing them for microformats and consolidating into a single feed. Live examples for kevinmarks.com:
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html HTML mf2 markup]
<source lang=html4strict>
<div class="h-entry">
<a href="http://waterpigs.co.uk/" class="p-author h-card">
<img src="http://waterpigs.co.uk/photo.jpg" alt="">
Barnaby Walters
</a>
<div class="p-summary p-name">@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf</div>
<footer>
<time class="dt-published" datetime="2014-04-01T14:25:14.000Z" pubdate="">
<a class="u-url u-uid" href="http://waterpigs.co.uk/notes/4VMERE/">2 years ago</a>
</time>
mentioning <a href="http://kevinmarks.com/">http://kevinmarks.com/</a>
</footer>
</div>
</source>
*[http://www.unmung.com/mf2?url=https%3A%2F%2Fwebmention.herokuapp.com%2Fapi%2Fmentions%3Fsite%3Dkevinmarks.com%26format%3Dhtml&html=&pretty=on parsed JSON form of the HTML]
<source lang=javascript>
{
"type": ["h-entry"],
"properties": {
"uid": ["http://waterpigs.co.uk/notes/4VMERE/"],
"author": [
{"type": ["h-card"],
"properties": {
"url": ["http://waterpigs.co.uk/"],
"photo": ["http://waterpigs.co.uk/photo.jpg"],
"name": [""]
},
"value": "Barnaby Walters"
}],
"url": ["http://waterpigs.co.uk/notes/4VMERE/"],
"summary": ["@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"],
"published": ["2014-04-01T14:25:14Z"],
"name": [ "@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf"]
}
}
</source>
*[https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=json simplified JSON] (whitespace added)
<source lang=javascript>
{
"url":"http://waterpigs.co.uk/notes/4VMERE/",
"name":null,
"published":1396362314000,
"summary":"@kevinmarks awesome demos as always! Thanks for live posting! #indiewebcampsf",
"author": {
"name":"Barnaby Walters",
"photo":"http://waterpigs.co.uk/photo.jpg",
"url":"http://waterpigs.co.uk/"
},
"interactions": ["http://www.kevinmarks.com/indiewebsfdemowrapup.html"],
"targets":["http://kevinmarks.com/"],
"type":"reply",
"interactionTarget":false
},
</source>

=== [https://github.com/indieweb/php-comments php-comments] library ===
This library takes HTML and converts it to a simple PHP data structure. Example post:

<source lang="php">
$result = array(
'type' => 'reply',
'author' => array(
'name' => 'Aaron Parecki',
'photo' => 'http://aaronparecki.com/images/aaronpk.png',
'url' => 'http://aaronparecki.com/'
),
'published' => '2014-02-16T18:48:17-0800',
'name' => 'Example Note',
'text' => 'this text is displayed as the comment',
'url' => 'http://aaronparecki.com/post/1'
);
</source>

== Name Candidates ==
As 'jf2' is only a working name let's collect alternatives:

;JFDI
:Backronym: JSON For Data Interchange
;jf2
:Minimal JSON for mf2

== Links ==
* [https://github.com/w3c-social/Social-Syntax-Brainstorming/wiki/Minimal-Activity-Stream github.com/w3c-social/Social-Syntax-Brainstorming/wiki/Minimal-Activity-Stream] - Primary development
* [https://github.com/dissolve/socialstream github.com/dissolve/socialstream] - Sample php code to convert MF2 -> JS2
* [http://stream.thatmustbe.us/?url=ben.thatmustbe.me/feed stream.thatmustbe.us/?url=ben.thatmustbe.me/feed] - Service running the socialstream code

== See Also ==
* [[json]]
* [[microformats2]]
* [[microformats2-parsing]]

h-card-brainstorming

2015-10-27T16:38:53Z

Kevin Marks: /* Pronouns */

{{stub}}

<entry-title>h-card Brainstorming </entry-title>
This page is for brainstorming about various uses, details of, and additions to [[h-card]].

This page contains <em>proposals</em>. For the current state please see [[h-card]].

__TOC__
Brainstorm proposals that illustrate how to use the existing hCard spec will likely be incorporated into existing hCard documentation such as:
* [[h-card-authoring]]
* [[h-card-examples]]
* ... and potentially additional documentation.

== Explorations ==
Add new explorations here as === === triple level headings

=== Pronouns ===
Ashton McAllan marks up her pronouns as:
<source lang=html4strict>
<span class="p-x-pronoun-nominative">she</span> /
<span class="p-x-pronoun-oblique">her</span> /
<span class="p-x-pronoun-posessive">hers</span>
</source>
in her [[h-card]] on http://acegiak.net/

Each pronoun is listed individually with it's form allowing parsers and programs to identify them for different uses. Other languages may include different forms of pronoun. This solution is suggested after reading [https://en.wikipedia.org/wiki/Personal_pronoun the Wikipedia Personal Pronouns article]

==== Pronouns Prior Art ====
* MediaWiki preferences, e.g. https://www.w3.org/wiki/Special:Preferences (when logged in) has a radio button group from you can choose your nominative pronoun (or none).
<blockquote><pre>
How do you prefer to be described?
(*) (I prefer not to say)
( ) She edits wiki pages
( ) He edits wiki pages
</pre></blockquote>

== See Also ==
* [[h-card]]
* [[hcard-brainstorming]] - for additional proposals to bring forth to h-card

xoxo-sample-code

2015-10-26T03:45:25Z

Kevin Marks: add github link

= XOXO Sample Code =

A whole bunch of open source ([http://creativecommons.org/licenses/by/2.0/ CC-by-2.0], [http://www.apache.org/licenses/LICENSE-2.0 Apache 2.0]) sample code to read and write [[xoxo]] files in Python and Java (with Perl, PHP, ... to follow).

Also on [https://github.com/microformats/xoxo github]
== Python ==
See [[xoxo-sample-code-python]]

== Java ==
See [[xoxo-sample-code-java]]

== PHP ==
See [[xoxo-sample-code-php]]

== other implementations ==
* [http://boxtheweb.mihopa.net/code/apis/xoxo2array.php.txt xoxo2array.php]
* [http://boxtheweb.mihopa.net/code/apis/array2xoxo.php.txt array2xoxo.php]
* [http://boxtheweb.mihopa.net/code/apis/#outlineclasses Outline Classes]

jf2

2015-10-21T20:17:31Z

Kevin Marks: /* Prior Simplifications */ webmention example

jf2

2015-10-21T19:57:52Z

Kevin Marks: name bikeshedding seecion

existing-rel-values

2015-10-08T22:23:12Z

Kevin Marks: /* HTML5 link type extensions */ fix html5 link

<entry-title> existing rel values </entry-title>

This page contains tables of known HTML rel values from specifications, formats, proposals, brainstorms, and non-trivial [[POSH]] usage in the wild. In addition, dropped and rejected values are listed at the end for comprehensiveness.

<span id="usage">usage</span>: see [[rel-faq#How_is_rel_used|how is 'rel' used]]. Regarding <span id="rev">rev</span>, see: [[rel-faq#Should_rev_even_be_used|should 'rev' even be used]].

This page is also the official rel registry ([http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types][http://www.w3.org/TR/html5/links.html#other-link-types]). Add new and proposed rel values to the following section:
* [[existing-rel-values#HTML5_link_type_extensions|HTML5 link type extension]]

== formats ==
These rel values are defined formats from specifications (HTML 4, microformats) are thus are <strong>recommended for general use</strong>. Alphabetically ordered by value.

Note:
* <strong>Do not</strong> add proposed rel values for HTML5 here, add them to the [[#HTML5_link_type_extensions|HTML5 link type extensions]] table.
* <strong>Do not</strong> add rel values you find in the wild to this table of rel formats, instead add them to the table in the [[existing-rel-values#POSH_usage|POSH section]].
* <strong>Do not</strong> add non-HTML rel values you find to this table of rel formats, instead add them to the table in the [[existing-rel-values#non_HTML_rel_values|non HTML rel values section]].
* <strong>Do not</strong> add rel values from obsolete/superceded proposals or drafts, instead add them to the table in the "dropped" section.

Sources:
* W3C Recommendations:
** [http://www.w3.org/TR/html401/types.html#h-6.12 HTML 4.01 section 6.12 Link types] (HTML4 Link types)
** [http://www.w3.org/TR/grddl/ Gleaning Resource Descriptions from Dialects of Languages] (GRDDL)
* [[microformats]] specifications
** [[xfn]]
** [[rel-license]]
** [[rel-nofollow]]

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description <br />(from the relevant specification where possible)
! Link to defining specification

|-
| [[rel-acquaintance|acquaintance]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance
| [[XFN]]

|-
| [[rel-alternate|alternate]]
| external resource
| external relation
| Designates substitute versions for the document in which the link occurs. When used together with the <code>lang</code> attribute, it implies a translated version of the document. When used together with the <code>media</code> attribute, it implies a version designed for a different medium (or media).
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-appendix|appendix]]
| allowed
| allowed
| Refers to a document serving as an appendix in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-bookmark|bookmark]]
| not allowed
| allowed
| Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The <code>title</code> attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-chapter|chapter]]
| allowed
| allowed
| Refers to a document serving as a chapter in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-child|child]]
| not allowed
| external relation
| the referenced person is a child of the person represented by the current document
| [[XFN]]

|-
| [[rel-colleague|colleague]]
| not allowed
| external relation
| the referenced person is a colleague of the person represented by the current document
| [[XFN]]

|-
| [[rel-contact|contact]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a contact
| [[XFN]]

|-
| [[rel-contents|contents]]
| allowed
| allowed
| Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from "Table of Contents").
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-copyright|copyright]]
| allowed
| allowed
| Refers to a copyright statement for the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-co-resident|co-resident]]
| not allowed
| external relation
| the referenced person lives in the same residence as the person represented by the current document
| [[XFN]]

|-
| [[rel-co-worker|co-worker]]
| not allowed
| external relation
| the referenced person is a co-worker of the person represented by the current document
| [[XFN]]

|-
| [[rel-crush|crush]]
| not allowed
| external relation
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)
| [[XFN]]

|-
| [[rel-date|date]]
| not allowed
| external relation
| this person considers the referenced person to be a date (i.e. is dating the referenced person)
| [[XFN]]

|-
| [[rel-friend|friend]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a friend
| [[XFN]]

|-
| [[rel-glossary|glossary]]
| allowed
| allowed
| Refers to a document providing a list of terms and their definitions that pertain to the current document.||[http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-help|help]]
| allowed
| allowed
| Refers to a document offering help (more information, links to other sources information, etc.)
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-its-rules|its-rules]]
| allowed
| not allowed
| Refers to a document with external ITS rules.
| [http://www.w3.org/TR/its20/#selection-global-html5 Internationalization Tag Set (ITS) Version 2.0]

|-
| [[rel-kin|kin]]
| not allowed
| external relation
| the referenced person is part of the extended family of the person represented by the current document
| [[XFN]]

|-
| [[rel-license|license]]
| allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is a license for the current page.
| [[rel-license]]

|-
| [[rel-me|me]]
| external relation
| external relation
| the referenced document represents the same person as does the current document
| [[XFN]]

|-
| [[rel-met|met]]
| not allowed
| external relation
| this person has met the referenced person
| [[XFN]]

|-
| [[rel-muse|muse]]
| not allowed
| external relation
| the referenced person inspires the person represented by the current document
| [[XFN]]

|-
| [[rel-neighbor|neighbor]]
| not allowed
| external relation
| the referenced person lives nearby the person represented by the current document
| [[XFN]]

|-
| [[rel-next|next]]
| external relation
| external relation
| Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-nofollow|nofollow]]
| not allowed
| external relation
| indicates that the destination of that hyperlink {{should-not}} be afforded any additional weight or ranking by user agents which perform link analysis upon web pages (e.g. search engines).
| [[rel-nofollow]]

|-
| [[rel-parent|parent]]
| not allowed
| external relation
| the referenced person is a parent of the person represented by the current document
| [[XFN]]

|-
| [[rel-prev|prev]]
| external relation
| external relation
| Refers to the previous document in an ordered series of documents. Some user agents also support the synonym "Previous".
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-previous|previous]]
| external relation
| external relation
| Synonym of <code>prev</code>
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-section|section]]
| allowed
| allowed
| Refers to a document serving as a section in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sibling|sibling]]
| not allowed
| external relation
| the referenced person is a sibling of the person represented by the current document
| [[XFN]]

|-
| [[rel-spouse|spouse]]
| not allowed
| external relation
| the referenced person is a spouse of the person represented by the current document
| [[XFN]]

|-
| [[rel-start|start]]
| allowed
| allowed
| Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-stylesheet|stylesheet]]
| external resource
| not allowed
| a style sheet for the current document<br /> used with the invisible <link href> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <a href> are strongly preferred. Unfortunately the use of stylesheet in user visible content like <a href> appears to be strictly theoretical.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-subsection|subsection]]
| allowed
| allowed
| Refers to a document serving as a subsection in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sweetheart|sweetheart]]
| not allowed
| external relation
| this person considers the referenced person to be their sweetheart
| [[XFN]]

|-
| [[rel-tag|tag]]
| not allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is an author-designated "tag" (or keyword/subject) for the current page.
| [[rel-tag]]

|-
| [[rel-toc|toc]]
| allowed
| allowed
| Synonym of <code>contents</code> (from "Table Of Contents")
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-transformation|transformation]]
| allowed
| allowed
| Relates a source document to a transformation, usually represented in XSLT, that relates the source document syntax to the RDF graph syntax. Used in [[grddl|GRDDL]]
| [http://www.w3.org/TR/grddl/#transformation GRDDL]

|}

=== notes ===
*<code>rel="alternate"</code> can take further meaning from additional attributes, such as
** <code>rel="alternate" lang="fr"</code> (French language version of this page)
** <code>rel="alternate" media="print"</code> (printable version of this page)
** <code>rel="alternate" media="handheld"</code> (version of the page intended or better for handheld/portable devices like PDAs, cell phones, etc.)

*Synonyms such as "previous", "toc" are not as widely supported as the main term.

== proposals ==
A few rel values have been developed as drafts as a result of going through most of the microformats [[process]], and are thus listed here for your serious consideration. You <strong>may use these values</strong>, and if you find any problems with them please point them out on the respective "issues" page for the rel value.

{| border="1"
|+
! rel value !! summary !! proposed in !! external spec (if any)
|-
| [[rel-pronunciation|pronunciation]] || …indicates that the destination of the 'link' element is a document providing a pronunciation lexicon for speech-synthesis purposes. || [[rel-pronunciation]]
|-
| [[rel-directory|directory]] || …indicates that the destination of the hyperlink is a directory listing containing an entry for the current page. || [[rel-directory]]
|-
| [[rel-enclosure|enclosure]] || …indicates that the destination of that hyperlink is intended to be downloaded and cached. || [[rel-enclosure]] || [http://www.apps.ietf.org/rfc/rfc4287.html RFC4287]
|-
| [[rel-home|home]] || …indicates that the <nowiki>[referenced document]</nowiki> is the homepage of the site in which the current page appears. || [[rel-home]]
|-
| [[rel-payment|payment]] || …indicates that the destination of the hyperlink provides a way to show or give support (e.g. financial) for the current page|| [[rel-payment]]
|}

== HTML5 link type extensions ==

The following values are registered as link type extensions per the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types requirements in the WHATWG HTML spec] and the [http://www.w3.org/TR/html5/links.html#other-link-types requirements in the W3C HTML5 spec].

Before you register a new value:
* '''Please check the [[#formats|Formats table]] and DO NOT re-register''' rel values that are already there. Please note that the W3C HTML WG has made a [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Decision] to drop <code>index</code>, <code>up</code>, <code>first</code> and <code>last</code> from the HTML5 spec itself.
* '''Please check the [[#dropped|Dropped table]] and DO NOT register''' values that are already there. If you believe a rel value was dropped from another specification without prejudice, please provide link/cite to explicit text/decision stating as such, e.g. the value was merely postponed, or perhaps expected to be spun-out into its own spec from the group developing that specification.

Note that entries in the [[#formats|Formats table]] and entries that are already in HTML5 as built-in keywords are also considered extensions with the "Ratified" status.

Please make sure that registrations added here have all the required data filled in ''including'':
* "Effect on link"
* "Effect on a and area" and
* a link to a spec that documents the keyword ''as an HTML <code>rel</code> keyword''. (A spec that merely defines the file format of the link target but does not define the <code>rel</code> keyword for use in HTML is not the kind of spec that is being required here.)

Entries lacking any of the above required data will likely be removed.

Changes to this registry will not be reflected in validators in real time. But validators will typically get automatically updated with the changes within one week or so

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description
! Link to specification
! Synonyms
! Status

|-
| [[rel-apple-touch-icon|apple-touch-icon]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-icon-precomposed|apple-touch-icon-precomposed]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-startup-image|apple-touch-startup-image]]
| External Resource
| Not allowed
| Specify a splashscreen for Web apps on iOS Safari
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| maybe redundant with rel=icon with the sizes attribute?
| proposed

|-
| [[rel-archived|archived]]
| External Resource
| Hyperlink Annotation
| The target resource is archived and kept largely or solely for historical purposes.
| [http://www.sitemorse.com/rel-archived.html rel="archived" description]
|
| proposed

|-
| [[rel-attachment|attachment]]
| Hyperlink
| Hyperlink
| The resource linked to is "attached" to this document, similar to email attachments. Used in WordPress.
| No formal specification
|
| proposed

|-
| [[WPVL_PRETTYPHOTO_REL]]
| Hyperlink
| Hyperlink
| Open lightbox with video
| No formal specification
|
| proposed

|-
| [[rel-authorization_endpoint|authorization_endpoint]]
| External Resource
| Not allowed
| Specify a hosted authorization server
| [http://indiewebcamp.com/distributed-indieauth distributed IndieAuth documentation]
|
| proposed

|-
| [[rel-canonical|canonical]]
| External Resource
| Not allowed
| Specifies the canonical URL for the current document in order to help avoid duplicate content.
| [http://en.wikipedia.org/wiki/Canonical_meta_tag Canonical meta tag] [http://www.Google.com/support/webmasters/bin/answer.py?answer=139066#2 Canonicalization at Google Webmaster Central] [http://www.Bing.com/community/site_blogs/b/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft Webmaster Center] [http://www.YSearchBlog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo! Search Blog]
|
| proposed

|-
| [[rel-category|category]]
| Hyperlink
| Hyperlink
| Refers to a category assigned to the current document or post. Implemented by WordPress for indicating a relation between a blog post and a category.
| [[rel-category]]
|
| proposed

|-
| [[rel-clearbox|clearbox]]
| Not allowed
| Img Pop-Up
| Images (or any other content, depending on href link) with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked (with installed "Clearbox v3"). When adding [gallery] to rel="clearbox" all images get a clickable button for next/prev; insert into <code><a rel="clearbox[gallery=Name of the gallery comes here]"> href="http:example.com/img.jpg"><img src="http:example.com/img.jpg"></a></code>
| [http://www.kreaturamedia.com/clearbox/ Clearbox 3]
|
| proposed

|-
| [[rel-component|component]]
| External Resource
| Not allowed
| Specify an HTML document that is treated as a component of this document.
| [https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Web Components]
|
| proposed

|-
| [[rel-chrome-webstore-item|chrome-webstore-item]]
| External Resource
| Not allowed
| Link tag to declare for app and extensions inline installations hosted in the Chrome Web Store.
| [https://developers.google.com/chrome/web-store/docs/inline_installation Using Inline Installation]
|
| proposed

|-
| [[rel-dcterms.(property)#conformsTo|DCTERMS.conformsTo]]
| External Resource
| Not allowed
| An established standard to which the described resource conforms. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.conformsTo" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#contributor|DCTERMS.contributor]]
| External Resource
| Not allowed
| An entity responsible for making contributions to the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.contributor" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#creator|DCTERMS.creator]]
| External Resource
| Not allowed
| An entity primarily responsible for making the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.creator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#description|DCTERMS.description]]
| External Resource
| Not allowed
| An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.description" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#hasFormat|DCTERMS.hasFormat]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the pre-existing described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasPart|DCTERMS.hasPart]]
| External Resource
| Not allowed
| A related resource that is included either physically or logically in the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasVersion|DCTERMS.hasVersion]]
| External Resource
| Not allowed
| A related resource that is a version, edition, or adaptation of the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isFormatOf|DCTERMS.isFormatOf]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isPartOf|DCTERMS.isPartOf]]
| External Resource
| Not allowed
| A related resource in which the described resource is physically or logically included. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReferencedBy|DCTERMS.isReferencedBy]]
| External Resource
| Not allowed
| A related resource that references, cites, or otherwise points to the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReplacedBy|DCTERMS.isReplacedBy]]
| External Resource
| Not allowed
| A related resource that supplants, displaces, or supersedes the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isRequiredBy|DCTERMS.isRequiredBy]]
| External Resource
| Not allowed
| A related resource that requires the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isVersionOf|DCTERMS.isVersionOf]]
| External Resource
| Not allowed
| A related resource of which the described resource is a version, edition, or adaptation. <br />Changes in version imply substantive changes in content rather than differences in format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#license|DCTERMS.license]]
| External Resource
| Not allowed
| A legal document giving official permission to do something with the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.license" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#mediator|DCTERMS.mediator]]
| External Resource
| Not allowed
| An entity that mediates access to the resource and for whom the resource is intended or useful. In an educational context, a mediator might be a parent, teacher, teaching assistant, or care-giver. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.mediator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#publisher|DCTERMS.publisher]]
| External Resource
| Not allowed
| An entity responsible for making the resource available. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.publisher" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#references|DCTERMS.references]]
| External Resource
| Not allowed
| A related resource that is referenced, cited, or otherwise pointed to by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#relation|DCTERMS.relation]]
| External Resource
| Not allowed
| A related resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#replaces|DCTERMS.replaces]]
| External Resource
| Not allowed
| A related resource that is supplanted, displaced, or superseded by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#requires|DCTERMS.requires]]
| External Resource
| Not allowed
| A related resource that is required by the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#rightsHolder|DCTERMS.rightsHolder]]
| External Resource
| Not allowed
| A person or organization owning or managing rights over the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.rightsHolder" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#source|DCTERMS.source]]
| External Resource
| Not allowed
| A related resource from which the described resource is derived. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#subject|DCTERMS.subject]]
| External Resource
| Not allowed
| The topic of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-disclosure|disclosure]]
| Not allowed
| External Resource
| The 'disclosure' Link Relation Type designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation type is specified.
| [http://tools.ietf.org/html/draft-yevstifeyev-disclosure-relation The 'disclosure' Link Relation Type]
|
| proposed

|-
| [[rel-discussion|discussion]]
| Hyperlink
| Hyperlink
| Refers to discussion of the current document or post.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-dns-prefetch|dns-prefetch]]
| External Resource
| Not allowed
| Tells the browser to perform dns lookup for host names ahead of use.
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla documentation] [http://dev.chromium.org/developers/design-documents/dns-prefetching Google documentation]
|
| proposed

|-
| [[rel-edit|edit]]
| Hyperlink
| Not allowed
| Tells the browser where the current page can be edited
| [http://universaleditbutton.org/Registered_MIME_type#Alternate_Linking_Scheme Universal Edit Button Alternate Linking Scheme]. Implemented in at least [http://mediawiki.org MediaWiki].
|
| proposed

|-
| [[rel-edituri|EditURI]]
| External Resource
| Not allowed
| A blogging auto discovery value, commonly used by WordPress
| [http://bitworking.org/projects/atom/draft-gregorio-09.html#Edit AtomAPI]
|
| proposed

|-
| [[rel-enclosure|enclosure]]
| External Resource
| External Resource
| Indicates that the referred resource is intended to be downloaded and cached.
| [[rel-enclosure]]
|
| proposed

|-
| [[rel-entry-content|entry-content]]
| Not allowed
| External Resource
| Indicates that the referenced document is an alternative display source for an Internet Explorer Web Slice.
| [http://msdn.microsoft.com/en-us/library/cc304073(VS.85).aspx#_alternative Web Slice format specification 0.9]
|
| proposed

|-
| [[rel-external|external]]
| Not allowed
| Hyperlink
| Indicates that the referenced document is not part of the same site as the current document.
| [[rel-external]]
|
| proposed

|-
| [[rel-home|home]]
| Hyperlink
| Hyperlink
| Refers to the top level document for the current document. It can be combined with 'alternate' to indicate a feed for the site of the current page.
| [[rel-home]]
|
| proposed

|-
| [[rel-hub|hub]]
| Hyperlink
| Hyperlink
| Refers to a hub that enables registration for notification of updates to the current page.
| [http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#discovery PubSubHubbub Spec]
|
| proposed

|-
| [[rel-in-reply-to|in-reply-to]]
| Hyperlink
| Hyperlink
| Refers to an original post that the current page is a comment on or reply to.
| [[rel-in-reply-to]]
|
| proposed

|-
| [[rel-index|index]]
| Hyperlink
| Hyperlink
| Refers to a document providing a list of topics with pointers that pertain to the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
|
| proposed

|-
| [[rel-indieauth|indieauth]]
| External Resource
| Not allowed
| the IndieAuth server for the relying party to contact for IndieAuth authentication
| [http://spec.indieauth.com/ IndieAuth specification]
|
| proposed

|-
| [[rel-issues|issues]]
| Hyperlink
| Hyperlink
| Refers to issues regarding the current document or specification.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-jslicense|jslicense]]
| Hyperlink
| Hyperlink
| Refers to a document with JavaScript source code and license information (also called a [http://www.gnu.org/licenses/javascript-labels.html JavaScript License Web Labels] page). We might want choose a keyword for this that is more general -- there are many situations besides JavaScript in which it is desirable or required by license agreements (e.g., GNU GPL) to make an offer of both the source code and a copy of a license when distributing object code versions of a given work.
| [[rel-jslicense]]
|
| proposed

|-
| [[rel-lightbox|lightbox]]
| Not allowed
| Img Pop-Up
| Images with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked (e.g. with installed "Lightbox 2"-Plugin). When adding [group] to rel="lightbox" all images get a clickable button for next/prev; insert into <code><a rel="lightbox[group]"><img src="http:example.com/img.jpg"></a></code>
| [http://lokeshdhakar.com/projects/lightbox2/ Lightbox 2] (needs actual specification to be kept in this list, this link is just documentation of one implementation)
|
| proposed

|-
| [[rel-manifest|manifest]]
| External Resource
| Not allowed
| Imports or links to a manifest
| [http://w3c.github.io/manifest/#linking W3C Manifest for web application]
|
| proposed

|-
| [[rel-meta|meta]]
| External Resource
| Not allowed
| External metadata about the HTML document
| [http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-rdf-in-HTML W3C's RDF/XML Syntax Specification]
|
| proposed

|-
| [[rel-indieauth|micropub]]
| External Resource
| Not allowed
| the micropub endpoint for creating new posts
| [http://indiewebcamp.com/micropub Micropub scecification]
|
| proposed

|-
| [[rel-openid.delegate|openid.delegate]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 1.1 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid.server|openid.server]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 1.1 authentication
| [http://openid.net/specs/openid-authentication-1_1.html#anchor4 OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid2.local_id|openid2.local_id]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 2.0 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-openid2.provider|openid2.provider]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 2.0 authentication
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-p3pv1|p3pv1]]
| External Resource
| Not allowed
| References a machine-readable privacy policy description in the P3P format
| [http://www.w3.org/TR/P3P/#syntax_link P3P spec]
|
| proposed

|-
| [[rel-pgpkey|pgpkey]]
| External Resource
| Not allowed
| Associates a PGP key with a Web page so that the Web page URL can be used as the commenter's URL in PGP-signed blog comments and the blogging system receiving the comment can fetch the key and verify the signature as belonging to the owner of the URL.
| [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html PGP-Signed Comments]
|
| proposed

|-
| [[rel-pingback|pingback]]
| External Resource
| Not allowed
| gives the address of the pingback server that handles pingbacks to the current document
| [http://www.hixie.ch/specs/pingback/pingback Pingback]
|
| proposed

|-
| [[rel-prerender|prerender]]
| External Resource
| External Resource
| Prerenders the Web page targeted by the link including running it scripts.
| [[rel-prerender]]
|
| proposed

|-
| [[rel-prettyPhoto|prettyPhoto]]
| Not Allowed
| Img Pop-Up
| Images with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked
| [http://www.no-margin-for-errors.com/projects/prettyphoto-jquery-lightbox-clone/documentation/ PrettyPhoto]
|
| proposed

|-
| [[rel-profile|profile]]
| External Resource
| Contextual External Resource
| indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof. See also [[xmdp-brainstorming]].
| [http://microformats.org/wiki/rel-profile rel-profile]
|
| proposed

|-
| [[rel-publisher|publisher]]
| External Resource
| External Resource
| Indicates that the referenced document is a metadata profile (e.g., a social-media/real-name profile such as a Google+ profile) for the publisher of the current page, or some portion of the current page.
| [https://support.google.com/plus/answer/1713826?hl=en Google help page]
|
| proposed

|-
| [[rel-rendition|rendition]]
| External Resource
| External Resource
| Indicates some example rendering, interpretation, or depiction of the source. User agents may choose to execute, display, or render the target in-place; or navigate to the target.
| [http://www.globalmentor.com/specs/html-rel-rendition/ HTML rel rendition]
|
| proposed

|-
| [[rel-reply-to|reply-to]]
| External Resource
| Hyperlink
| indicates any mailbox(es) (i.e. email addresses) to which responses are to be sent. ''Note: this is distinct from the 'in-reply-to' value which refers to the originating document, not to the address where comments should be sent.
| [http://tools.ietf.org/html/rfc2822 RFC2822] (originally [http://tools.ietf.org/html/rfc822#section-4.4.3 RFC822])
|
| ratified

|-
| [[rel-service|service]]
| External Resource
| Not allowed
| Atom Publishing Protocol editing service autodiscovery.
| [http://wiki.whatwg.org/wiki/ServiceRelExtension Documentation on the WHATWG wiki]
|
| proposed

|-
| [[rel-shortlink|shortlink]]
| External Resource
| Not allowed
| Specifies the preferred shortened URL for the page.
| [http://code.google.com/p/shortlink/wiki/Specification shortlink spec]
|
| proposed

|-
| [[rel-sidebar|sidebar]]
| Hyperlink
| Hyperlink
| Indicates that the referenced document is intended to be shown in a secondary browsing context.
| [[rel-sidebar]]
|
| proposed

|-
| [[rel-sitemap|sitemap]]
| External Resource
| Not allowed
| Provides a link to an XML document describing the layout of the site.
| [[rel-sitemap]]
|
| proposed

|-
| [[rel-subresource|subresource]]
| External Resource
| Not allowed
| An external resource intended for use within the current page.
| [http://www.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource Chromium documentation]
|
| proposed

|-
| [[rel-syndication|syndication]]
| Hyperlink
| Hyperlink
| Refers to a page which is a syndicated copy of the current page.
| [[rel-syndication]]
|
| proposed

|-
| [[rel-timesheet|timesheet]]
| External Resource
| Not allowed
| Applies a timesheet to the document.
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet non-normative section in the Timesheet spec]
|
| proposed

|-
| [[rel-token_endpoint|token_endpoint]]
| External Resource
| Not allowed
| Specify an HTTP endpoint that micropub clients can use to obtain an access token given an authorization code
| [http://indiewebcamp.com/token-endpoint token endpoint documentation]
|
| proposed

|-
| [[rel-webmention|webmention]]
| External Resource
| Hyperlink
| gives the address of the webmention endpoint that handles webmentions to the current document
| [http://webmention.org/ WebMention specification]
|
| proposed

|-
| [[rel-widget|widget]]
| External Resource
| External Resource
| Autodiscovery for W3C widgets
| [http://dev.w3.org/2006/waf/widgets/Overview.html#linking-to-a-widget-package-from-a-html- non-normative section in the Widget packaging spec]
|
| proposed

|-
| [[rel-wlwmanifest|wlwmanifest]]
| External Resource
| Not allowed
| Windows Live Writer manifest autodiscovery
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx documentation on MSDN]
|
| proposed

|-
| [[rel-image_src|image_src]]
| External Resource
| Not allowed
| Specify a Webpage Icon for use by Facebook, Yahoo, Digg, etc.
| Unknown, but see for instance [http://www.niallkennedy.com/blog/2009/03/enhanced-social-share.html this]
| probably redundant with rel=icon
| proposed

|-
| [[rel-cmis-acl|http://docs.oasis-open.org/ns/cmis/link/200908/acl]]
| External Resource
| External Resource
| Identifies the resource containing a CMIS ACL document for the link context
| [http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html#_Toc243905525 CMIS 1.0, Section 3.4.3.4]
|
| proposed

|-
| [[rel-stylesheet/less|stylesheet/less]]
| External Resource
| Not allowed
| Less CSS framework stylesheets.
| [http://lesscss.org/#-client-side-usage Less CSS usage]
|
| proposed

|-
| [[rel-yandex-tableau-widget|yandex-tableau-widget]]
| External Resource
| Not allowed
| Lets webmasters configure the appearance of their own site widgets in Yandex.Browser
| [https://api.yandex.com/tableau/ Yandex's Tableau API]
|
| proposed
|}

== brainstorming ==
Several rel values are being brainstormed as potential microformats and are thus listed here. If you find you have a use for such semantics in real world examples, <strong>consider trying out</strong> these values and provide feedback on the respective brainstorming page(s) with your results and experiences.

You may list new proposed rel values here, and even better if you can list and link to POSH uses in the wild.

{| border="1"
|+
! rel value !! summary !! brainstormed in and usage in the wild

|-
| [[rel-accessibility|accessibility]] || indicate[s] that the destination of that hyperlink contains accessibility information for the current page. || [http://www.brucelawson.co.uk/2009/rel-accessibility/ blog post] which itself uses the rel value in a <link> tag in the head of the document.

|-
| [[rel-author|author]] || indicate[s] that the destination of that hyperlink represents the author of the current page. Combines with [[rel-me|rel-me]] to chain authorship information. || Google has said it will index rel-Author in this [http://googlewebmastercentral.blogspot.com/2011/06/authorship-markup-and-web-search.html blog post], with further [http://www.google.com/support/webmasters/bin/answer.py?answer=1229920 discussion of the rel-me connection] See also [http://dev.w3.org/html5/spec/Overview.html#link-type-author the HTML5 spec]

|-
| [[rel-bibliography|bibliography]] || indicate[s] that the destination of that hyperlink is a bibliography for the current page. || [http://microformats.org/discuss/mail/microformats-discuss/2007-October/010863.html mailing list post, 2007-10-15]

|-
| [[rel-cite|cite]] || indicate[s] that the destination of that hyperlink is an authoritative source or a precedent to the current page. || [[distributed-conversation-brainstorming]]

|-
| [[rel-group|group]] || the referenced document represents a group to which the person represented by the current document belongs || [[group-brainstorming]]

|-
| <span id="longdesc">[[rel-longdesc|longdesc]]</span> || Alternative to the img longdesc attribute, for use on visible links || [http://www.google.com/search?q=rel%3D%22longdesc%22 Google search for rel=longdesc in the wild] shows many sources of proposals. Please edit this to list the earliest and perhaps most recent/comprehensive proposal. No known real world POSH usage in the wild yet.

|-
| [[rel-map|map]] || Link to a map. Possibly embedded within an adr, hCard, geo or hCalendar. Parsers {{may}} attempt to parse the URL if it is a link to a known map site (e.g. Geohash, Google Maps, Multimap) and extract co-ordinates and other useful data. || (to [[User:TobyInk|TobyInk]] by email)

|-
| [[rel-member|member]] || the referenced document represents a member of the group represented by the current document || [[group-brainstorming]]

|-
| [[rel-m_PageScroll2id|m_PageScroll2id]] || JS to scroll to a defined ID || [[group-brainstorming]]

|-
| [[rel-preconnect|preconnect]] || indicates an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high costs of connection establishment latency.|| [https://igrigorik.github.io/resource-hints/#preconnect resource hints draft]

|-
| [[rel-prefetch|prefetch]] || indicates the URL and content-type of a resource that is likely to be a required resource when the next action or navigation is triggered. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#prefetch resource hints draft]

|-
| [[rel-preload|preload]] || indicates the URL and content-type of a resource that should be fetched as early as possible by the user agent. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#preload resource hints draft]

|-
| [[rel-prerender|prerender]] || indicates the URL of the next navigation target. Initiating a prerender allows the user agent to deliver an instant navigation experience: the user agent downloads the top-level resource and its assets, and performs all of the processing steps required to show the page without actually showing it to the user.|| [https://igrigorik.github.io/resource-hints/#prerender resource hints draft]

|-
| [[rel-profile|profile]] || indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof || [[xmdp-brainstorming]]

|-
| [[rel-shortlink|shortlink]] || the referenced document represents the current document but with a shorter URL || [http://samj.net/2009/04/introducing-relshort-better-alternative.html blog post]
|-
| source || the referenced document represents the source code for the current document or project || [[source-brainstorming]] [http://adactio.com/journal/6667/ blog post]

|-
| vcalendar-parent || link from an event to a containing event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-child || link from an event to a contained event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-sibling || link from an event to a related event with the same container || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]

|-
| [[rel-status|status]] || the referenced document represents the status (or source of status updates) for the author of this document || [http://monkinetic.com/2009/11/24/status-autodiscovery-relstatus.html blog post]

|}

=== more brainstorming ===
See also:
* [[genealogy-brainstorming]] for some thoughts on possible additional values for family relationships (use existing [[XFN]] [[rel-parent|parent]], [[rel-child|child]], [[rel-sibling|sibling]], [[rel-spouse|spouse]], [[rel-kin|kin]] values first though)
* [[xpn-brainstorming]] for some thoughts on possible additional values for professional relationships (use existing [[XFN]] [[rel-co-worker|co-worker]], [[rel-colleague|colleague]] values first though)

== POSH usage ==
There are numerous rel values used as [[POSH]], both in the wild, whose origins are not necessarily known, nor are their meanings consistent. There are also numerous rel values from external proposals of varying degrees of merit. It is useful to document their existence and summarize their implied meanings/usage intent as research that may be used to perhaps take one or more of them thru the microformats [[process]] if there is both sufficient interest and sufficient in the wild usage.

Note: If a value is missing from this table, it may have either already been promoted by writing it up as a proposal, or demoted by being explicitly dropped. Please check the other tables first before adding to this table.

Note: this list is incomplete, please help complete it from the following sources:

External sources:
* [http://developer.mozilla.org/about/meta Meta Information in DevMo Docs] (DevMo)
* [http://wiki.mozilla.org/Microsummaries Microsummary]
* [http://lachy.id.au/dev/markup/specs/wclr/ Web Communication Link Relationships] (WCLR)
* [http://www.w3.org/MarkUp/Relationships.html W3C Link Relationship values draft] (LRdraft) - from a draft of the HTML spec circa 1991.
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes HTML5 draft] '''Liable to change'''
* [http://wiki.foaf-project.org/Autodiscovery FOAF Project Wiki: Autodiscovery] (FOAF)
* [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]
* [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google Blog]

{| border="1"
|+
! rel value !! summary !! origin !! proposal(s)

|-
| [[rel-archive|archive]] || index of archived entries || unknown, perhaps Wordpress open source blogging software || WCLR

|-
| [[rel-archives|archives]] || Provides a link to a collection of records, documents, or other materials of historical interest. || || HTML5

|-
|[[rel-author|author]]||see brainstorming above for suggested use by google||unknown || DevMo / HTML5

|-
| [[rel-canonical|canonical]] || To help search engines disambiguate the same page with multiple representations || Google || [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google]/[http://www.bing.com/community/blogs/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft]/[http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo!], [http://blog.ask.com/2009/02/ask-is-going-canonical.html Ask Jeeves]

|-
| [[rel-comment|comment]] || … || … || WCLR

|-
| [[rel-contribution|contribution]] || … || … || WCLR

|-
| [[rel-edituri|EditURI]]
| Location of the xml-rpc gateway for a Wordpress install that allows external programs to add, edit and delete posts. Used by "[http://codex.wordpress.org/Weblog_Client WordPress blog client]" software for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. || Description stubbed in [[rel-edituri]].

|-
| [[rel-endorsed|endorsed]] || … || … || WCLR

|-
| [[rel-fan|fan]] || xxxx. || … || [[hcard-user-profile-authoring]]

|-
| [[rel-feed|feed]] || Gives the address of a syndication feed for the current document. || … || WCLR/ HTML5

|-
| [[rel-footnote|footnote]] || Location of the footnote on a link to a footnote. || Markdown preprocessors such as [http://maruku.rubyforge.org/ Maruku] || HTML5

|-
| [[rel-icon|icon]] || Imports an icon to represent the current document. (Allowed in <code>link</code> only) || [http://dev.w3.org/html5/spec-LC/links.html#rel-icon HTML5] || WCLR/HTML5

|-
| [[rel-kinetic-stylesheet|kinetic-stylesheet]] || Imports a [http://kssproject.org/ KSS] 'kinetic stylesheet' to bind dynamic behavior to elements || Used in the [http://plone.org Plone] Content Management System || …

|-
| [[rel-lightbox|lightbox]] || Hook - Indicates that following the link will trigger a "lightbox" script (Allowed in <code>link</code> only) || ([http://www.google.co.uk/search?q=rel%3D%22lightbox%22 Google search for rel=lightbox in the wild]) || …

|-
| [[rel-lightbox|lightbox[group_name]]] || Used by lightbox scripts to group different sets of images together. Images from one group will not appear in another group's lightbox. See also "lightbox". || [http://lokeshdhakar.com/projects/lightbox2/#how Lightbox 2] || …

|-
| [[rel-prettyPhoto|prettyPhoto]] || See also "lightbox" || ([http://www.google.fr/search?q=rel%3D%22prettyphoto%22 Google search for rel="prettyphoto" in the wild]) || …

|-
| [[rel-clearbox|clearbox]] || See also "lightbox" || ([http://www.google.fr/search?q=rel%3D%22clearbox%22 Google search for rel="clearbox" in the wild]) || …

|-
| [[rel-made|made]] || … || … || LRdraft

|-
| [[rel-meta|meta]] || … || [http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#transport 1999 W3C RDF syntax REC] || FOAF

|-
| [[rel-microsummary|microsummary]]|| … || … ||[http://wiki.mozilla.org/Microsummaries Microsummary], be aware of: [[page-summary-formats#Issues_2|microsummary issues]]

|-
| [[rel-noreferrer|noreferrer]] || indicates that no referrer information is to be leaked when following the link. || [http://dev.w3.org/html5/spec-LC/links.html#rel-noreferrer HTML5] || HTML5

|-
| [[rel-openid-delegate|openid.delegate]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-openid-server|openid.server]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-permalink|permalink]] || … || … || WCLR

|-
| [[rel-pgpkey|pgpkey]] || (see also rel-publickey) || … || [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html], [http://golem.ph.utexas.edu/~distler/blog/archives/000325.html]

|-
| [[rel-pingback|pingback]] || Gives the address of the pingback server that handles pingbacks to the current document. (Allowed in <code>link</code> only) || … || WCLR/ HTML5

|-
| [[rel-popover|popover]] || Used by a JS widget to display a large, descriptive tooltip. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#popovers Popover.js] || …

|-
| [[rel-prefetch|prefetch]] || Specifies that the target resource should be pre-emptively cached. (Allowed in <code>link</code> only) || … || HTML5

|-
| [[rel-privacy|privacy]] || Specifies that the target resource is the privacy policy. || … || …

|-
| [[rel-publickey|publickey]] || (see also rel-pgpkey) || … || [http://rasterweb.net/raster/2002/12/12/20021212072812/]

|-
| [[rel-referral|referral]] || … || … || WCLR

|-
| [[rel-related|related]] || … || … || WCLR

|-
| [[rel-replies|replies]] || indicates a continued thread || unknown || [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]

|-
| [[rel-respond-proxy|respond-proxy]] || Working with respond.js - proxy on external server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-respond-redirect|respond-redirect]] || Working with respond.js - redirect location on local server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-resource|resource]] || … || … || WCLR

|-
| [[rel-search|search]] || … || unknown || unknown

|-
| [[rel-sitemap|sitemap]] || Links to a site map document. || … || http://www.sitemaps.org/

|-
| [[rel-sponsor|sponsor]] || … || … || WCLR

|-
| [[rel-tooltip|tooltip]] || Used by a JS widget to display a tooltip similar (though more customizable) to what is shown by browsers if the 'title' attribute is present. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#tooltips Tooltip.js] (and likely other JS tools) || …

|-
| [[rel-trackback|trackback]] || … || unknown, perhaps open source Movable Type blogging software || WCLR

|-
| [[rel-unendorsed|unendorsed]] || (probably redundant to [[rel-nofollow|nofollow]]) || … || WCLR

|-
| [[rel-user|user]] || … || … || WCLR
|-
| [[rel-wlwmanifest|wlwmanifest]] || Used by "[http://explore.live.com/windows-live-writer Windows Live Writer]," a Microsoft [http://codex.wordpress.org/Weblog_Client blog client] for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. Similar values are probably used by other blog content management systems as well. || …

|}

=== WCLR ===

The WCLR proposal is described by its author (in e-mail, 2007-09-25) as:

<blockquote>
<p>…now effectively obsolete, since HTML5 and Microformats cover all the worthwhile relationships in that already.</p>

These are [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes covered by HTML5 already]:

* permalink -> bookmark
* archive -> archives
* feed
* pingback
* unendorsed -> nofollow

The rest now seem unnecessary.
</blockquote>

Nonetheless, there may be some mileage in using them in microformats, at least until HTML5 is widely available.

== Dublin Core ==
In the past, Dublin Core values have been added to this page in the table about HTML5 features, but no examples, nor an actual specification explicitly stating how the value(s) should be used in HTML could be found. The linked specifications below have been updated so we should start considering Dublin Core values accordingly.

{| border="1"
|+
! rel value !! summary !! source
|-
| schema.DC || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, with regard to the fifteen terms of the Dublin Core Metadata Element Set already published || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]

|-
| schema.DCTERMS || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, reflecting the changes described more fully in the 2012 document "Maintenance changes to DCMI Metadata Terms" [http://dublincore.org/usage/decisions/2012/dcterms-changes/] || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]
|-
|}

'''Issues need updating given new information from linked resources.'''

Notes:
* Dublin Core. This search may help: [http://www.google.co.uk/search?as_q=rel%3Dschema.*&hl=en&num=10&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=http%3A%2F%2Fdublincore.org&as_rights=&safe=images].
** '''examples from that search only use invisible <code><link href></code> element'''. At first glance it appears the results from the search show only uses with the invisible <code><link href></code> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <code><a href></code> are strongly preferred.
*** [http://www.ietf.org/rfc/rfc2731.txt RFC2731] defines <code>rel="schema.AC"</code> and <code>rel="schema.RC"</code> with the pattern <code>rel="schema.PREFIX"</code> as a syntax for defining namespaces for use in meta[@name], *[@rel], *[@rev] and (as per eRDF) *[@class] attributes. A link to a Dublin Core metadata schema is generally not suitable for end users, so <code><link href></code> appears to be more appropriate than <code><a href></code> for those that use Dublin Core metadata schemas.
*** The scheme proposed above provides metadata namespace declarations. As described by DCMI specifications, such indications '''cannot''' be provided w/o a suitable namespace. In order to give complete pieces of information, the correct description set must be: <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> (for the namespace declaration, followed by) <code><meta name="DCTERMS.<nowiki>[element]</nowiki>" content="<nowiki>[element.value]</nowiki>"></code> for related elements.
**** Note: [http://purl.org/dc/terms/ schema.DCTERMS] is conventionally related to an upgraded elements list than [http://purl.org/dc/elements/1.1/ schema.DC] and should be preferred as rel values. Both are discussed here for subject completeness)
** '''proposal to use in content currently only theoretical'''. Thus unfortunately the use of Dublin Core in user visible content like <code><a href></code> appears to be strictly theoretical. See [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011445.html microformats-discuss/2008-January/011445.html] for a proposal to use Dublin Core in user visible content.
*** '''recent improvements'''. DCMI solves some trouble concerning metadata through the ''description set model''. Some of these informations cannot currently be provided in any standard ways other than DC, namely dates, validity and periodicity. Following this public bug report ([https://www.w3.org/Bugs/Public/show_bug.cgi?format=multiple&id=22520]), the correct namespace declaration for DC and DCTERMS metadata are now considered valid HTML code. We '''must''' encourage this practice both for internal usefulness and for shared practices.

* The Dublin Core document [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] is a specification for, and gives examples of, both <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> and <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/">. Note that Dublin Core encourages the use of DCTERMS elements over DC. A list of projects which use Dublin Core metadata is maintained [http://dublincore.org/projects/ here].
* [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] also includes examples of <link rel="DCTERMS.[element]" href="">, where [element] = subject, isReferencedBy, creator, and publisher. The <link> tag is used instead of the <meta> tag whenever the content is a URL. (Note that this use is different from, but related to, <link rel="schema.DCTERMS" href="">.) Potentially, ''any'' of the 55 DCTERMS elements could be used in this way, and this could include use in HTML 5.
** As said before, HTML5 validators now allow the use of <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> for namespace declarations.

* According to DCMI specification linked above, as well as [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] documentation, HTML5 @rel attribute proposed values table has been updated. It now includes a subset of DCMI ''/terms/'' namespace properties, more specifically those whose value can (or must) be logically expressed by a resource, so that the "href" attribute value becomes a non-literal value surrogate referring to the resource itself.
** Elements from ''/elements/1.1/'' namespace have not been included on purpose. According to [http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces "FAQ/DC and DCTERMS Namespaces"], the old namespace is maintained for legacy purposes only and it is not as suitable for non-literal values as the ones denoted by <code><link></code> elements.

== Use with HTTP Link Header ==
You can also use any of the rel values (that are allowed for link elements) with HTTP Link Headers,

Example: returning a Javascript file with a license (since JS itself has no way to indicate a license)
<source lang=text>
Link: <http://creativecommons.org/publicdomain/zero/1.0/>; rel="license"
</source>

For multiple licenses (e.g. CC-SA and GPL), simply use multiple <code>Link:</code> headers.
<source lang=text>
Link: <http://creativecommons.org/licenses/by-sa/3.0/>; rel="license"
Link: <http://www.gnu.org/licenses/gpl.html>; rel="license"
</source>

Example: similarly, linking to a copyright statement for an image:
<source lang=text>
Link: <http://example.org/copyright.html>; rel="copyright"
</source>
or providing a brief inline copyright statement:
<source lang=text>
Link: <data:text/plain;charset=utf-8,Copyright 2013 ExampleCo, All Rights Reserved.>; rel="copyright"
</source>

== unspecified ==
Some rel values have been added to this page perhaps in one of the tables above, but no examples, nor an actual specification explicitly stating that the value(s) should be used in the HTML 'rel' attribute could be found. They are listed here in the hopes someone can discover more specific/precise URLs to examples or specifications about them (preferably both). Until such precise URLs to examples/specs are provided, the values can be treated as they are purely theoretical and thus of little interest.

A simple list here is sufficient.

== non HTML rel values ==
There are markup languages other than HTML that also have a rel attribute, often based upon the HTML rel attribute.
It is useful to document some of these other languages and their rel values for both reference purposes, and to provide background research for the possible development and re-use of these values in HTML, as [[poshformats]] or [[microformats]]

Sources:
* [[Atom]] [[RFC4287]] specification.
* See http://www.iana.org/assignments/link-relations.html for more.
* See [http://amundsen.com/media-types/maze/format/#link-relations Maze+XML]
* See [http://amundsen.com/media-types/collection/format/#link-relations Collection+JSON]
* See [http://www.opensearch.org/Specifications/OpenSearch/1.1#Url_rel_values OpenSearch]
* See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]
* See [http://rels.messages.io Workflow-Related Link Relations at Messages.io]

{| border="1"
|+
! rel value !! summary<br />(from the relevant specification where possible)) !! defining specification

|-
| self
| From http://www.ietf.org/rfc/rfc4287.txt : <blockquote>The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.</blockquote>
| [[Atom]] http://www.ietf.org/rfc/rfc4287.txt

|-
| http://gdata.youtube.com/schemas/2007#in-reply-to || See http://code.google.com/apis/youtube/2.0/developers_guide_protocol_comments.html || YouTube extension to Atom

|-
| collection || Refers to a resource which represents a collection of which the current resource is a member.

When used in the Maze+XML media type, the associated URI returns the available collection of mazes.
|| Maze+XML, Collection+JSON, OpenSearch

|-
| compensatingtx || Link to a resource representing information about a compensating transaction for each member transaction of a [http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf Long-Lived Compensating Transaction] || See [http://rels.messages.io/#compensatingtx Compensating Transaction Link Relation]

|-
| east || Refers to a resource to the "east" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the east in the active maze.

|| Maze+XML

|-
| events || Link to a collection resource representing a list of subscribe-able events. || See [http://rels.messages.io/#events Events Link Relation]

|-
| exit || Refers to a resource that represents the exit or end of the current client actvity or process.

When used in the Maze+XML media type, the associated URI points to the final exit resource of the active maze.

|| Maze+XML

|-
| north || Refers to a resource that is "north" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the north in the active maze.

|| Maze+XML

|-
| south || Refers to a resource that is "south" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the south in the active maze.

|| Maze+XML

|-
| [[rel-via|via]] || Identifies a resource that is the source of the information in the context. || Atom 1.0 Syndication format (RFC 4287)

|-
| west || Refers to a resource that is "west" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the west in the active maze.

|| Maze+XML

|-
| item || The target IRI points to a resource that is a member of a collection represented by the context IRI. || Collection+JSON

|-
| create-form || When included in a resource, the "create-form" link relation MAY identify a target resource that represents the form to append a new member to the link context. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| edit-form || When included in a resource, the "edit-form" link relation identifies a target resource that represents the form for editing associated resource. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| lightframe || Opens the target in a lightbox. On inclusion it provides a simple target the lightframe and loads the content in a lightbox effect || Lightbox

|-
| superbox[image] || jQuery Superbox! is a script which allows you display windows with the lightbox effect. || superbox

|-
| wp-video-lightbox || wp-video-lightbox! is a rel to anchor tag script display videos with the lightbox effect. || wp-video-lightbox

|-
| youtube || Opens the target youtube video in using the Swipebox Plugin || Swipebox

|-
| shadowbox || shadowbox is a jQuery script for images displaying with the "lightbox" effects. || shadowbox

|-
| permission || When included in a resource, the "permission" link relation MAY identify a target resource that represents the list of entities that can access or modify the resource in the link context. || See [http://cdoc.io/spec.html#permission-link-relation Collection Document Media Type Specification]

|-
| sub || When included in a resource representation of an event, the "sub" (subscription) link relation MAY identify a target resource that represents the ability to subscribe to the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#sub Subscription Link Relation]

|-
| unsub || When included in a resource representation of an event, the "unsub" (subscription cancellation) link relation MAY identify a target resource that represents the ability to un-subscribe from the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#unsub Subscription Cancellation Link Relation]

|-
| version-history
| When included on a versioned resource, this link points to a resource containing the version history for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| latest-version
| When included on a versioned resource, this link points to a resource containing the latest (e.g., current) version.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy
| When included on a versioned resource, this link points to a working copy for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy-of
| When included on a working copy, this link points to the versioned resource from which this working copy was obtained.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| predecessor-version
| When included on a versioned resource, this link points to a resource containing the predecessor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| successor-version
| When included on a versioned resource, this link points to a resource containing the successor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| ... || ... || ...

|}

== dropped ==
The following rel values were in earlier version(s) of specification(s) and it is presumed by their absence from the most recent version of the respective specification(s) that they have been deprecated or obsoleted.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

In particular:
* if a rel value was in a draft and is missing (without explanation) from the final spec, or
* if a rel value was in a previous version of and is missing (without explanation) from an update to the specification (even a draft update)

Then absent any other information or explanation, it is presumed that the group/editors working on that specification decided to explicitly drop it (either in development, or in the updated version) and thus it should be obsoleted (not re-registered).

If you wish to add them, please research <em>why</em> such values were omitted from latter specifications before doing so. If you do discover the reasoning, please add a short statement or link to thereof into the appropriate place in the following table.

If there is more data, e.g. a link to an email of discussion of the spec development that explains ''why'' the rel value was dropped, and it explicitly states, e.g. it was without prejudice, or merely post-poned, or perhaps expected to be spun-out into its spec (or some other explicit positive reason), then it makes to link/cite that explicit text as part of a proposal.

Sources:
* [http://www.w3.org/MarkUp/html3/ HTML3] (HTML3) / has been superceded by [http://www.w3.org/MarkUp/Wilbur/ HTML 3.2] - which itself has been superceded by [http://www.w3.org/TR/REC-html40 HTML 4.0] - which itself has been updated by [http://w3.org/TR/html401 HTML 4.01], commonly referred to as "HTML 4" in this wiki and other places.)
* [http://www.w3.org/TR/relations.html Proposed HTML 4.0 link types] (HTML4dropped) - obsoleted/superceded by the HTML 4.0 Recommendation. Any values that were in the "Proposed HTML 4.0 link types" document but didn't make it into the HTML 4.0 Recommendation were thus explicitly dropped and should be avoided.

{| border="1"
|+
! rel value !! summary !! defining specification !! why dropped

|-
|[[rel-banner|banner]]||Was used to reference another document to be used as banner for this document (i.e. a form of "include" statement).|| HTML3 ||unknown

|-
| [[rel-begin|begin]] || identifies the author-defined start of a sequence of documents of which the current document is a node.
|| HTML4dropped||unknown

|-
| [[rel-biblioentry|biblioentry]] || identifies a bibliographic entry || HTML4dropped||unknown

|-
| [[rel-bibliography|bibliography]] || identifies a bibliography || HTML4dropped||unknown

|-
| [[rel-child|child]] (obsolete/superceded) || the target document is a hierarchical child, or subdocument, of the current document|| HTML4dropped||unknown

|-
| [[rel-citation|citation]] || the target is a bibliographic citation || HTML4dropped||unknown

|-
| [[rel-collection|collection]] || the target document is an collection that contains the current document || HTML4dropped||unknown

|-
| [[rel-definition|definition]] || identifies a definition of a term || HTML4dropped||unknown

|-
| [[rel-disclaimer|disclaimer]] || identifies a hypertext link to a legal disclaimer || HTML4dropped||unknown

|-
| [[rel-editor|editor]] || identifies a hypertext link to an editor || HTML4dropped||unknown

|-
| [[rel-end|end]] || identifies the author-defined end of a sequence of documents of which the current document is a node. || HTML4dropped||unknown

|-
| [[rel-footnote|footnote]] || the anchor is a footnote marker and the target is a footnote || HTML4dropped||unknown

|-
| [[rel-navigate|navigate]] || the target document contains information such as a image map that will help users to gain a sense of how and where to found information || HTML4dropped||unknown

|-
| [[rel-origin|origin]] || synonym for <code>top</code> || HTML4dropped||unknown

|-
| [[rel-parent|parent]] (obsolete/superceded) || the target document is the hierarchical parent, or container, of the current document|| HTML4dropped||unknown

|-
| [[rel-pointer|pointer]] || the target is a pointer to the real target. This value can be used by a user agent to perform a pre-fetch of the specified target for evaluation until the real target is reached || HTML4dropped||unknown

|-
| [[rel-publisher|publisher]] || identifies a hypertext link to a publisher || HTML4dropped||unknown

|-
| [[rel-sibling|sibling]] (obsolete/superceded) || the target document is a child of a common parent, or a hierarchical peer of the current document|| HTML4dropped||unknown

|-
| [[rel-top|top]] || the target document is the logical top node of the tree (see also <code>begin</code>) || HTML4dropped||unknown

|-
| [[rel-trademark|trademark]] || identifies a hypertext link to a trademark notice || HTML4dropped||unknown

|-
| [[rel-translation|translation]] || the target is a translation to another language || HTML4dropped||unknown

|-
| [[rel-urc|urc]] || identifies a Universal Resource Citation || HTML4dropped||unknown

|-
|}

== dropped without prejudice ==
In one known instance (from HTML4 to HTML5), some rel values were in an earlier version of a specification (or a proposal) and were dropped from a latter (draft) version, and it was noted that these values were dropped with the intent that they could still be proposed in a registry and thus they explicitly were not deprecated or obsoleted. This section documents such values as separate from the [[#dropped|dropped]] section.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

Rel values that were dropped without prejudice from a specification will be considered similar to new values that have never been specified.

If you know of additional rel values that were dropped without prejudice from an update to a specification, please cite a URL and quote from the group developing the specification that officially states from that group that the dropping of the values was done without prejudice, or equivalent statement (such as explicit allowance of external registration, proposal, and/or development).

This table serves a historical purpose. If you wish to propose a value from this table, please copy it and leave it in place.

Sources:
* Several rel values were [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7475#c15 explicitly dropped from HTML5]. Per: [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Issue 118 Decision] ('''emphasis''' added): <blockquote><p>"The final proposal argues for the removal of some relation values, to wit, it suggests removal of '''index, up, first and last'''. It was pointed out in survey comments that these relations are already registered in the IANA link relation registry. Presumably, '''these relations could also be entered in whatever other registry or registries HTML5 adopts for this purpose'''.</p>...<p>"Next Steps</p>...<p>"Since the relations to be removed are already registered at the IANA link relation registry, no further action is needed to include them there. WG members are '''free to register or record these relations elsehwere''' [sic], as well."</p></blockquote>

{| border="1"
|+
! rel value
! summary
! defining specification
! why dropped

|-
| [[rel-first|first]]
| synonym for <code>begin</code>
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-index|index]]
| Refers to a document providing an index for the current document.
| was in [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-last|last]]
| synonym for <code>end</code>
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-up|up]]
|When the document forms part of a hierarchy, this link references the immediate parent of the current document.
| was in [http://www.w3.org/MarkUp/html3/dochead.html HTML3] - but [http://www.w3.org/TR/html401/types.html#type-links dropped in HTML4]
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
|}

See related [http://dev.w3.org/html5/spec/links.html#linkTypes HTML5: Link types] for existing HTML5 specified rel values.

== rejected ==
Some rel values have been proposed and rejected. They are listed here to make that explicit. Authors {{must not}} use rejected rel values.

Source: [[rejected-formats]].

{| border="1"
|+
! rel value !! origin / proposal !! why rejected
|-
| [[rel-logo|logo]]
| [http://relogo.org Relogo.org]
| [[rejected-formats#Logo]]
|-
|[[rel-pavatar|pavatar]] || [http://pavatar.com/ pavatar] || [[rejected-formats#Pavatar]]
|-
|}

== tools ==
See [[implementations]].

== addtional external research ==
Here are some additional historical references to the development or rel-values which may be useful when researching values, especially why specific values may have been proposed but abandoned.
* 1996-06-07 [http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt Hypertext links in HTML] (copies: [http://ftp.ics.uci.edu/pub/ietf/html/draft-ietf-html-relrev-00.txt ftp.ics.uci.edu])
* 1996-11-13 [http://www.w3.org/Architecture/NOTE-link Describing and Linking Web Resources]
* 1997-01-23 [http://lists.gnu.org/archive/html/lynx-dev/1997-01/msg00537.html LYNX-DEV Lynx and the LINK tag]
* 1997-01-24 [http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jan/0357.html Taxonomy list]
* 1997-03-28 [http://www.w3.org/TR/WD-htmllink-970328 W3C Working Draft: Hypertext Links and Meta Information in HTML]

=== previous attempts at documenting ===
There have been previous attempts at documenting known rel values, most of which fell out of date due to being dependent on a single author maintaining them. They're listed here purely for historical reasons, and are not sufficient to be references of their own (since they're just individual curations of other references)
* [http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html Link Type Definitions Glossary] by fantasai
* ...

== related ==
{{rel-related-pages}}
* [[elemental-microformats]]
* [[existing-rev-values]]
* [[existing-class-names]]

== copyright ==

{{cc-pd-license}}

microformats2-experimental-properties

2015-07-11T16:48:00Z

Kevin Marks: /* nickname? */

== h-as-* ==
ActivityStreams-based post types, usually done in combination with h-entry.

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example: h-as-note])

== h-x-username ==

=== Usage ===

* [http://glennjones.net/ glennjones.net] ([http://glennjones.net/notes/2015-07-11 example])
* [http://tantek.com/ tantek.com] ([http://tantek.com/2015/191/t1/indiewebcamp-pre-party example])

how is this different from [[h-card]]'s p-nickname ? [[User:Kevin Marks|Kevin Marks]]

== p-x-dietary-preference ==

For dietary preferences (vegetarian, vegan etc.) - the intention is to help event organisers organise catering by aggregating together the dietary preferences of attendees.

=== Suggested values ===
* ovo-lacto vegetarian
* lacto vegetarian
* ovo vegetarian
* vegan
* pescatarian
* omnivore
* gluten-free
* lactose-free

=== Usage ===
* [https://tommorris.org/ tommorris.org]

== p-x-pronoun-* ==

Properties to identify a user's preferred pronouns

; p-x-pronoun-nominative: the user's preferred nominative pronoun (e.g. he, she, they)
; p-x-pronoun-oblique: the user's preferred oblique pronoun (e.g. him, her, them)
; p-x-pronoun-possessive: the user's preferred possessive pronoun (e.g. his, hers, theirs)

=== Usage ===

* [https://waterpigs.co.uk/ waterpigs.co.uk]

== p-x-sexual-orientation ==

For when we eventually build the open web dating service.

;Suggested values:
:* straight or heterosexual
:* bisexual
:* pansexual
:* gay or lesbian or homosexual
:* asexual

=== Usage ===
* [https://tommorris.org/ tommorris.org]

microformats2-parsing-issues

2015-07-11T09:07:15Z

Kevin Marks: /* u- parsing iframe srcdoc */

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== Empty properties overridden by implied rules against user expectation ===
2015-07-03: raised by [[User:Glenn Jones|Glenn Jones]]

Emma Kuo brought up an issue (https://github.com/glennjones/microformat-node/issues/22) based on following the indieweb note pattern, where the content of a note is given both the e-content and p-name classes. If the element containing the notes only has none text content like image the p-name can have unexpected value. Here is the example she gave:

<code><pre>
<div class="h-entry">
<a href="http://this.site/photo" class="u-url"></a>
<div class="e-content p-name"><img src="photo.jpg" class="u-photo"/></div>
Some extraneous text
<div class="h-cite">
<a href="http://someother.site/like" class="u-url"></a>
<a href="http://this.site/photo" class="u-like-of"></a>
<div class="e-content p-name">liked this</div>
</div>
</div>
</pre></code>

At the moment I parser this as follows: - if a property (p-name) is empty do not add it to the output. In this case "empty" is classed as not containing any non-whitespace text. As far as I known there is no guidance on how to handle "empty" properties in microformats paring rules, so I followed the conventions of JSON API's not to return "empty" properties.

The side effect of the above is that p-name also has a number of "implied rules". The "implied rules" try to automatically fill properties like p-name if there is no defined value. In the example above it uses the textContent of the parent h-entry, so value of the h-entry>p-name is the text content of the h-cite i.e. "likes this".

Options:

1. We should not allow the "implied name rule" to get textContent from within a child h-*
<div class="discussion">
* +1 I believe this is inline with how we parse properties and will meet user/author expectations [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)
* -1 A nested h-* is still part of the content of the parent h-*, I don't quite understand the rationale for excluding it. For example, I may include lots of h-cards in the body of a post that references people and wouldn't want them to be excluded from the implied name generation. [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
* -1 I'm not sure this would solve the problem because auto-filled text could come from the parent h-* ("some extraneous text" in the example above) [[User:emmak|Emma Kuo]] 20:50, 4 July 2015 (UTC)
</div>
2. We should not execute the "implied rules" where there is an author defined "empty" property.
<div class="discussion">
* -1 Although the output would meet author expectations it is complex for parsers as they will have to keep state for each property through the whole series of parsing rules. [[User:Glenn Jones|Glenn Jones]] 9:22, 3 July 2015 (UTC)
* +1 An explicit, empty, p-name property should prevent an implicit p-name from being generated. For example tantek.com includes <span class="p-name"></span> at the start of the h-feed to prevent a giant name from being auto-generated. From my reading of the parsing spec, I don't see any reason that blank strings should be excluded from parsing. (mf2py and php-mf2 will both happily include empty strings in their output) [[User:Kylewm|Kylewm]] 14:40, 3 July 2015 (UTC)
</div>

=== uf2 children inside a classic microformats root class name ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behavior was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== microformats2 root class names should only see microformats2 properties ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== implied properties on backcompat parsing unlikely to be intended ===
Status: resolved, awaiting implementation attempt/experience.

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)

** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)

</div>

=== link elements and u- parsing ===
Status: resolved, awaiting implementation attempt/experience.

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== drop alternates collection ===
Status: resolved, warning in specification, awaiting implementations to drop

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 split into separate issue from include alternates in rels per implementation feedback from Kevin Marks. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls" in original issue now "include alternates in rels", we no longer need "alternates", and those with client consuming code have universally indicated that they would rather use rel-urls anyway. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform the the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# '''keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)'''
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
#* +1 will help parsers be more consistent with each other, and I haven't ever encountered a case where preserving leading/trailing whitespace was desirable [[User:Kylewm|Kylewm]] 20:45, 8 June 2015 (UTC)

2015-06-08 option 2 resolved by consensus and implementation in mf2py.

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== u- parsing iframe src ===
Currently if I put u-* on an iframe it gets the value of the fallback text. This seems a shame. Getting the URL seems a sensible answer.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== i- parsing iframe src ===

More controversially, what about using an iframe for transclusion? A use case here is comments on a static site. Currently, on eg http://www.kevinmarks.com/microformatschema.html the comments are injected via JS, making them opaque to parsers and thus precluding further parsing such as salmentions.

If instead they were an iframe embedding them, a parser could optionally fetch its contents, parse them, and include them in the parsed mf2 output at that point. Overloading u-* for this seems wrong; e-* as below for srcdoc would have a different effect; this implies a new prefix directive would be needed. A strawman i-* (for include) may work.
[[User:Kevin Marks|Kevin Marks]] 09:07, 11 July 2015 (UTC)

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
Status: incorporated into [[microformats2-parsing]]

<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

=== deduping of rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-02 by [[User:Kevin Marks|Kevin Marks]]
* 2015-06-05 resolved by consensus and one real world implementation proof of implementability and verification of expected results. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers
** Resolution: in the case of duplicate other attributes, first one set wins. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
* +1 makes sense to me, and not having them be sets in the current spec is likely an oversight on my part. Thanks for noting this issue. [[User:Tantek|Tantek]] 05:28, 3 June 2015 (UTC)
</div>

=== include alternates in rels ===
Status: incorporated into [[microformats2-parsing]]

2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.
* 2015-06-05 resolved per consensus and one real world implementation proof of implementability. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
** +1 drop "alternates" independently now made a separate issue. [[User:Tantek|Tantek]] 03:42, 6 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

rel-tag-faq

2015-06-29T23:50:14Z

Kevin Marks: /* rel-tag in Link elements */ visible metadata

= rel-tag frequently asked questions =

This document serves to answer and discuss frequently asked questions specifically about the [[rel-tag]] microformat. You may want to read the [[rel-faq]] first as it answers many common questions about the HTML4 "rel" and "rev" attributes, and their linktype values. If you have a new question to ask, first consider asking on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss list].

== Q&A ==

=== Where does a tagging link belong? ===
*Does the tagging link only need to appear in my Web feed (RSS / Atom)? Does the tagging link need to appear on the page where my specific blog entry lies? Does the tagging link need to appear everywhere that I can possibly imagine?
** In short, tagging links belong in all the places and formats in which you published tagged content. The Web page is the primary location where users read content and where search engines index. Thus the Web page is a place where you should absolutely include your [[rel-tag]] links. To tag your blog posts, put the [[rel-tag]] links inside them, visibly. The Web feeds are simply alternate ways of publishing your blog posts, and thus should include the full content of your blog posts, [[rel-tag]] links intact.
=== Where shouldn't I use rel-tag? ===
* rel-tag expresses a particular relationship (a) between the page you are on and (b) the target of a link. If you're not asserting this relationship, don't use rel-tag. In particular:
** don't use rel-tag in [http://en.wikipedia.org/wiki/Tag_cloud Tag Clouds]
** don't use rel-tag to refer to the pages http://www.technorati.com/tag/xyz, http://del.icio.us/tag/xyz, http://www.flickr.com/photos/tags/xyz/ (and so forth) if you're not asserting "this page is tagged 'xyz'"
=== Path with a . in ===
*The format specifies that the tag must "come after the last / in the path". Will something like <code><nowiki>http://example.com/index.php/TAG</nowiki></code> work? Or does it have to be a "real" directory or [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite]? -- [[User:Singpolyma|singpolyma]] 23:51, 24 Jan 2006 (PST)
** The key is the URL. Whether that URL is generated from a database or a directory does not matter. The URL matters.
*** My question, however, was about whether that URL form ( <code><nowiki>http://example.com/index.php/TAG</nowiki></code> ) would be valid, since there is the dot in "index.php".
**** Yes, the URL in the example is valid (or legal or conformant or whatever you want to call it to minimize confusion). The dot (period, full stop, U+002E) is free to appear in most places in a URL, even in the middle of a path-segment that is not the last path-segment. (The latest specification for URLs, "[http://gbiv.com/protocols/uri/rfc/rfc3986.html Uniform Resource Identifier (URI): Generic Syntax]", is RFC 3986.)
=== Using Apache mod_rewrite ===
* ''I'm developing a web application which uses tagging, and so of course I want to use [[rel-tag]]. For this application, I want nice, clean URLs. I was planning to use [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map a clean URL onto my underlying scripts. How do I use Apache's [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map <code><nowiki>http://example.org/~user/app/tag/car</nowiki></code> to <code><nowiki>http://example.org/~user/app/script.php?tag=car</nowiki></code> ?''
** One solution involves changing the script to inspect the path for the tag (via the variable "PATH_INFO"), rather than inspecting the query:
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/([^/]+)$ script.php/$1 [last]
</Directory></nowiki></pre>
** For people who can edit the server's main configuration file, the following untested configuration code may work. Corrections are welcome.
<pre><nowiki>RewriteEngine On
RewriteMap tag int:escape
RewriteRule ^/~user/app/tag/([^/]+)$ /~user/app/script.php?tag=${tag:$1} [last]</nowiki></pre>
** The following configuration code, left over from a previous contribution to this document, does a poor job according to tests. The following code fails to enforce the [[rel-tag]] rules about the tag corresponding to the last non-empty path-segment. The following code fails to transcode the tag for safe use in the URL query. Consider that a request on <code><nowiki>http://example.org/~user/app/tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/not-a-tag/the-tag</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=not-a-tag/the-tag</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/the-tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=the-tag/</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/attack&intent=destroy</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=attack&intent=destroy</nowiki></code> .
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/(.*)$ script.php?tag=$1
</Directory></nowiki></pre>
=== Does a rel tag still have meaning if the link redirects? ===
* If the HTTP server returns a 302 status code, does the rel-tag have meaning? Is there a formal rule that indexers should follow the link to the final, resolved destination? Or is there a formal rule that a rel tag should be ignored if URL of its link does not return a status code of 200?''
** Only the linked URL is important. The document specified by the URL, including any HTTP headers it contains are irrelevant. The whole point of rel-tag is that user-agents can figure out the name of the tag from the URL without having to make a request for the page linked to. [[User:TobyInk|TobyInk]] 03:56, 10 Aug 2007 (PDT)
=== rel-tag in Link elements===
*What is the rationale of rel-tag not being allowed in link elements, as long as rel-category is? Shouldn't the two have similar behaviours?
** The goal of rel-tag was to encourage visible, clickable links for tags, that are indexed by all search crawlers, not invisible metadata. See [http://microformats.org/wiki/rel-tag#Tags_Are_Visible_Metadata Tags Are Visible Metadata]

===CSS selector===
*How do you write a CSS selector for rel-tag?
** <code>a[rel~="tag"] { color: green }</code>

===Are tags case sensitive?===
*Are tags case sensitive. Is "Dog" the same tag as "dog" and "DOG"?
**{{AwaitingAnswer}}
**That's a conscious design decision for your site. Sites like Flickr intentionally normalize the tag name to reduce the possibility of multiple tags that mean the same thing. The name of the tag is more important than how it is displayed.

===Multi-word tags===
*How should a multi-word tag be made? For instance, if using Wikipedia as a name space, a page about a Black Redstart (a bird) would be tagged '''Black_Redstart''', with an underscore [http://en.wikipedia.org/wiki/Black_Redstart]. Is there any way of aliasing alternatives ("BlackRedstart", "Black-Redstart", etc.)? Is any particular format preferable?
** Existing bevavior
*** delicious supports combined tags
*** flickr supports multi-word tags with spaces but collapses spaces when searching
*** ma.gnolia supports multi-word tags with spaces
*** technorati supports multi-word tags with spaces
**{{AwaitingAnswer}}

===Tags with file extensions===
*Is <code><a rel="tag" href="<nowiki>http://example.com/cheese.htm</nowiki>">cheese</a></code> a valid tag for "cheese"? Ditto ".asp" or ".php" variants? If not, why not?

Any file-name extension in the last path segment is part of the tag value:

*<nowiki>http://example.com/cheese.htm</nowiki> ⇒ cheese.htm
*<nowiki>http://example.com/cheese.asp</nowiki> ⇒ cheese.asp
*<nowiki>http://example.com/cheese.php</nowiki> ⇒ cheese.php

The [[rel-tag|rel-tag specification]] is clear on how to extract a tag from a URL. Special treatment for file-name extensions is not part of the extraction. Brian Suda gave an [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008538.html explanation on the microformats-discuss list]. Consider the following URLs, the tags that the following URLs give under the current specification, and the effect of requiring special treatment for file-name extensions on the tags that the following URLs give.

*http://en.wikipedia.org/wiki/.htaccess
*http://en.wikipedia.org/wiki/.Net
*http://en.wikipedia.org/wiki/India.Arie
*http://en.wikipedia.org/wiki/ASN.1
*[http://en.wikipedia.org/wiki/L.I.E. http://en.wikipedia.org/wiki/L.I.E.]

===What about Scope?===
Since rel-tag is a feature used in many other microformats, the question often arises: "What is the scope of the tag?" For instance, a rel-tag may appear inside of an [[xfolk xFolk]] entry and on first glance it may appear that the tag should only apply to that entry. However, current publishing practice seems to indicate anything appearing on a page is likely related to the content of the page. Therefore, the interpretation is that not only does the rel-tag apply its direct container but to all containers and to the document as a whole; it contains the xFolk entry. This is a departure from strict knowledge theory in favor of real-world usage.

As another example, you may link to your friend Joe with XFN and hCard, indicating in his categories that Joe is interested in swimming, which you loathe. Since the article is primarily about you and not about Joe's hobbies and because the rel-tag is inside an hCard, you may expect that the rel-tag does not apply to the document; however, the document does contain information about swimming, albeit tiny, namely that your friend likes it. In this way, rel-tag is binary: it indicates direction (yes or no) but not magnitude. This equivalent to a free-text search sans [[http://en.wikipedia.org/wiki/tf-idf tf-idf]]; i.e. without a notion of term relevance.

The upshot of this is that rel-tags can have downward scope but not upward scope.

===Encoding and decoding the tag text in JavaScript===
If you want to get the text of the tag using JavaScript, you should use decodeURIComponent() to get a text representation of the tag, not escape. decodeURIComponent will properly handle UTF-8.

==Related pages==
{{rel-tag-related-pages}}
**{{AwaitingAnswer}}

rel-tag-faq

2015-06-29T23:46:00Z

Kevin Marks: clean up indenting for better ToC

= rel-tag frequently asked questions =

This document serves to answer and discuss frequently asked questions specifically about the [[rel-tag]] microformat. You may want to read the [[rel-faq]] first as it answers many common questions about the HTML4 "rel" and "rev" attributes, and their linktype values. If you have a new question to ask, first consider asking on the [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss list].

== Q&A ==

=== Where does a tagging link belong? ===
*Does the tagging link only need to appear in my Web feed (RSS / Atom)? Does the tagging link need to appear on the page where my specific blog entry lies? Does the tagging link need to appear everywhere that I can possibly imagine?
** In short, tagging links belong in all the places and formats in which you published tagged content. The Web page is the primary location where users read content and where search engines index. Thus the Web page is a place where you should absolutely include your [[rel-tag]] links. To tag your blog posts, put the [[rel-tag]] links inside them, visibly. The Web feeds are simply alternate ways of publishing your blog posts, and thus should include the full content of your blog posts, [[rel-tag]] links intact.
=== Where shouldn't I use rel-tag? ===
* rel-tag expresses a particular relationship (a) between the page you are on and (b) the target of a link. If you're not asserting this relationship, don't use rel-tag. In particular:
** don't use rel-tag in [http://en.wikipedia.org/wiki/Tag_cloud Tag Clouds]
** don't use rel-tag to refer to the pages http://www.technorati.com/tag/xyz, http://del.icio.us/tag/xyz, http://www.flickr.com/photos/tags/xyz/ (and so forth) if you're not asserting "this page is tagged 'xyz'"
=== Path with a . in ===
*The format specifies that the tag must "come after the last / in the path". Will something like <code><nowiki>http://example.com/index.php/TAG</nowiki></code> work? Or does it have to be a "real" directory or [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite]? -- [[User:Singpolyma|singpolyma]] 23:51, 24 Jan 2006 (PST)
** The key is the URL. Whether that URL is generated from a database or a directory does not matter. The URL matters.
*** My question, however, was about whether that URL form ( <code><nowiki>http://example.com/index.php/TAG</nowiki></code> ) would be valid, since there is the dot in "index.php".
**** Yes, the URL in the example is valid (or legal or conformant or whatever you want to call it to minimize confusion). The dot (period, full stop, U+002E) is free to appear in most places in a URL, even in the middle of a path-segment that is not the last path-segment. (The latest specification for URLs, "[http://gbiv.com/protocols/uri/rfc/rfc3986.html Uniform Resource Identifier (URI): Generic Syntax]", is RFC 3986.)
=== Using Apache mod_rewrite ===
* ''I'm developing a web application which uses tagging, and so of course I want to use [[rel-tag]]. For this application, I want nice, clean URLs. I was planning to use [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map a clean URL onto my underlying scripts. How do I use Apache's [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html mod_rewrite] to map <code><nowiki>http://example.org/~user/app/tag/car</nowiki></code> to <code><nowiki>http://example.org/~user/app/script.php?tag=car</nowiki></code> ?''
** One solution involves changing the script to inspect the path for the tag (via the variable "PATH_INFO"), rather than inspecting the query:
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/([^/]+)$ script.php/$1 [last]
</Directory></nowiki></pre>
** For people who can edit the server's main configuration file, the following untested configuration code may work. Corrections are welcome.
<pre><nowiki>RewriteEngine On
RewriteMap tag int:escape
RewriteRule ^/~user/app/tag/([^/]+)$ /~user/app/script.php?tag=${tag:$1} [last]</nowiki></pre>
** The following configuration code, left over from a previous contribution to this document, does a poor job according to tests. The following code fails to enforce the [[rel-tag]] rules about the tag corresponding to the last non-empty path-segment. The following code fails to transcode the tag for safe use in the URL query. Consider that a request on <code><nowiki>http://example.org/~user/app/tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/not-a-tag/the-tag</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=not-a-tag/the-tag</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/the-tag/</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=the-tag/</nowiki></code> . Consider that a request on <code><nowiki>http://example.org/~user/app/tag/attack&intent=destroy</nowiki></code> would map internally to a request on <code><nowiki>http://example.org/~user/app/script.php?tag=attack&intent=destroy</nowiki></code> .
<pre><nowiki><Directory "/home/user/public_html/app/>
RewriteEngine On
RewriteRule ^tag/(.*)$ script.php?tag=$1
</Directory></nowiki></pre>
=== Does a rel tag still have meaning if the link redirects? ===
* If the HTTP server returns a 302 status code, does the rel-tag have meaning? Is there a formal rule that indexers should follow the link to the final, resolved destination? Or is there a formal rule that a rel tag should be ignored if URL of its link does not return a status code of 200?''
** Only the linked URL is important. The document specified by the URL, including any HTTP headers it contains are irrelevant. The whole point of rel-tag is that user-agents can figure out the name of the tag from the URL without having to make a request for the page linked to. [[User:TobyInk|TobyInk]] 03:56, 10 Aug 2007 (PDT)
=== rel-tag in Link elements===
*What is the rationale of rel-tag not being allowed in link elements, as long as rel-category is? Shouldn't the two have similar behaviours?''

===CSS selector===
*How do you write a CSS selector for rel-tag?
** <code>a[rel~="tag"] { color: green }</code>

===Are tags case sensitive?===
*Are tags case sensitive. Is "Dog" the same tag as "dog" and "DOG"?
**{{AwaitingAnswer}}
**That's a conscious design decision for your site. Sites like Flickr intentionally normalize the tag name to reduce the possibility of multiple tags that mean the same thing. The name of the tag is more important than how it is displayed.

===Multi-word tags===
*How should a multi-word tag be made? For instance, if using Wikipedia as a name space, a page about a Black Redstart (a bird) would be tagged '''Black_Redstart''', with an underscore [http://en.wikipedia.org/wiki/Black_Redstart]. Is there any way of aliasing alternatives ("BlackRedstart", "Black-Redstart", etc.)? Is any particular format preferable?
** Existing bevavior
*** delicious supports combined tags
*** flickr supports multi-word tags with spaces but collapses spaces when searching
*** ma.gnolia supports multi-word tags with spaces
*** technorati supports multi-word tags with spaces
**{{AwaitingAnswer}}

===Tags with file extensions===
*Is <code><a rel="tag" href="<nowiki>http://example.com/cheese.htm</nowiki>">cheese</a></code> a valid tag for "cheese"? Ditto ".asp" or ".php" variants? If not, why not?

Any file-name extension in the last path segment is part of the tag value:

*<nowiki>http://example.com/cheese.htm</nowiki> ⇒ cheese.htm
*<nowiki>http://example.com/cheese.asp</nowiki> ⇒ cheese.asp
*<nowiki>http://example.com/cheese.php</nowiki> ⇒ cheese.php

The [[rel-tag|rel-tag specification]] is clear on how to extract a tag from a URL. Special treatment for file-name extensions is not part of the extraction. Brian Suda gave an [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008538.html explanation on the microformats-discuss list]. Consider the following URLs, the tags that the following URLs give under the current specification, and the effect of requiring special treatment for file-name extensions on the tags that the following URLs give.

*http://en.wikipedia.org/wiki/.htaccess
*http://en.wikipedia.org/wiki/.Net
*http://en.wikipedia.org/wiki/India.Arie
*http://en.wikipedia.org/wiki/ASN.1
*[http://en.wikipedia.org/wiki/L.I.E. http://en.wikipedia.org/wiki/L.I.E.]

===What about Scope?===
Since rel-tag is a feature used in many other microformats, the question often arises: "What is the scope of the tag?" For instance, a rel-tag may appear inside of an [[xfolk xFolk]] entry and on first glance it may appear that the tag should only apply to that entry. However, current publishing practice seems to indicate anything appearing on a page is likely related to the content of the page. Therefore, the interpretation is that not only does the rel-tag apply its direct container but to all containers and to the document as a whole; it contains the xFolk entry. This is a departure from strict knowledge theory in favor of real-world usage.

As another example, you may link to your friend Joe with XFN and hCard, indicating in his categories that Joe is interested in swimming, which you loathe. Since the article is primarily about you and not about Joe's hobbies and because the rel-tag is inside an hCard, you may expect that the rel-tag does not apply to the document; however, the document does contain information about swimming, albeit tiny, namely that your friend likes it. In this way, rel-tag is binary: it indicates direction (yes or no) but not magnitude. This equivalent to a free-text search sans [[http://en.wikipedia.org/wiki/tf-idf tf-idf]]; i.e. without a notion of term relevance.

The upshot of this is that rel-tags can have downward scope but not upward scope.

===Encoding and decoding the tag text in JavaScript===
If you want to get the text of the tag using JavaScript, you should use decodeURIComponent() to get a text representation of the tag, not escape. decodeURIComponent will properly handle UTF-8.

==Related pages==
{{rel-tag-related-pages}}
**{{AwaitingAnswer}}

about

2015-06-19T02:54:47Z

Kevin Marks: Undo revision 65066 by Johnukony (Talk) undo spam

<entry-title>About microformats</entry-title>

[[about|About microformats]] | [[about/thanks|Thanks]] | [[about/people|People]] | [[about/colophon|Colophon]]

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns.

== Microformats are ==
* A way of thinking about data
* Design principles for formats
* Adapted to current behaviors and usage patterns (“[http://ifindkarma.typepad.com/relax/2004/12/microformats.html Pave the cow paths].”)
* Highly correlated with semantic XHTML, AKA the [http://www.tantek.com/presentations/2004etech/realworldsemanticspres.html real world semantics, AKA lowercase semantic web], AKA lossless HTML
* A set of simple open data format standards that many are actively developing and implementing for more/better structured blogging and web microcontent publishing in general.
* “[http://theryanking.com/blog/archives/2005/04/07/an-evolutionary-revolution/ An evolutionary revolution]”
* All the above.

== Microformats are not ==
* A new language
* Infinitely extensible and open-ended (though [[microformats2]] is a bit more extensible)
* An attempt to get everyone to change their behavior and rewrite their tools
* A whole new approach that throws away what already works today
* A panacea for all taxonomies, ontologies, and other such abstractions
* Defining the whole world, or even just boiling the ocean
* Any of the above

== The microformats principles ==
* Solve a specific problem
* [[start-simple|Start as simple]] as possible
* Design for humans first, machines second
* [[Reuse]] building blocks from widely adopted standards
* Modularity / embeddability
* Enable and encourage decentralized development, content, services

== historical ==
This page is largely historical, and acts as a wiki editable replacement for http://microformats.org/about.

== See Also ==
* [[microformats]]
* [[microformats2]]
* [[principles]]

----
Return to [[Main_Page]]

microformats2-parsing-issues

2015-06-02T23:51:12Z

Kevin Marks: /* deduping of rels */ close div

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== deduping of rels ===
2015-06-02 by [[User:Kevin Marks|Kevin Marks]]

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)
</div>

=== drop alternates collection and include them in rels ===
2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform the the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== uf2 children inside a classic microformats root class name ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behavior was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== microformats2 root class names should only see microformats2 properties ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== implied properties on backcompat parsing unlikely to be intended ===
Status: resolved, awaiting implementation attempt/experience.

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)

** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)

</div>

=== link elements and u- parsing ===
Status: resolved, awaiting implementation attempt/experience.

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]

microformats2-parsing-issues

2015-06-02T23:49:35Z

Kevin Marks: /* deduping of rels */ implementation to try

This page is for documenting issues with the [[microformats2-parsing]] specification.

== issues ==
Open issues in various states of partial resolution from none to nearly resolved.

=== deduping of rels ===
2015-06-02 by [[User:Kevin Marks|Kevin Marks]]

Many sites have multiple duplicate rel links to the same url - a very common case is WordPress home pages eg [http://ma.tt ma.tt]

Each post on the page has a block like
<code><pre>
<div class="entry-meta">
<span class="date">
<a href="http://ma.tt/2015/05/beethoven-mozart-bach/"
title="Permalink to Beethoven, Mozart, Bach" rel="bookmark">
<time class="entry-date" datetime="2015-05-31T22:42:00+00:00">May 31, 2015</time></a></span>
<span class="categories-links">
<a href="http://ma.tt/category/asides/" rel="category tag">Asides</a></span>
<span class="author vcard">
<a class="url fn n" href="http://ma.tt/author/saxmatt/"
title="View all posts by Matt" rel="author">Matt</a></span>
</div></pre></code>

As currently defined, the parser will create duplicate entries in <code>rels</code> for each post:
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/",
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/",
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/",
"https://ma.tt/"
],
}
</pre></code>

and in the <code>rel-urls</code> we will also see:
<code><pre>
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author",
"author",
"author",
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home",
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag",
"category",
"tag",
"category",
"tag",
"category",
"tag"
],
"text": "Asides"
}
</pre></code>
These duplicates are unhelpful for parser consumers. We should:
* make them both sets - only listing distinct values. This will remove ordering information, but order is irrelevant for rel in html.
<code><pre>
"rels": {
"category": [
"https://ma.tt/category/asides/"
],
"author": [
"https://ma.tt/author/saxmatt/"
],
"tag": [
"https://ma.tt/category/asides/"
],
"home": [
"https://ma.tt/"
],
}
…
"rel-urls": {
"https://ma.tt/author/saxmatt/": {
"rels": [
"author"
],
"text": "Matt",
"title": "View all posts by Matt"
},
…
"https://ma.tt/": {
"rels": [
"home"
],
"text": "Matt Mullenweg",
"title": "Matt Mullenweg"
},
…
"https://ma.tt/category/asides/": {
"rels": [
"category",
"tag"
],
"text": "Asides"
}
</pre></code>

* possibly we could also make <code>title</code> <code>text</code> <code>type</code> sets too. That would solve the information loss issue with the current parsers

<div class="discussion">
* +1 as the proposer. A version of mf2py that does this is running at unmung,com. see [http://www.unmung.com/mf2?url=https%3A%2F%2Fma.tt&html=&pretty=on fro ma.tt] or [http://www.unmung.com/?html=%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E%0D%0A%3Ca+href%3D%22http%3A%2F%2Fma.tt%2Fcategory%2Fasides%2F%22+rel%3D%22category+tag%22%3EAsides%3C%2Fa%3E&pretty=on a simple test] [[User:Kevin Marks|Kevin Marks]] 23:49, 2 June 2015 (UTC)

=== drop alternates collection and include them in rels ===
2015-06-01 by [[Tantek]], per inconsistency noted by Kevin Marks.

As fallout from the adoption and implementation of 'rel-urls' per [[microformats2-parsing-brainstorming#more_information_for_rel-based_formats]], we should:
* add "alternate" rels to the "rels" collection to make them easier to look-up in "rel-urls" - that is, all rel values end up in "rels" collections. No exceptions.
* drop "alternates" as its no longer needed, and all current consuming code clients like rel-urls better anyway.

<div class="discussion">
* +1 [[User:Tantek|Tantek]] as the documenter of this issue, and attempting to represent what I think KevinMarks intended with "rels" and "rel-urls".
* +1 This makes sense to me, as the <code>rels</code> and <code>rel-urls</code> should match so you can lookup in rels first, then get details about urls from rel-urls. We can drop "alternates" independently from this change. [[User:Kevin Marks|Kevin Marks]] 00:23, 2 June 2015 (UTC)
* +1 Makes sense. And I agree with Kevin; I think parsers should deprecate "alternates" for now and drop it after a version cycle or two. [[User:Kylewm|Kylewm]] 00:30, 2 June 2015 (UTC)
* implemented in [https://github.com/kevinmarks/mf2py/commit/4dba45200eef11da811f64817d02044ab9e98b77 my fork of mf2py] and running on [http://www.unmung.com/?html=%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fa%22%3Eauthor+a%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22author%22+href%3D%22http%3A%2F%2Fexample.com%2Fb%22%3Eauthor+b%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F1%22%3Epost+1%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22in-reply-to%22+href%3D%22http%3A%2F%2Fexample.com%2F2%22%3Epost+2%3C%2Fa%3E%0D%0A%3Ca+rel%3D%22alternate+home%22%0D%0A+++href%3D%22http%3A%2F%2Fexample.com%2Ffr%22%0D%0A+++media%3D%22handheld%22%0D%0A+++hreflang%3D%22fr%22%3EFrench+mobile+homepage%3C%2Fa%3E&pretty=on unmung] [[User:Kevin Marks|Kevin Marks]] 01:29, 2 June 2015 (UTC)
</div>

=== whitespace collapsing revisited ===
2015-05-27: (raised by [[User:Kevin Marks|Kevin Marks]] per Glenn Jones)

Revising the microformats tests to conform the the "don't collapse whitespace" rule below reveals some non-intuitive cases.
preserving whitespace in addresses is somewhat defensible, but in an implied name it is often unhelpful, as it preserves non-user visible space there for authoring reasons.

For example:
[https://github.com/microformats/tests/commit/a325e0e9bc2089507e69b1883f7065a3316e07c2#diff-d577012c1438978a571c4049179607f0 this test] shows how extraneous whitespace ends up in the <code>name</code>

<code><pre>
<div class="h-review-aggregate">
<div class="p-item h-event">
<h3 class="p-name">Fullfrontal</h3>
<p class="p-description">A one day JavaScript Conference held in Brighton</p>
<p><time class="dt-start" datetime="2012-11-09">9th November 2012</time></p>
</div>

<p class="p-rating">
<span class="p-average value">9.9</span> out of
<span class="p-best">10</span>
based on <span class="p-count">62</span> reviews
</p>
</div>
</pre></code>

give a parsed result of:

<code><pre>
{
"items": [{
"type": ["h-review-aggregate"],
"properties": {
"item": [{
"value": "Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012",
"type": ["h-event"],
"properties": {
"name": ["Fullfrontal"],
"description": ["A one day JavaScript Conference held in Brighton"],
"start": ["2012-11-09"]
}
}],
"rating": ["9.9"],
"average": ["9.9"],
"best": ["10"],
"count": ["62"],
"name": ["Fullfrontal\nA one day JavaScript Conference held in Brighton\n9th November 2012\n\n\n9.9 out of \n 10 \n based on 62 reviews"]
}
}],
"rels": {}
}
</pre></code>

The <code>value</code> is a reasonable textual representation of the event, but the implied <code>name</code> is full of spurious whitespace that any consumer would have to strip.

[https://github.com/microformats/tests/commit/4c9690b53b0a2f40440abac8e609c51ac7dd6d56 h-review] has similar issues

2015-05-28: (Addition by [[User:GlennJones|Glenn Jones]])

The example below shows the type of markup most effected by the "implied name" and "don't collapse whitespace" rule working together to produce output that is hard to use without further processing.

<code><pre>
<a class="h-card" href="http://glennjones.net">
<span class="p-given-name">Glenn</span>
<span class="p-family-name">Jones</span>
</a>
</pre></code>

The output for the name property from the above HTML would be <code>Glenn\r\n Jones</code> using the (trim lead/trailing) suggested in the parsing spec. I could of course move the spans onto one line, but it feels fragile to consider whitespace sensitivity in HTML like this. Added to the fact that HTML templating environments often take away that level of whitespace control from authors anyway.

There are issues with both: keeping whitespace, returns and tabs from parsed HTML or collapse that whitespace. If we return the whitespace it becomes mal-formatted for humans because it was only added to make the HTML code understandable and in most cases was not meant to be used/read outside of that context. If we collapse the whitespace we can have issues of whitespace sensitive text from <code><pre></code> etc. being incorrectly formatted.

Providing a CSS aware innerText feature would produce the most useable output, but this is too complex/time consuming to build for most parser developers. In the face of no perfect solution I have taken the 80:20 view, whereby errant whitespace, causes me considerably more problems than mal-formatted <code><pre></code> content so I collapse whitespace on all text returned.

This feature is a non-CSS aware version of innerText. It does not cover all rendering edge cases, but enough to produce practical output.

For now, I have started changing the node parser to flag "white-space collapsing" as an experimental feature which is off by default i.e. http://glennjones.net/tools/microformats/ but personally I will parse everything with this on as I find it the most practical solution.

Not sure where that leaves me on the options below.

Options:

Choose from:
# keep as is and every parser client has to post process for common cases.
# keep as is but have mf2 parser trim leading/trailing whitespace (likely to provide desired result and be reasonably backcompat)
#* +1 my preference of the two options. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
#* +1 though this doesn't solve any of the problems discussed above, it's still worth doing [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Somewhat orthogonal:
* make <code>value</code> on properties with children normalise whitespace
** -1 Seems like a bad idea as this "value" is supposed to be the same as if there was no embedded child microformat. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
* make implied <code>name</code> normalise whitespace.
** +0 This is reasonable and already done somewhat in the parsing spec (trim lead/trailing). [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** +1 Given the universality of name, this would fix most of the issues we see. [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)
* Put \n in textual forms if there is a <code><p></code> tag in the original.
** -1 that's a long path to go down with whitespace equivalents for HTML markup. [[User:Tantek|Tantek]] 20:45, 27 May 2015 (UTC)
** would only preserving whitespace if in <pre> be an 80:20 compromise? [[User:Kevin Marks|Kevin Marks]] 16:41, 28 May 2015 (UTC)

Because there are both code markup and specific vocabulary (label) needs for preserving whitespace, we are compelled to preserve in general, perhaps except for very specific limited generic cases (e.g. trim leading/trailing, "value" parsing, implied name). [[User:Tantek|Tantek]]

=== uf2 children inside a classic microformats root class name ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: (raised by kylewm) What should microformats2 children inside a classic microformats root class name do?

Options:

1. Nothing. Any unattached uf2 children inside a classic microformats root are ignored. Problems:
<div class="discussion">
* However then there's a possible surprise if/when the author upgrades the classic microformats root to uf2, then all of a sudden all the new uf2 children show-up.
* Another downside: author adds uf2 markup, can't figure out why nothing is happening (because somewhere up the tree in code they didn't touch is classic microformats that are hiding these unattached uf2 children.
</div>
2. Show up in the children collection of the classic microformats root
<div class="discussion">
* Feels most predictable. When you add uf2 root class names anywhere, they will show up in the JSON output hierarchy.
* When you convert ancestor class microformats root class names to uf2 root class names, no surprise in terms of which microformats show up. Same children collection.
* +1 Thus I'm leaning towards this one, despite the fact that classic microformats never had a concept of generic unattached children. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>
3. Show up as peers to the classic microformats root. Issue(s)
<div class="discussion">
* Has ths surprise aspect of if/when you convert the classic root class name to a uf2 root class name, the former peers become unattached children.
</div>

=== any h- root class name overrides and stops backcompat root ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: The presence of any h-* root class name overrides and stop any backcompat parsing of classic microformats root class names. [[User:Tantek|Tantek]] 04:55, 21 January 2015 (UTC)

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for restricting backcompat root class name to only seeing backcompat property class names
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== backcompat classic microformats should only see backcompat properties ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: When parsing a microformats vocabulary that indicates a backcompat root class name (and thus an absence of the microformats2 equivalent on the same element), parsers must only look for the backcompat properties that are specified explicitly for that backcompat root class.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such behavior was never expected by authors, and crossing a classic microformats root class name with microformats2 property names were never explicitly expected nor specified to work.

Thoughts?
<div class="discussion">
* Tom & Kyle - implementable with the same backcompat root flag as needed for
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== microformats2 root class names should only see microformats2 properties ===
Status: resolved, awaiting implementation attempt/experience.

2015-020: When parsing a microformats2 root class name, only explicit microformats2 properties should be parsed. Any backcompat property names must be ignored.
[[User:Tantek|Tantek]] 04:04, 21 January 2015 (UTC)

Reasoning: such microformats2 authors should be expected to do all their microformats markup with microformats2 class names - this is a deliberate expectation so that their microformats aren't polluted with other (classic microformats) coincidentally named generic class names.

Thoughts?
<div class="discussion">
* ++ Consensus at [[2015-01-20]] - option that presents the least surprises in the most cases.
</div>

=== implied properties on backcompat parsing unlikely to be intended ===
Status: resolved, awaiting implementation attempt/experience.

<div class="discussion">
Since classic microformats had no notion of implied properties, when implied property parsing occurs on backward compat classic microformats root class names, it is unlikely that any implied property (p-name u-url u-photo) was ever intended by the author of the classic microformat. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)
Examples:
* see https://indiewebcamp.com/h-entry#bad_hentry_properties for a growing list

'''Proposed resolution:'''

* Be explicit in implied property parsing that it must only be done for explicit 'h-*' root class name microformats, not for any (back)compat parsing of microformats. Please comment on this proposal with "** comment" on new lines below. [[User:Tantek|Tantek]] 02:43, 30 December 2014 (UTC)

** +1 This makes a lot of sense to me. We should strive to parse mf1 as it was intended by the author, and I think you're right that implied rules are unlikely to be what was intended [[User:Kylewm|Kylewm]] 03:22, 30 December 2014 (UTC)
** RESOLVED at [[2015-01-20]] meetup. [[User:Tantek|Tantek]] 04:09, 21 January 2015 (UTC)
</div>

=== implied properties when an explicit class is provided ===
<div class="discussion">
Should "u-url" still be implied if another explicit class is already provided, as below. This is a contrived example, but it is taken from Bridgy's unit tests.

<code><pre>
<article class="h-entry">
<a class="u-like-of" href="http://orig.domain/baz">liked this</a>
</article>
</pre></code>

In this case, http://orig.domain/baz is almost certainly not the u-url, so IMO it would be better to leave it out —[[User:Kylewm|Kylewm]] 15:10, 7 October 2014 (UTC)

'''2015-01-20 consensus'''
* Changed my mind. Simpler to do nothing. Example provided is artificially constructed, does not reflect likely real world confusion of if we make implied properties more complicated. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
* ++ Consensus on do nothing for this case. At [[2015-01-20]]

'''Proposed resolution:'''
* Changed again. Due to indiewebcamp.com/edit use-case, this now makes sense for all implied properties. That is:
** If an element has any explicit property class name(s) on it, then it must not be used to imply any properties. [[User:Tantek|Tantek]] 20:50, 27 May 2015 (UTC)

</div>

=== link elements and u- parsing ===
Status: resolved, awaiting implementation attempt/experience.

<div class="discussion">
* Raised by tantek on 2014-07-08 on [http://logs.glob.uno/?c=freenode%23microformats&s=8+Jul+2014&e=9+Jul+2014#c72916 irc]: should the parsing specification for handling u- properties be modified to include the <code>link</code> element? The potential downside is that [[invisible-metadata-is-considered-harmful]], however all known real world examples of <code>link</code> are <em>semi-</em>visible data (not fully hidden).

There are potential cases for wanting to use link as an alternative to <code>a</code> (and <code>area</code>), such as a whole page where the root <code>html</code> element is an <code>h-card</code> and the properties are included across the page: some in visible data in the <code>body</code> while others are in the <code>head</code> as <code>link</code> elements. Example:

One specific use-case is the semi-visible <code>link rel="shortcut icon" href="..."</code> - which is visible sometimes in browser UI, and also when a user chooses "Add to Home Screen" on a mobile device. Such page level icons may be used as a <code>u-photo</code> or <code>u-logo</code> of the containing <code>h-*</code> object on the <code>html</code> element.
* http://adactio.com/about/myself/ on 2014-190
** <em>could</em> use <code><html class=h-card></code> - page is all about Jeremy Keith the person
** <em>icon / logo is only</em> on <code><link></code> tag which <em>could</em> use <code>class=u-logo</code>: <br/><code><link rel="shortcut icon apple-touch-icon" type="image/png" href="/icon.png" /></code>

Another specific use-case is a post permalink page, e.g. with <code><html class=h-entry></code>
* http://waterpigs.co.uk/notes/4WjHpC/
** <em>has</em> <code><html class="no-js h-entry hentry h-as-note" lang="en"></code>

Another use-case is publishing links to PGP/GPG keys linked from the head which is currently handled by <code><link rel=pgpkey></code> which is already supported in existing [[microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats|microformats2 rel parsing]] of <code>link rel</code> elements. Thus there is a (admittedly weak) argument for consistently parsing <em>both</em> <code><link rel></code> <em>and</em> <code><link class="u-*"></code>.

E.g. inside that aforementioned real world <code><html class=h-entry></code> post permalink page example,
* why should <code><link rel="in-reply-to"></code> work
* but not <code><link class="u-in-reply-to"></code> ?
The slightly stronger argument for consistency of link handling is that it <strong>[[simpler|simplifies]]</strong> the publisher (and parser) model:
* <code><a></code> and <code><area></code> work for both <code>rel</code> and <code>class</code>
* why does <code><link></code> only work for <code>rel</code> ?
* it would be <em>simpler</em> if all three tags just worked (in the same way) for both <code>rel</code> and <code>class</code>

'''Should the parsing spec be modified to handle these cases?''' —[[User:TomMorris|Tom Morris]] 09:25, 9 July 2014 (UTC)

** I'm generally in favour. It'd be good to see what other parser developers think. —[[User:TomMorris|Tom Morris]] 10:16, 9 July 2014 (UTC)
** adding this to the parsers won't be an issue. <del datetime="2014-07-09T18:45">The question is should the door be opened to hidden mf data?</del> <ins datetime="2014-07-09T18:45">Up on further reflection, there seems to be no need to distinguish between <code>rel=property</code> and <code>class=u-property</code> on link elements. So I am in favour for consistency.</ins> [[User:KP|Kartik]] 18:30, 2014-07-09 (EST)
** RESOLVED at [[2015-01-20]] meetup. Make link consistent with a.
</div>

=== e- parsing iframe srcdoc ===
<div class="discussion">
* Proposal: addition of a new e-* parsing rule for iframe elements with srcdoc attributes. E.G.

<source lang="html4strict">
<div class="h-entry">
<iframe class="e-content" srcdoc="<p>A paragraph of HTML with "quoted quotes" &amp; doubly quoted ampersands</p>" />
</div>
</source>
<source lang="javascript">
{
"items": [{
"type": ["h-entry"],
"properties": {
"content": ["<p>A paragraph of HTML with "quoted quotes" & doubly quoted ampersands</p>"]
}
}]
}
</source>

This would allow, for example, HTML comments to be sandboxed inside iframes but still parsable as microformats.

I believe the correct processing would be to leave " entities as they are but to unescape any doubly-escaped ampersands.

** Is there any use case for that? —[[User:TomMorris|Tom Morris]] 12:32, 14 September 2013 (UTC)
** +1 we need documentation of use case and existing sites publishing iframe srcdoc like this - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
** Rejected by consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 properties on select ===
How should select elements with properties be treated any differently?

Awaiting real world examples / stronger use-cases, until then no special treatment of select elements with properties:
<div class="discussion">
* Are there any real world examples of select elements with microformats properties?
* What would the use-case be for putting a microformats property class name on a select element?
* Nothing special. By consensus at [[2015-01-20]] meetup due to lack of real world uses cases / existing sites. [[User:Tantek|Tantek]] 06:26, 21 January 2015 (UTC)
</div>

=== How to interpret mf2 root name on form ===
See what to do about <em>root class names</em> on <code><form></code> elements in particular:
* [[hcard-input]]

Awaiting real world examples / stronger use-cases, until then, no special treatment of root class names on <code><form></code> elements:
<div class="discussion">
* Are there any real world examples of a <code><form></code> element with a microformats root class name?
* [[hcard-input]] is one possible use-case, is anyone attempting to use forms for hCard input, e.g. with scripts to help make it work?
* Are there other use-cases for putting a microformats root class name on a <code><form></code> element?
* As of [[2015-01-20]] - no consensus - need more input as to when/why this is useful to do anything special.
</div>

===Parsing Literal Values===
Issue raised by: [[User:BenWard|Ben Ward]]

It is proposed for microformats2 that all microformats be parsable from just their root element, e.g. <code><p class="h-card">Ben Ward</p></code> would create an hCard with the following properties after parsing:

<source lang=javascript>
{
'type': ['h-card'],
'properties': {
'name': ['Ben Ward']
}
}
</source>

This is a four-fold change from the current [[hCard]]:
# type is generically identifiable as a microformat root, even in parsed form. The use of the 'h-' prefix persists into the type of the object. This is deliberately so, as a result of re-using the JSON data model of microdata which itself is re-using a common JSON convention, such that microformatted data is clearly distinguishable (as opposed to any other random schema that may be using a similar data model).
# root-class-only support. Per [[microformats-2-implied-properties]], the ''name'' property is implied by the entirety of the root class name element.
# 'name' instead of 'fn'. As also documented in [[microformats-2-implied-properties]], the continuous challenges/problems and need to repeatedly re-explain 'fn' over the years combined with the real-world market response of nearly every other party doing a person vocabulary renaming 'fn' to 'name', microformats 2 makes this change as well.
# There is no automatic parse-time inferring of <code>'given-name': ['Ben']</code> and <code>'family-name': ['Ward']</code>. Any such inferring *might* be made by a vCard converter, but is left up to that specific application (not all applications) built on that vocabulary, though even in that case it may not be necessary, as an empty "N:;;;" [[vCard]] property is sufficient to satisfy the N property requirement of [[vCard]], and also causes no problems when imported into various [[vcard-implementations]].

It is required of the extractor to understand that when a microformats object specifies no explicit child properties, that it must treat <code>h-card</code> as having a <code>p-name</code>. But, the parser is generic, so it also treats <code>h-review</code>, <code>h-entry</code>, <code>h-recipe</code>, <code>h-geo</code> as having a ‘<code>p-name</code>’.

As a result, specific vocabularies are evolved to drop their specific form of name (e.g. fn, summary, entry-title) and simplified to use a common 'name' property instead.

Note: while the overwhelming majority of real world publishing/consuming uses of microformats do so with proper nouns which have names (and thus this parser-level incorporation of an implied 'name'), there are some formats that do not have a 'name' semantic. For example, [[geo]], [[adr]], and possibly if/when developed, units of measure, length, cost. The current thinking is that the benefits to the far greater proper-noun use-case of microformats outweigh the technical inelegance of having an extra/ignored 'name' property on formats that lack such a semantic.

Some formats also may appear in theory to better imply some other property, e.g. a review might be thought to imply its ''content'', not its name, and an Atom entry its ''content'', not its title, but in practice (actual publishing patterns) this is not the case. Typically, brief unstructured reviews (or mentions thereof) provide a ''summary'' (often hyperlinked to an expanded structured form) of that review, not its content, and similarly, brief unstructured posts (e.g. RSS items) have historically most often been link blog items which include the title of an item and a link. Short status updates as well established by Twitter are newer and would seem to imply purely content with no title, at least semantically, however, even Twitter populates the RSS title and ATOM entry title of their feeds with the content. It's not clear what went into that decision, however, that's likely irrelevant, as the outcome turns out to be emergent consistency among publishing behaviors.

To avoid overloading or undermining the semantics of a vocabulary, I propose that we handle this at the extractor level in a simpler fashion: Define a new property for literal data, that an extractor will provide if no other information was available. All ''interpreters'' may then be instructed that in the event that an object has no properties, it can attempt to interpret the literal value from the page instead.

* This was one of the design iterations I went through which led me to the current implied 'name' design. Another iteration was the ability for a vocabulary to specify a single required property which was implied if there were no properties provided. However, the combination of the fact that in most cases such single required properties were quite name-like, and that a vocabulary-specific rule like that would then bind parsers to specific vocabularies (even so slightly) led me to collapse them into implying a 'name'. It's not perfect, but it's the best alternative so far that balances practical convenience of publishing/consuming, avoids vocabulary-specific knowledge in the parser, and technical (in)elegance. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

In existing microformats, the closest existing example we have for this is the <code>label</code> property in hCard, which is used to represent the literal address label for a place. It is a corresponding piece of <code>fn</code>, <code>org</code> and <code>adr</code> in combination, but has no structure in and of itself. Possibly, every microformat could have a <code>label</code> form where structured data is unavailable.

However in practice, the hCard <code>label</code> property is both little understood and little used. It's not even clear that it ought to be kept for microformats 2 (no known consumers, very few (if any?) real-world non-test publishers). This disuse is likely a good indicator that we should avoid basing anything on its design.

Alternatively, <code>value</code> is used throughout microformats to target a generic value (e.g. in combination with <code>price</code> in hListing.) It has been proposed that when parsing properties that are also themselves microformats, we create native objects of the form:

{
'value': '1900 12th Street, San Francisco, CA 94'
, 'type': ['h-adr']
, 'properties': {
'street-address': '1900 12th Street'
, 'etc': 'etc'
}
}

We could apply this same pattern to the root level:

{
type: [h-card]
, properties: {}
, value: 'Ben Ward'
}

In this case, an interpreter or implementation is responsible for using <code>value</code> in place of <code>fn</code>, or restructuring the object. It would be the responsibility of each vocabulary to define its root property. The parsing layer of microformats 2.0 would not impose semantics or naming onto that.

For another example, h-geo would end up like this:

{
type: [h-geo]
, properties: {}
, value: '1.3232;-0.543'
}

* This is an alternative I've been considering as well: [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)
** 'value' is more generic than 'name' (applies to more vocabularies) with the trade-off that it naturally has less (weaker) semantics.
*** +1 I think that having naturally weaker semantics would be appropriate for this parsing functionality. —[[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC)
** The interesting thing that this analysis has revealed is that there appear to be two distinct clusters of microformats, the much more commonly used/understood/useful proper-noun microformats which markup things with names (people, events, reviews, recipes), and the less used compound-data microformats which are often used ''inside'' other microformats and just have some sort of semi-structured value (adr, geo, measure, and perhaps even things like tel). Perhaps this is implying the possibility and some degree of utility for ''two'' microformats root class name prefixes, 'h-' for existing proper-noun microformats, and something else ('m-' for microformat/molecule?, 's-' for structured-value?, 'v-' for value (though historically "v-"/"v." has meant "vendor-specific")?) for unnamed structured data microformats.
*** This more and more feels like a good idea, and I'm leaning toward "s-" for struct / structure / structured value. "s-" works just like "h-" except that it doesn't imply any properties at parse time. We can try it and see what happens. There's also no harm if publishers just use "h-" structures, they just (possibly) get a few extra properties if they happen to omit properties.
** Parallels the same JSON when a property has both a string value ''and'' is a structure itself.
*** Changed my mind on this. The parallel is not quite there. 'name'/'url'/'photo' are only implied if there are NO properties, where as the JSON string value + structure convention *always* provides a 'value'. [[User:Tantek|Tantek]] 22:39, 4 October 2011 (UTC)
*** And due to this difference in behavior ('value' is there when nested properties are present, whereas 'name' is only implied when there are no properties specified), I think it's correct to keep them separate, i.e. stick with implied 'name'. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
** However, I'm still currently leaning towards the practical convenience of providing a 'name' for the vast majority of microformats uses, rather than diluting this feature for the sake of avoiding implying inapplicable semantics to the few plain structured data microformats, and even then, only when no properties are explicitly specified! I'd rather introduce a new root prefix for those than lose the simplicity and utility of implied 'name'. [[User:Tantek|Tantek]] 13:48, 4 October 2011 (UTC)

== resolved ==
=== When to collapse whitespace in properties ===

The spec doesn’t explicitly require whitespace to be collapsed or not. The official mf2 test suite requires it to be collapsed.

Reasons why whitespace ''shouldn’t'' be collapsed:
* Plaintext property representations of syntax-highlighted code, poetry and song lyrics require whitespace to be present
* Whether or not whitespace is an important part of the content being parsed is determined by css white-space and CANNOT be inferred from HTML markup alone

Resolution 2013-11-12: Agreed, whitespace should not be collapsed (other than normal HTML5 parsing rules). The spec now refers to "textContent" rather than "innertext" to make this explicit.

=== How to interpret mf2 classnames on form inputs ===
E.G. how to parse:

<source lang=html4strict>
<input class="u-url" value="https://brennannovak.com/notes/338" />
</source>

Examples in the wild: https://brennannovak.com/notes/338

See proposal:
* [[hcard-parsing-brainstorming#input_element_handling]]

Resolution 2013-11-12: Per that proposal, p- u- dt- properties on input[value] elements now use the value attribute.

=== mixture of microformats2 and classic microformats classnames on different elements ===
Some sites in the wild have mistakenly combined classic mf and mf2 markup in ways which misrepresent the content if parsed in BC mode.

Typically this is caused by putting classic and mf2 classnames for the same vocabulary on different elements, e.g:

<source lang="html4strict">
<body class="hentry">
<article class="h-entry">
<h1 class="p-name"></h1>
</article>
</body>
</source>

Sites where this has been observed:
* http://acegiak.machinespirit.net/2013/10/17/barnaby-walters-notes-another-thing-i-love-about-the-web-users-have-the-power-to-take-control-of-their-uis-and-improve-their-own-experiences-aside-drm-for-html-would-prevent-this-from-being-possibl/
* http://shawfactor.com/2013/08/06/thoughts-on-extending-webmentions/ (fixed)
* http://notizblog.org/2013/06/18/the-rise-of-the-indieweb/ (fixed)

Discussion:

* As far as I can tell, the problems in all of these examples were caused by mf2 markup being injected by a wordpress plugin, but classic mf classnames being present further up the DOM in the themes. When parsed in compatibility mode, the classic mf classnames are transformed into mf2 classnames, making the original mf2 classnames look like children of empty items.
* Turns out this isn’t theme-specific, WordPress injects hentry via PHP [http://indiewebcamp.com/irc/2013-10-22/line/1382448759]. The bug with the wordpress mf2 plugin is resolved as of [http://indiewebcamp.com/irc/2013-10-22/line/1382449035 2013-10-22] --[[User:Barnabywalters|bw]] 13:38, 22 October 2013 (UTC)

=== e- and p- escaping levels ===
<div class="discussion">
* The fact that the parsed value of any element with .e-* is at a different level of escaping to the parsed values of p-*, dt-* etc. without any indication of how the property was parsed in the output is a security problem. For example:

<table style="width: 100%">
<tr>
<th>input</th>
<th>output</th>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="p-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
<tr>
<td><source lang=html4strict>
<p class="h-card">
<span class="e-name"><tag></span>
</p>
</source></td>
<td><source lang=javascript>
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"<tag>"
]
}
}
]
}
</source></td>
</tr>
</table>

* As a parser developer, the most straightforward way I can think of solving this is to add an option (enabled by default) which encodes HTML special characters on all non e-* properties, so the developer knows that all property values are going to be at the same level of escaping. --[[User:Barnabywalters|bw]] 20:00, 15 June 2013 (UTC)
** Your suggestion of auto-HTML-encoding p-*/u-*/dt-* property values is the most sensible I think. I would NOT make it an option, as it makes sense write consistent microformats2 consumers. - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
** Can you think of any existing apps/consumers of microformats2 via the parser that would break? What would indieweb comments parsers do? - [[User:Tantek|Tantek]] 07:18, 5 July 2013 (UTC)
*** The only breakage which might occur would be over-encoding of non e-* properties, but I’ll release this update as v0.2.0 and warn people about the changes. The worst thing which could happen is that some comments look a bit weird, as opposed to the current worst possible scenario of easy XSS attacks --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** We should also decide exactly which characters get encoded — just angle brackets, or quotes/ampersands as well? --[[User:Barnabywalters|bw]] 12:55, 5 July 2013 (UTC)
*** I am not sure about this, it seems more like a helper function rather than a core feature of the parser. Personally I would like to store data as text and encode only when I am going to use and I known the format it is going to be use in. --[[User:GlennJones|Glenn Jones]] 9:54, 14 July 2013 (UTC)
***After the discussion on the indiewebcamp IRC with Barnaby Walters I now understand the XSS issue that this change is trying to address. A rogue author could include HTML with scripts to execute a XSS attack. These could be masked by switch prefixes i.e. p-* to e-* on a well use property. As the consumer does not see the prefix in the JSON output they have no idea if a property will content HTML or text. I will update my two parsers and the test suite --[[User:GlennJones|Glenn Jones]] 8:02, 17 July 2013 (UTC)
**So what about an author setting a property to e-* when it would normal be p-*, dt-* or u-* i.e.
<source lang=html4strict>
<div class="h-card"><p class="e-name"><script> alert('xss test') </script></p></div>
</source>
** per [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]], parsers should never automatically attempt to HTML-special-characters encode - as that would provide the client of the parser a false sense of security. It's *always* up to client code to escape any text being output to HTML *at the moment it is output to HTML* and never before, because they can never trust that any text from storage/elsewhere has for sure been escaped or not. - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** Should we not encode e-* as well and the consumer can decode at their own risk --[[User:GlennJones|Glenn Jones]] 18:42, 21 July 2013 (UTC)
*** No, never, per above point from [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
** See [[events/2013-09-14-microformats2-parsing|microformats2 parsing discussion 2013-09-14]] etherpad: https://etherpad.mozilla.org/microformats2parsing for more details on the resolution to this issue - and incorporate here (then move to resolved section below). - [[User:Tantek|Tantek]] 18:07, 17 October 2013 (UTC)
* Resolved by changes to the parsing spec: all properties are plaintext (non-HTML escaped), e-* properties result in a dictionary with <code>value</code> = plaintext version, <code>html</code> = raw HTML version
----

</div>

=== br hr empty string ===
<div class="discussion">
* The parsing rule 'else if br.p-x or hr.p-x, then return "" (empty string)' for p-* can cause any code consuming the API to become quite bloated. It means that you have test every array value to see if its an empty string. It is also unclear to me what the purpose of this mark-up pattern is for [[User:GlennJones|Glenn Jones]]
** Upon reconsidering this, I agree with you, this is an unlikely use case. If a publisher wants to explicitly set an empty property "p-foo" they can simply write <code><span class="p-foo"></span></code> which looks explicit. Whereas BR and HR tags are often just presentational, so we should both not encourage usage of them for semantics, and anyone that did use them would be subject to likely loss of semantics upon a redesign (that got rid of those particular BR and HR tags). I'm going to remove them from the parsing spec. - [[User:Tantek|Tantek]] 15:29, 10 February 2013 (UTC)
</div>

=== datetime examples without T delimiter ===
<div class="discussion">
* The examples in the wiki microformats-2 pages such h-entry and h-entry had datetime without the 'T' delimiter between date and time. ie
<source lang="html4strict">
<time class="dt-published" datetime="2013-06-13 12:00:00">13<sup>th</sup> June 2013</time>
</source>
I have updated the pages. As far as I known this is a new pattern for dates. Was it a mistake in the examples or is it a new datetime pattern.
** The [[HTML5]] "time" element, and "datetime" attribute allow for space <span style="white-space:nowrap">" "</span> as a separator between date and time as well as "T", thus we allow it for microformats as well. The <span style="white-space:nowrap">" "</span> separator is preferred as the date and time are more readable when separated by a space. The examples noted in those specs deliberately use this. - [[User:Tantek|Tantek]] 18:48, 15 July 2013 (UTC)
</div>

=== rel-alternate absent optional attributes ===
<div class="discussion">
* What should rel-alternate parsing do when one of the optional attributes specified (<kbd>hreflang</kbd> or <kbd>media</kbd> or both) is not there? The options seem to be:
*# leave the corresponding key out of the alternate JSON object
*#* This one. Leave the corresponding key out.
*# include the corresponding key in the alternate JSON object, but set the value to the JSON null object
*# include the corresponding key in the alternate JSON object, but set the value to a blank string
*# something I haven't thought of

I haven't checked the existing implementations, but Barnaby said he's not sure what the appropriate way to deal with it is either. —[[User:TomMorris|Tom Morris]] 15:41, 9 August 2013 (UTC)
</div>

=== rel-alternate and type attribute ===
<div class="discussion">
* Should rel-alternate parsing also pick up the <code>type</code> attribute? It’s fairly widely used, e.g. for ATOM feeds.
** Numerous existing sites/pages have various [[rel-alternate]] uses with a type attribute for feeds/APIs so that's good enough to add this for help with discovery in general. Rel parsing updated. - [[User:Tantek|Tantek]] 00:47, 15 September 2013 (UTC)
</div>

=== Extraction vs Interpretation ===
Issue raised by: [[User:BenWard|Ben Ward]]

A microformats ‘1.0’ parser performs the following function:

* Given a piece of HTML content, discover a known microformat, extract it, apply various extraction patterns based upon the HTML mark-up used (e.g. include pattern, <code>abbr</code> patterns, date-time patterns, value-title pattern), apply various content optimisations where applicable, and return the result in an object native to the programming language.

This is performing two types of function: Extraction of data from an HTML document or fragment, ''and'' interpretation and optimisation of that content to match the rules set out by a vocabulary specification.

It is only possible to write a generic parser that covers the first half of this task: Extraction, and application of global rules based on HTML elements and patterns common to all formats.

The purpose of a generic parser (as supported by use cases such as search engines, and other crawlers) is:

To provide a way for tools to extract rich data from a page for native storage, such that the data may be interpreted later by applications. This allows microformats to be crawled, and indexed, and removes the need to include complex HTML parsing within every implementation of microformat data.

Microformats will continue to define various vocabulary-specific optimisations. as part of the design to be optimised for authors. For example: The <code>fn</code> pattern in [[hcard]], or the <code>lat;long</code> pattern in [[geo]], as well as default values for properties, such as the maximum rating in an [[hreview]].
* Actually, no, as it is defined currently, microformats 2 ''drops'' vocabulary-specific optimizations. Such optimizations have often been too inapplicable, error prone or i18n-unsafe (e.g. fn to given-name + family-name fails for both numerous cases where middlenames/initials are used, and in general in numerous Asian languages where given/family name order is the reverse of Western English conventions, or languages with multiple family-names, e.g. Spanish - see [[hcard-issues-resolved]] for more). This is a deliberate cutting of a "feature" from microformats 1, it is a deliberate model simplification design decision. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

==== Extraction resolution ====
Proposed resolution:

Microformats2 should refer only to ''extraction'' of microformats. Vocabularies should in turn document their appropriate optimisations, which will need to be applied by implementations, or a companion to an extractor, which I'll refer to here as an ‘interpreter’.
* Vocabularies will no longer have optimizations, this is again deliberately, as they've been shown to be more error prone than helpful. Thus there should be no need for any vocabulary-specific 'interpreters'. However, due to design quirks in various legacy/interchange formats, ''export conversions algorithms'' to those legacy/interchange formats will require some additional legacy-format-specific rules (e.g. odd "required" rules in [[Atom]] or [[vCard]] will require specific synthesis rules, limitations in said formats will require filtering of some values, e.g. [[vcard3]] BDAY disallows vague birthdays like year-month and --month-day - subsequently allowed in [[vcard4]]). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

A microformats2 ‘extractor’, in combination with the functionality of a domain and format-aware ‘interpreter’ (either another shared component, or part of the implementation itself) would be equivalent to a microformats 1.0 ‘parser.’
* A microformats2 parser is both generic (no knowledge of specific vocabularies), and lacks any/all such vocabulary-specific rules as compared to a microformats 1.0 [[hcard-parsing|parser]] with the exception of a 1) a limited list of well-established/interoperable backward compat root class names (of current [[microformats]] that are or can be soon shown to be specifications/standards per the [[process]]), 2) flat sets of backward compat property names (some with prefix/name specific conversion) for each of those backward compat root class names. This is a deliberate design decision that makes microformats 2 more "micro", and yes this means that even with such backward compat support, this simple form of backward compat may mean that some existing microformats 1 content breaks. We'll assess those and iterate on a documented case-by-case basis rather than attempt to maintain theoretical 100% backward compatibility (since many current microformats format-specific-features are either unused, or may have caused more problems than solutions). [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

N.B. I'll rewrite some of these as [[microformats2-parsing-faq]] to help better clarify. The reasoning that led to most of these design decisions is documented in the [[microformats-2#About_This_Brainstorm|microformats 2: About This Brainstorm]] section and following sections. I'll recheck those sections to see if/where reasoning for some of the above noted design decisions may have been missed, and back-fill accordingly. This is necessary because [[microformats2]] is a evolutionary result of simultaneously addressing both numerous generic [[issues]] as well as various common [[hcard-issues-resolved|format]]-[[hcalendar-issues-resolved|specific]] [[mfo|problems]] in microformats1 syntax and vocabularies. The very number of changes may make it more challenging (from a microformats1 perspective) to see why any particular design change has been made. [[User:Tantek|Tantek]] 12:43, 4 October 2011 (UTC)

This issue can be moved from resolved to closed once the above-mentioned write-ups have occurred.

===Parsing properties from rel attributes===
tl;dr resolution: As of 2013, [[microformats2-parsing]] handles parsing all link and a href rel values at document scope level, and producing canonical JSON accordingly. - [[User:Tantek|Tantek]]

Issue raised by [[User:BenWard|BenWard]] 07:24, 5 October 2011 (UTC):

* Currently, hAtom parses `bookmark` as a permalink
* Various microformats parse `rel=tag` as tags
* The current proposal for parsing does not allow parsing properties from rel attributes.

Microformats parsers could instead extract ''all'' link relationships from rel attributes within an microformat object, parsing them as if a u- prefixed property.
* Minor nit: Rather than same as a u- prefixed property, I think such "rel" properties should be parsed purely from the <code>href</code> attribute on <code><a></code> and <code><area></code> elements and nothing more. I would strongly disagree to extending rel to apply to other elements with URLs like img src, object data, or to apply to elements in general like div. That's the path that RDFa has taken and caused much confusion as a result. [[User:Tantek|Tantek]] 07:39, 5 October 2011 (UTC)
** Agree: That seems like a perfectly reasonable restriction. --[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)

This results in:

* Continuing use of the <code>rel</code> attribute in HTML, thereby building on HTML semantics rather than bypassing them or ignoring them in favour of something less meaningful.
* Parsing hAtom objects contain a property named <code>bookmark</code>, in place of <code>permalink</code>.
* All microformats that use <code>rel-tag</code> would contain a property named… <code>tag</code>. Perfect.

Since <code>rel</code> attributes are not overloaded for other functionality like class is, and other uses of <code>rel</code> within content are low (and non-semantic uses are nil, to the best of my knowledge) the risk of property pollution would be extremely low.

Note, with regard to this last point, that a generic microformats parser ''will'' parse false-positive properties, and ''will'' parse objects in combined chunks, rather than individually by format. Extracted objects will often not represent a vocabulary without further processing.

<div class="discussion">
* This sounds like it might be workable. Let's try it and see how well authors "get it". - [[User:Tantek|Tantek]]
* Possible issue: do we have any collisions between class property names and rel names? (I don't think so offhand, but useful to ask the question). - [[User:Tantek|Tantek]]
** None that I can think of in microformats. There is the case of Google's <code>rel=author</code> and <code>p-author</code> in hAtom. However, the next point, about mfo scoping, would cover it in most situations (rel-author on a hyperlink within an hcard wouldn't be applied to the hentry.) The one situation in a parse tree where it's ambiguous would be this:
<source lang=html4strict>
<a href="p-author h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
** I can think of two quite reasonable solutions:
*** 1. Declare that class properties take precedence over rel properties of the same name, discarding rel values if a class is also found, or
*** 2. Since all properties are now multi-value anyway, the hAtom object could be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
** —[[User:BenWard|BenWard]] 08:29, 5 October 2011 (UTC)
*** Option 2 makes sense and is consistent with the rest of the multi-value parsing/handling. - [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
*** What about without the 'p-author'?
<source lang=html4strict>
<a href="h-card"
rel="author"
href="http://benward.me">
Ben Ward
</a>
</source>
Should that be parsed as:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
'http://benward.me' /* from the rel="author" */
],
…
}
}
</source>
Or
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': 'http://benward.me' /* from the rel="author" */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},

],
…
}
}
</source>
*** And if the former, then we're presumably saying that the value parsed due to the presence of a rel is always its own value, and does not combine with any other structures. I am fine with this, but I wanted to make sure we are ok with that explicitly. [[User:Tantek|Tantek]] 14:56, 5 October 2011 (UTC)
**** +1 I think that since the rel attribute is specifically concerned with the relation to an href attribute, it should not be combined with other structures that are rightly declared uses classes.
***** The more I've thought about this and how consuming applications may want to treat rel semantics, the more it seems correct to keep rel semantics distinct from class semantics. Class semantics are quite general/flexible, whereas rel is quite specific, naming something else in terms of a relationship from the current page/microformat's perspective. I think we should consider putting rel values in their own 'rel' collection, separate from the 'properties' collection. E.g. the original rel-author p-author h-card markup example would be parsed into this:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from the p-author */
'type': ['h-card'], /* from the h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
}
],
…
}
'rel': {
'author': ['http://benward.me'] /* from the rel="author" */
}
}
</source>
***** and if a post had multiple authors:
<source lang=javascript>
{
'type': ['h-entry'],
'properties': {
…
'author': [
{
'value': ['Ben Ward'], /* from p-author */
'type': ['h-card'], /* from h-card ... */
'properties': {
'name': ['Ben Ward'],
'url': ['http://benward.me']
},
{
'value': ['Tantek Çelik'], /* from 2nd p-author */
'type': ['h-card'], /* from 2nd h-card ... */
'properties': {
'name': ['Tantek Çelik'],
'url': ['http://tantek.com']
},
],
…
}
'rel': {
'author': [
'http://benward.me', /* from rel="author" */
'http://tantek.com' /* from 2nd rel="author" */
]
}
}
</source>
***** This preserves the semantic distinction between rel and properties in general, and leaves it up to a higher-level application to implement any logic around showing "more info" about a rel-author, e.g. by correlating the rel-author URL with the 'url' of an hCard it found in the same entry. However, note that even in the earlier JSON data model, the rel-author value just shows up as another property value, and any higher level application would still have to do some correlation logic. At least with this JSON data model, applications that may be looking for a rel value in particular, or a property value in particular can do so without having one unintentionally pollute the other. [[User:Tantek|Tantek]] 17:33, 6 October 2011 (UTC)

* Presumably we'd apply all the same property scoping rules to rel scoping as well. E.g. a rel hyperlink inside a microformat won't be seen by any containing microformat. - [[User:Tantek|Tantek]]
** Correct, it should be parsed in the same scope as all other class properties in the object.
*** Update: all rel microformats are now parsed at page-scope. Per-microformat scoping of rel has been found to be too confusing in practice (and against the general semantic of rel expressed in the HTML/HTML5 specs) [[User:Tantek|Tantek]] 01:00, 10 July 2014 (UTC)

This issue can be moved from resolved to closed once we've verified that all the above-mentioned and implied needs to write things up have occurred.
</div>

== see also ==
* [[microformats2-parsing]]
* [[microformats2]]