author backcompat: always vcard?

[sknebel]

http://microformats.org/wiki/h-entry#Parser_Compatibility says

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:

  <article class="hentry">
    <span class="author">Tom Morris</span>
    [....]
  </article>

parses as

{
  "type": ["h-entry"],
  "properties":  {
    "author": [{
      "type": ["h-card"], 
      "properties": { }, 
      "value": "Tom Morris"
    }]
…

Is this understanding correct?

IMHO a preferable result would be

{
  "type": ["h-entry"],
  "properties":  {
    "author": ["Tom Morris"]
…

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.

[tantek]

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).

(Originally published at: http://tantek.com/2018/358/t1/)