metaformats-brainstorming: Difference between revisions
(meta names to consider including / name description (insufficient testable consuming code implementations), other meta uses to consider, other spec ideas) |
(→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) |
||
Line 114: | Line 114: | ||
== other meta uses to consider == | == other meta uses to consider == | ||
See: | See: | ||
* https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names | |||
** for any meta names that this effort rejects due to lack of implementations, consider filing an bug on the HTML Standard to deprecate/drop such names | |||
* https://github.com/joshbuchea/HEAD#meta | * https://github.com/joshbuchea/HEAD#meta | ||
* https://wiki.whatwg.org/wiki/MetaExtensions | * https://wiki.whatwg.org/wiki/MetaExtensions |
Revision as of 22:33, 4 April 2022
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.
- https://indieweb.org/metaformats
- https://david.shanske.com/2022/03/14/meta-tags-to-microformats/
- https://www.jvt.me/posts/2022/03/14/opengraph-mf2/
- https://ogp.me/
- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta
- https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element
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 thebody
?
- Do any existing consuming code (that supports meta in the
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 thecontent
attribute
in "parsing a u- property", insert before "else return the textContent of the element after …"
- else if
meta.u-x[content]
, then get thecontent
attribute
in "parsing a dt- property", insert before "else return the textContent of the element after …"
- else if
meta.dt-x[content]
, then return thecontent
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
orhead
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 ofh-entry
- if it’s "profile" then imply a
head
element root class name ofh-card
- if it's "music" or "video" then imply a
head
element root class name ofh-cite
- get its
- end if
- if there is no implied
head
element root class name andmeta[name=twitter:card]
then- if it's "summary" or "summary_large_image" then imply a
head
element root class name ofh-entry
- if it's "summary" or "summary_large_image" then imply a
- end if
- if there is no implied
head
element root class name andmeta[property^=og:]
ormeta[name^=twitter:]
- then imply a
head
element root class name ofh-entry
meta names to consider including
name description
for class=p-summary
after:
- if
meta[property="og:description"]
, parsecontent
asp-summary
- else if
meta[name="twitter:description"]
, parsecontent
asp-summary
add
- else if
meta[name="description"]
, parsecontent
asp-summary
OR
simplify to:
- if
meta[property="og:description"],meta[name="twitter:description"],meta[name="description"]
- parse
content
asp-summary
- parse
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:
- https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names
- for any meta names that this effort rejects due to lack of implementations, consider filing an bug on the HTML Standard to deprecate/drop such names
- https://github.com/joshbuchea/HEAD#meta
- https://wiki.whatwg.org/wiki/MetaExtensions
other spec ideas
- Consider using "metafont" typeface