html5: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(→‎Current microformat compatibility: labeled microdata vocabs explicitly)
(create referenceable subsections for HTML5 features, resolve profile issue)
Line 7: Line 7:
==New features in HTML5==
==New features in HTML5==


* '''<code>time</code> element for representing date times'''. In HTML5, the machine form of datetimes can be represented natively. It should be possible to replace the date-time design pattern with native HTML.
=== time element ===
** <code>time</code> takes an optional <code>pubdate</code> attribute, to indicate the publication date of an <code>article</code>. Synonymous with [[hAtom]] <code>published</code>, may imply [[hAtom]] <code>updated</code>, may imply [[hReview]] <code>dtreviewed</code>, may imply [[hListing]] <code>dtlisted</code>
'''<code>time</code> element for representing date times'''. In HTML5, the machine form of datetimes can be represented natively. It should be possible to replace the date-time design pattern with native HTML.
* '''<code>article</code>''' element for major, independent compositions of content within a page. Perhaps synonymous with [[hAtom]] <code>hentry</code>. Could be parsed as <code>hentry</code> within explicit <code>hfeed</code> blocks?
* <code>time</code> takes an optional <code>pubdate</code> attribute, to indicate the publication date of an <code>article</code>. Synonymous with [[hAtom]] <code>published</code>, may imply [[hAtom]] <code>updated</code>, may imply [[hReview]] <code>dtreviewed</code>, may imply [[hListing]] <code>dtlisted</code>
* '''<code>data-</code> naming convention for tag attributes'''. the draft specification states that any attribute that starts with "data-" will be treated as a storage area for private data.
** Note that the data-* stuff is explicitly 'not' for Microformats, at least not Microformats that ever want to be handled natively by the browser. Those attributes are defined in such a way that browsers will never do anything special with them, ever. They are intended for script authors to have a space in which they can play without ever clashing with anything the browser does.
* '''[[microdata]]'''. HTML5 provides a set of attributes and associated DOM APIs for extracting data from web pages.
** <code>itemprop</code> attribute is a more specific version of <code>class</code>, for field names
** <del><code>subject</code> attribute allows semantically linking within the page. Conceptually similar to the [[include-pattern]].</del>
** <code>&lt;itemref refid="x" /&gt;</code> allows semantically linking within the page. Conceptually similar to the [[include-pattern]].
** <code>content</code> attribute on the <code>meta</code> element can be used to invisibly include data. Conceptually similar to the [[value-class-pattern]].
** <code>itemscope</code> attribute identifies blocks to be marked as structure data. Conceptually similar to the [[mfo]] brainstorming?
** <code>itemtype</code> attribute to specify the type for an item (for example: <code><nowiki>itemtype="http://microformats.org/profile/hcard"</nowiki></code>)


== Current microformat compatibility ==
=== article element ===
There seems to be no issue with current implementation of the following microformats in HTML 5:
'''<code>article</code>''' element for major, independent compositions of content within a page. Perhaps synonymous with [[hAtom]] <code>hentry</code>. Could be parsed as <code>hentry</code> within explicit <code>hfeed</code> blocks?
* [[hcard]]
* [[xfn]]


Microdata vocabularies:
=== microdata ===
'''[[microdata]]'''. HTML5 provides a set of attributes and associated DOM APIs for extracting data from web pages.
* <code>itemprop</code> attribute is a more specific version of <code>class</code>, for field names
* <del><code>subject</code> attribute allows semantically linking within the page. Conceptually similar to the [[include-pattern]].</del>
* <code>&lt;itemref refid="x" /&gt;</code> allows semantically linking within the page. Conceptually similar to the [[include-pattern]].
* <code>content</code> attribute on the <code>meta</code> element can be used to invisibly include data. Conceptually similar to the [[value-class-pattern]].
* <code>itemscope</code> attribute identifies blocks to be marked as structure data. Conceptually similar to the [[mfo]] brainstorming?
* <code>itemtype</code> attribute to specify the type for an item (for example: <code><nowiki>itemtype="http://microformats.org/profile/hcard"</nowiki></code>)


