You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
author - including compat root vcard in the absence of h-card
I interpret this as "parse as if there was a vcard class on the author, even if there isn't", which during parsing then gets converted to an h-card. This produces a suboptimal result when the author property is only a string: the assumed vcard then has no properties (since implied name doesn't exist in mf1), resulting in a case like this:
which would result if the author property were just parsed as a p- property: If there's a nested vcard, it gets parsed and converted, otherwise it just parses to a string.
The text was updated successfully, but these errors were encountered:
This is a misintepretation of the backcompat portion of the spec.
Everything in the compat rules means “look for”.
In this case, “author - including compat root vcard in the absence of h-card” means to look for an “author” class name, including looking for a “vcard” class name on the same element, only if there is no “h-card” class name on the same element.
Thus yes, according to the spec, the code snippet:
<span class="author">Tom Morris</span>
Inside an hentry as noted above must be treated like:
<span class="p-author">Tom Morris</span>
And thus in the parsed JSON it becomes a simple "author": ["Tom Morris"] as noted as a “preferable result”.
If you can suggest wording that would help clarify this in the spec, I would be happy to make an editorial change to make this more explicitly clear (as well as similar for h-event location).
http://microformats.org/wiki/h-entry#Parser_Compatibility says
I interpret this as "parse as if there was a vcard class on the author, even if there isn't", which during parsing then gets converted to an h-card. This produces a suboptimal result when the author property is only a string: the assumed vcard then has no properties (since implied name doesn't exist in mf1), resulting in a case like this:
parses as
Is this understanding correct?
IMHO a preferable result would be
which would result if the author property were just parsed as a
p-
property: If there's a nested vcard, it gets parsed and converted, otherwise it just parses to a string.The text was updated successfully, but these errors were encountered: