metaformats-brainstorming

From Microformats Wiki
Revision as of 22:33, 4 April 2022 by Tantek (talk | contribs) (→‎other meta uses to consider: HTML spec meta names, for any that are rejected due lack of implementations, file bugs to deprecate/drop from the HTML Standard)
Jump to navigation Jump to search

This page is for documenting brainstorming related to the metaformats.

Prior documentation and blog posts

Some of this should go into a non-normative references section in metaformats.

Which HTML tags

See https://html.spec.whatwg.org/#metadata-content for tags to consider.

meta

The meta, obviously, for Open Graph Protocol and Twitter Cards at least. Are there any others?

  • Only in the head?
  • Or should we specify how to parse meta tags in the body as well?
    • Do any existing consuming code (that supports meta in the head) do anything with meta tags in the body?

Which attributes on meta

name

The HTML specification defines the meta name attribute: https://html.spec.whatwg.org/#attr-meta-name

If a meta element has a name attribute, it sets document metadata.

This implies that absent a name attribute, a meta element does not set document metadata. Thus if microformats are to support parsing metadata from meta elements in a manner compatible with what HTML requires, microformats must use the name attribute.

Document metadata is expressed in terms of name-value pairs, the name attribute on the meta element giving the name … The name specifies what aspect of metadata is being set; …

Since microformats has the similar model of name/value pairs in the form of properties and values, microformats should use the name attribute to express property semantics to follow this portion of the HTML specification.

As a fallback, should microformats also allow using the class attribute on meta tags? Or at least specify what should happen if it is present? Explored in the class attribute section below.

content

The HTML specification defines the meta content attribute: https://html.spec.whatwg.org/#attr-meta-content

Document metadata is expressed in terms of name-value pairs, … the content attribute on the same element giving the value. … valid names and the meaning of their values are described in the following sections. If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

property

Only for backcompat with Open Graph Protocol.

class

The meta tag does support the class attribute, but should we use it?

In short:

  • Since HTML already uses the 'name' attribute for property names, we should not recommend using another attribute.
  • Since a publisher might use the class attribute anyway like they would for other elements, we should define what it does in a predictable way.

Proposal:

  • Using the 'class' attribute should override any property specified via the 'name' attribute, because:
    • 'class' is the primary attribute used for microformats2
    • to override backcompat rules for specific 'name' or 'property' values
    • to unambiguously override if both a 'name' and 'property' value is set
    • to set additional properties from a single meta content value
  • Thus only do 'name' and 'property' backcompat parsing in the absence of microformats2 properties in the 'class' attribute.


In the algorithm sections:

in "parsing a p- property", insert before "else return the textContent of the element after …"

  • else if meta.p-x[content], then return the content attribute

in "parsing a u- property", insert before "else return the textContent of the element after …"

  • else if meta.u-x[content], then get the content attribute

in "parsing a dt- property", insert before "else return the textContent of the element after …"

  • else if meta.dt-x[content], then return the content attribute

no changes for "parsing an e- property", since it has no special parsing considerations on other empty elements like data.

How to parse meta root class names

Without any explicit use-cases for using a meta element as a microformats root element, there is no need to specify any special parsing considerations for microformats root class names on meta elements.

How to imply backcompat root classes from meta elements

As informed by https://david.shanske.com/2022/03/14/meta-tags-to-microformats/ for details of which backcompat root classes:

  • If there are no root class name(s) found on the html or head elements, then
    • parse meta elements for backcompat properties
    • if meta[property=og:type] then
      • get its content attribute value
      • if it’s "article" then imply a head element root class name of h-entry
      • if it’s "profile" then imply a head element root class name of h-card
      • if it's "music" or "video" then imply a head element root class name of h-cite
    • end if
    • if there is no implied head element root class name and meta[name=twitter:card] then
      • if it's "summary" or "summary_large_image" then imply a head element root class name of h-entry
    • end if
    • if there is no implied head element root class name and
      • meta[property^=og:] or meta[name^=twitter:]
    • then imply a head element root class name of h-entry

meta names to consider including

name description

for class=p-summary

after:

  • if meta[property="og:description"], parse content as p-summary
  • else if meta[name="twitter:description"], parse content as p-summary

add

  • else if meta[name="description"], parse content as p-summary

OR

simplify to:

  • if meta[property="og:description"],meta[name="twitter:description"],meta[name="description"]
    • parse content as p-summary

Reasoning:

  • Google seems to index/display meta name=description for some sites (though not testable)
  • Does any code consume meta name=description that can be easily tested? Absent 2+, not worth including

other meta uses to consider

See:

other spec ideas

  • Consider using "metafont" typeface

See Also

Retrieved from "http://microformats.org/wiki/index.php?title=metaformats-brainstorming&oldid=70515"