==== microdata vocabularies ====
* [http://dev.w3.org/html5/mdvcard/ microdata vCard] - use [[hCard]] instead, taking into account the [[hcard-faq|hCard FAQ]] and [[hcard-issues-resolved|resolved]]+[[hcard-issues-closed|closed issues]]. hCard 1.0.1 (under development) is incorporating these errata. Avoid the "microdata vCard" vocabulary as it is an out-of-date fork/snapshot of hCard.
* [http://dev.w3.org/html5/mdvcard/ microdata vCard] - use [[hCard]] instead, taking into account the [[hcard-faq|hCard FAQ]] and [[hcard-issues-resolved|resolved]]+[[hcard-issues-closed|closed issues]]. hCard 1.0.1 (under development) is incorporating these errata. Avoid the "microdata vCard" vocabulary as it is an out-of-date fork/snapshot of hCard.
* [http://dev.w3.org/html5/mdvevent/ microdata vEvent] - use [[hCalendar]] instead, taking into account the [[hcalendar-faq|hCalendar FAQ]] and [[hcalendar-issues-resolved|resolved]]+[[hcalendar-issues-closed|closed issues]].  hCalendar 1.0.1 is incorporating these errata. Avoid the "microdata vEvent" vocabulary, as it is an out-of-date fork/snapshot of hCalendar's vevent root class name and applicable properties.
* [http://dev.w3.org/html5/mdvevent/ microdata vEvent] - use [[hCalendar]] instead, taking into account the [[hcalendar-faq|hCalendar FAQ]] and [[hcalendar-issues-resolved|resolved]]+[[hcalendar-issues-closed|closed issues]].  hCalendar 1.0.1 is incorporating these errata. Avoid the "microdata vEvent" vocabulary, as it is an out-of-date fork/snapshot of hCalendar's vevent root class name and applicable properties.
* [http://dev.w3.org/html5/mdwork/ microdata Licensing Works] - see also [[licensing-brainstorming]]
* [http://dev.w3.org/html5/mdwork/ microdata Licensing Works] - see also [[licensing-brainstorming]]
=== data attributes ===
'''<code>data-</code> naming convention for tag attributes'''. the draft specification states that any attribute that starts with "data-" will be treated as a storage area for private data.
* Note that the data-* stuff is explicitly 'not' for Microformats, at least not Microformats that ever want to be handled natively by the browser. Those attributes are defined in such a way that browsers will never do anything special with them, ever. They are intended for script authors to have a space in which they can play without ever clashing with anything the browser does.
== Current microformat compatibility ==
There seems to be no issue with current implementation of the following microformats in HTML 5:
* [[hcard]]
* [[xfn]]


== Requests ==
== Requests ==
Line 39: Line 45:


==Issues==
==Issues==
<div class='discussion issues'>
<div class='discussion issues'>
* '''The <code>rev</code> attribute has been removed'''. In HTML5, <code>rel</code> and <code>rev</code> are no-longer paired, and the <code>rel</code> attribute nolonger describes the direction of a relationship. Microformats which use <code>rev</code> will need to use <code>rel</code> instead.
* '''The <code>rev</code> attribute has been removed'''. In HTML5, <code>rel</code> and <code>rev</code> are no-longer paired, and the <code>rel</code> attribute nolonger describes the direction of a relationship. Microformats which use <code>rev</code> will need to use <code>rel</code> instead.
Line 45: Line 50:
*** As above, <code>data-</code> attributes are for application-context functionality, ''not'' shared vocabularies. Further, the HTML5 specification makes <code>rel</code> the correct attribute to use, regardless of direction, through the changed specification. --[[User:BenWard|BenWard]] 17:53, 12 May 2009 (UTC)
*** As above, <code>data-</code> attributes are for application-context functionality, ''not'' shared vocabularies. Further, the HTML5 specification makes <code>rel</code> the correct attribute to use, regardless of direction, through the changed specification. --[[User:BenWard|BenWard]] 17:53, 12 May 2009 (UTC)
* '''The <code>profile</code> attribute has been removed'''. In HTML, the <code>profile</code> attribute from the <code>head</code> has been removed, with no direct replacement. This causes issues for GRDDL support. It's been suggested that profile URLs be represented in <code>link</code> elements instead, or even as a custom HTTP header. See [[grddl]] and [[profile-uris]]
* '''The <code>profile</code> attribute has been removed'''. In HTML, the <code>profile</code> attribute from the <code>head</code> has been removed, with no direct replacement. This causes issues for GRDDL support. It's been suggested that profile URLs be represented in <code>link</code> elements instead, or even as a custom HTTP header. See [[grddl]] and [[profile-uris]]
** See [[rel-profile]] which is the replacement for the profile attribute. [[User:Tantek|Tantek]] 23:24, 5 November 2009 (UTC)
* '''Microdata <code>itemprop</code> duplicates <code>class</code> data'''. the new attribute itemprop is designed to hold some meaningful data about an element, but class already exists to hold this data. Unsure of reasons why itemprop required?
* '''Microdata <code>itemprop</code> duplicates <code>class</code> data'''. the new attribute itemprop is designed to hold some meaningful data about an element, but class already exists to hold this data. Unsure of reasons why itemprop required?
** This is because microdata is designed to be generically parsable, even when the parser does not understand the vocabulary. As such, property names have to be on an explicit attribute, not shared with other, non-data classnames. --[[User:BenWard|BenWard]] 21:12, 4 September 2009 (UTC)
** This is because microdata is designed to be generically parsable, even when the parser does not understand the vocabulary. As such, property names have to be on an explicit attribute, not shared with other, non-data classnames. --[[User:BenWard|BenWard]] 21:12, 4 September 2009 (UTC)

Revision as of 23:24, 5 November 2009

Microformats in HTML 5

This page is to document future use of microformats in HTML 5. None of the items documented are supported now, and may change upon proper development within the microformats community, or changes in the HTML 5 specification. This page is to track HTML5 enabled enhancements to microformats, and issues that HTML5 raises. It may be used to track issues which we need to push back into the HTML 5 development process.

If there are things that Microformats would like to mark up that aren't handled by HTML5 explicitly, please let the WHATWG know, so we can improve HTML5. This is how time came to be, for instance.

New features in HTML5

time element

time element for representing date times. In HTML5, the machine form of datetimes can be represented natively. It should be possible to replace the date-time design pattern with native HTML.

  • time takes an optional pubdate attribute, to indicate the publication date of an article. Synonymous with hAtom published, may imply hAtom updated, may imply hReview dtreviewed, may imply hListing dtlisted

article element

article element for major, independent compositions of content within a page. Perhaps synonymous with hAtom hentry. Could be parsed as hentry within explicit hfeed blocks?

microdata

microdata. HTML5 provides a set of attributes and associated DOM APIs for extracting data from web pages.

  • itemprop attribute is a more specific version of class, for field names
  • subject attribute allows semantically linking within the page. Conceptually similar to the include-pattern.
  • <itemref refid="x" /> allows semantically linking within the page. Conceptually similar to the include-pattern.
  • content attribute on the meta element can be used to invisibly include data. Conceptually similar to the value-class-pattern.
  • itemscope attribute identifies blocks to be marked as structure data. Conceptually similar to the mfo brainstorming?
  • itemtype attribute to specify the type for an item (for example: itemtype="http://microformats.org/profile/hcard")

microdata vocabularies

data attributes

data- naming convention for tag attributes. the draft specification states that any attribute that starts with "data-" will be treated as a storage area for private data.

  • Note that the data-* stuff is explicitly 'not' for Microformats, at least not Microformats that ever want to be handled natively by the browser. Those attributes are defined in such a way that browsers will never do anything special with them, ever. They are intended for script authors to have a space in which they can play without ever clashing with anything the browser does.

Current microformat compatibility

There seems to be no issue with current implementation of the following microformats in HTML 5:

Requests

Issues

  • The rev attribute has been removed. In HTML5, rel and rev are no-longer paired, and the rel attribute nolonger describes the direction of a relationship. Microformats which use rev will need to use rel instead.
    • Or something like data-rev="vote-for"
      • As above, data- attributes are for application-context functionality, not shared vocabularies. Further, the HTML5 specification makes rel the correct attribute to use, regardless of direction, through the changed specification. --BenWard 17:53, 12 May 2009 (UTC)
  • The profile attribute has been removed. In HTML, the profile attribute from the head has been removed, with no direct replacement. This causes issues for GRDDL support. It's been suggested that profile URLs be represented in link elements instead, or even as a custom HTTP header. See grddl and profile-uris
    • See rel-profile which is the replacement for the profile attribute. Tantek 23:24, 5 November 2009 (UTC)
  • Microdata itemprop duplicates class data. the new attribute itemprop is designed to hold some meaningful data about an element, but class already exists to hold this data. Unsure of reasons why itemprop required?
    • This is because microdata is designed to be generically parsable, even when the parser does not understand the vocabulary. As such, property names have to be on an explicit attribute, not shared with other, non-data classnames. --BenWard 21:12, 4 September 2009 (UTC)

see also