metaformats-brainstorming: Difference between revisions
(quote relevant sections from HTML spec) |
(meta class attribute parsing) |
||
Line 12: | Line 12: | ||
== Which attributes on meta == | == Which attributes on meta == | ||
=== name === | === name === | ||
The HTML specification defines the meta name attribute: https://html.spec.whatwg.org/#attr-meta-name | The HTML specification defines the meta name attribute: https://html.spec.whatwg.org/#attr-meta-name | ||
Line 26: | Line 23: | ||
Since microformats has the similar model of name/value pairs in the form of properties and values, microformats should use the <code>name</code> attribute to express property semantics to follow this portion of the HTML specification. | Since microformats has the similar model of name/value pairs in the form of properties and values, microformats should use the <code>name</code> attribute to express property semantics to follow this portion of the HTML specification. | ||
As a fallback, should microformats also allow using the <code>class</code> attribute on meta tags? Or at least specify what should happen if it is present? | As a fallback, should microformats also allow using the <code>class</code> attribute on meta tags? Or at least specify what should happen if it is present? Explored in the [[#class|class attribute]] section below. | ||
=== content === | === content === | ||
Line 35: | Line 32: | ||
=== property === | === property === | ||
Only for backcompat with Open Graph Protocol. | 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 <code>else return the textContent of the element after …</code> | |||
* else if <code>meta.p-x[content]</code>, then return the <code>content</code> attribute | |||
in "parsing a u- property", insert before <code>else return the textContent of the element after …</code> | |||
* else if <code>meta.u-x[content]</code>, then get the <code>content</code> attribute | |||
in "parsing a dt- property", insert before <code>else return the textContent of the element after …</code> | |||
* else if <code>meta.u-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>. | |||
== See Also == | == See Also == | ||
* [[metaformats]] | * [[metaformats]] |
Revision as of 03:26, 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.u-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
.