metaformats-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(quote relevant sections from HTML spec)
(meta class attribute parsing)
Line 12: Line 12:


== Which attributes on meta ==
== Which attributes on meta ==
=== class ===
The meta tag does support the class attribute, but should we use it?
=== 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 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.u-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.

See Also