W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > April 2012

On why we should use data-its-* if we want to use prefixed attributes for HTML5

From: Maxime Lefrançois <maxime.lefrancois@inria.fr>
Date: Thu, 26 Apr 2012 17:18:02 +0200 (CEST)
To: public-multilingualweb-lt@w3.org
Message-ID: <99675875.209750.1335453482294.JavaMail.root@zmbs3.inria.fr>


Hi, 




Following the issue 2 and a rereading of the extensibility section 2.2.3 of the HTML5 specification, it is clearly stated that we must use prefix data-its- for HTML5. 

http://dev.w3.org/html5/spec/infrastructure.html#extensibility , I can assure the following: 



- The prefix-* approach is not conform, not valid. We must not use its-* custom attributes, as we can't be ensured, for instance, that a specific vendor of HTML5 browsers won't delete these attributes in the DOM before rendering the page. 

- The x-vendor-feature only applies to vendors and should be used for experimental purpose only. We are no vendor and we are not discussing an experimental feature for a single implementation. By vendors, it is meant browsers (chrome, firefox, opera, ie... c.f. FerretBrowser given as an example in HTML5 section 2.2.3). 

- It is explicitly stated in the same section that the data-* attribute should be ignored and untouched by vendors (browsers), but we may recommend the use of such attributes and remain fully compatible with the current HTML5 working draft. 



The data-* attributes may be used for data exchanges, which is our usage scenario. 

Following http://dev.w3.org/html5/spec/global-attributes.html#attr-data , the data-its-bar attribute of element e will be accessible through the DOM as e.dataset.itsBar, data-its-foo-bar attribute will be accessible through the DOM as e.dataset.itsFooBar, etc. 



For all the reasons stated above and in order to limit the possibilities of conflict, we must use data-its-* attributes. 

Kind regards, 

Maxime Lefrançois 
Ph.D. Student, INRIA - WIMMICS Team 
http://maxime-lefrancois.info 
@Max_Lefrancois 
Received on Thursday, 26 April 2012 15:18:52 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 June 2013 00:24:55 UTC