This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8381 - I greatly appreciate the addition of custom user attribute values, but take strong exception to the particular notation.
Summary: I greatly appreciate the addition of custom user attribute values, but take s...
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-26 02:48 UTC by contributor
Modified: 2010-10-04 14:31 UTC (History)
5 users (show)

See Also:

Attachments

Description contributor 2009-11-26 02:48:26 UTC 
Section: http://www.whatwg.org/specs/web-apps/current-work/#embedding-custom-non-visible-data

Comment:
I greatly appreciate the addition of custom attribute values, but I take strong exception to the particular notation.  In reality, HTML 5 is providing just one attribute named "data," which is quite acceptale because attribute values may be structured.  What's wrong here is the notation.  It needlessly forces the attribute's values to be objects, and it provides ill-advised syntactic sugar for handling structured data that is already better provided for in javascript. I recommend dropping the syntactic sugar, dropping the requirement that the attribute's values be objects, and changing the name from "data" to "u" for user.  The result will be a notation that is simpler, more powerful, easier to implement, and easier to learn and use -- a quintuple win.  

Posted from: 208.103.74.169
Comment 1 James Williams 2009-11-26 03:59:48 UTC 
I use custom attributes all the time, debugging them in MSIE and then compiling them into legitimate but unreadable HTML in order to get along with Firefox.  I also make heavy use custom css attributes and would appreciate having the two problems solved compatibly.  Here's a sample of my work that is fully acceptable to MSIE, but that must be "compiled" for Firefox:

.cls-gray { 
	color: #809080; 
	nskin: skin-gray; 
	placement: source-line; 
	active: { font-variant: small-caps }
	}

............... 
<span class="cls-gray" nref="#termDefinition"
      style="placement: note">term&nbsp;definition</span>

Using the one-name-is-enough principle, this could easily be rewritten as

.u	{ cls-gray: { 
		color: #809080; 
		nskin: skin-gray; 
		placement: source-line; 
		active: { font-variant: small-caps }
 		}
	}

............... 
<span class="cls-gray" u.nref="#termDefinition"
      style="u.placement: note">term&nbsp;definition</span>
Comment 2 Ian 'Hixie' Hickson 2010-01-05 11:37:19 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I am very confused by this bug report.

The data-*="" attributes aren't one attribute, they're an infinite number of attributes. The values are strings, not objects. There's no syntactic sugar in the markup, it's just regular content attributes. The dataSet IDL attribute is a convenience accessor for the underlying content attributes, but it also only uses strings for the values.

It isn't clear what syntactic sugar is to be dropped; it's not clear what requirement regarding attribute valus it is that is to be dropped; and changing the name from "data" to "u" seems to provide minimal improvement over the current draft. I don't see how changing any of these would make anyhing more powerful or easier to implement.

If you could elaborate on the proposal, ideally by pointing out the precise parts of the spec that you think need improving by quoting the relevant text, that would be more helpful.