From Microformats Wiki
html5-profile-issues /
Revision as of 00:05, 22 February 2010 by Komputist (talk | contribs) (→‎2010: added 2 issues)
Jump to navigation Jump to search

<entry-title>HTML5 profile attribute issues </entry-title>

These are externally raised issues about the HTML5 Profile Attribute with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

IMPORTANT: Please read the HTML5 Profile Attribute FAQ and the HTML5 Profile Attribute resolved issues before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

closed issues

See: html5-profile-issues-closed

resolved issues

See: html5-profile-issues-resolved


Please add new issues to the bottom of the list below by copy and pasting the template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.


  • Copyright statement - 2010-02-19

This is a request for clarification.

This document is in the public domain. If the W3C HTML Working Group accepts to take on the proposal as a deliverable, should contributions from the Working Group participants expected to be in the public domain as well, or can they remain under the W3C Document license? As owner of ACTION-29 in the WG, I'm interested in gathering rationals in both approaches. -PLH.

open issue!

raised by Krzysztof Maczyński

  • Should sections 2 and 3 be normative?

The message announcing the draft indicates that sections 2 (“listing known HTML 4.01 errata regarding the profile attribute on the head element”) and 3 (“describing how this specification could be applied to both previous versions of HTML and XHTML, and other markup languages”) would be informative. I propose that the HTML WG consider making them normative.

open issue!

raised by LHS

  • data-foo="" should be in (subsequent) scope of @profile. An <element class="classname"> that is linked to a profile should be treated as an element, for which it should be possible to specify optional or required data-foo attributes. Example: <element class="classname" data-profileprefix-attribute="value"></element> In other words, it should be possible to specify required/optional data-foo="" attributes together with specific element@class combinations.
Related info and messages
My message to the HTMLwg leading up to this issue entry,
Message from Toby Inkster in support of a html5 profile spec,
The original profile based distributed extensibility idea of Toby Inkster,
data-foo="" in HTML5, including the space ship element example: <div class="spaceship" data-ship-id="92432" data-weapons="laser 2" [ etc ]
For scripting libraries, then HTML5 recommends using a prefix (data-prefx-attribute="" to avoid clashes - this should be considered for the HTML5 profile specification also.

open issue!

raised by LHS

  • ARIA attributes and role="" should be in (subsequent) scope of @profile. An <element class="classname"> that is linked to a profile should be treated as an element, for which it should be possible to specify recommended ARIA and role attribtues. Example: <element class="classname" role="button"></element>
Related info and messages
My message to the HTMLwg leading up to this issue entry,
Question from Joe D Williams (comment to Toby Inksters Distributed Extensibility proposal


Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2

related pages