This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Spec section 3.2.3.9 on custom data attributes specifies how hyphenated data-* attribute names are converted to camelCase for inclusion in an element's dataset which is a DomStringMap. And precise specifications are given for how names are read and updated in a DomStringMap. However the specification is mute on whether an update to a name's value in the DomStringMap should cause an update to the corresponding content attribute in the underlying element. In jquery, for example, data-* attributes are read into the DomStringMap on first access, but changes to the corresponding values in the DomStringMap are *not* pushed back as changes to the DOM node's content attributes.
Having read some more spec I can simplify the question: are custom data elements in element.dataset required to reflect the corresponding data-* content attributes?
This is actually fully specified, as far as I can tell. Specifically, in section 3.2.3.9 the "algorithm for setting names to certain values" step 6 clearly says that setting a property on element.dataset sets the corresponding data-* attribute on the element. So the answer to the question in comment 1 is "Yes".
Good; thanks for pointing that out. I was investigating because jquery's .data() method, which seems awfully close to implementing the html5 spec, does *not* perform this reflection: it explicitly states that the .data() object is populated only once, and any future modifications to the object or to the DOM do not reflect.
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: Rejected Change Description: none Rationale: Reflection is indeed specified here. David: the confusion here is that jQuery's data() is actually something rather different. You can use data-* attributes to store additional information on the tree, but it's limited to the sort of stuff you can put in an attribute value. jQuery's data() is used to add pretty much any kind of data that JS can hold to an element. You can include things like pointers to another node, or the complete implementation of a plugin (so that if a plugin instance is handling the element's behaviour, you can grab the instance and interact with it using data()). It's not the same thing, and you really couldn't reflect what jQuery does into the DOM (at least not in a way that could make sense serialised).