metaformats-brainstorming: Difference between revisions
(dt-) |
|||
Line 58: | Line 58: | ||
in "parsing a dt- property", insert before "else return the textContent of the element after …" | in "parsing a dt- property", insert before "else return the textContent of the element after …" | ||
* else if <code>meta. | * else if <code>meta.dt-x[content]</code>, then return the <code>content</code> attribute | ||
no changes for "parsing an e- property", since it has no special parsing considerations on other empty elements like <code>data</code>. | no changes for "parsing an e- property", since it has no special parsing considerations on other empty elements like <code>data</code>. |
Revision as of 08:13, 2 April 2022
This page is for documenting brainstorming related to the 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 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