Re: problem with data-

At this stage there is no need for native browser support for the PS 
attributes. They just need to exist in a form that can be easily adopted 
by authors, easily consumed by browser extensions, and easily 
implemented in browsers (if the adoption proves successful enough to 
convince the browser engineers it is worthwhile) without breaking 
backwards compatibility.

There are different ways this can be done. None of them are perfect, so 
the TF will need to decide what it is prepared to comprimise on.

 From the WebPlat point of view, our recommendation is to use existing 
HTML technologies to get a form of the PS attributes out into the wild 
and into adoption, in order to demonstrate their viability and uptake.

The data attribute is intended to allow additional information to be 
added to native HTML elements, in a way that doesn't require 
non-standard attributes. This is how it's described on MDN [1]:

"data-* attributes allow us to store extra information on standard, 
semantic HTML elements without other hacks such as non-standard 
attributes, extra properties on DOM, or Node.setUserData()."

The comprimise with the data attribute is that it's not intended for use 
by tools outside of the website the attributes are defined on. The HTML 
spec recommends using Microdata instead [2], but the TF has already 
pushed back on using Microdata.

If the TF is concerned about bending the purpose of the data attribute, 
then I'd suggest revisiting Microdata as the easiest path forward.

It might be possible to use custom elements, but the comprimises are 
significantly higher. It would be necessary to create a custom element 
equivalent to every standard HTML element, in order to provide support 
for the proposed attributes.

In addition the burden on authors to adopt these custom elements would 
be much higher. Instead of using a standard HTML element and adding one 
or two attributes, they'd need to use a completely different element 
set, plus the polyfills needed to provide browser support where it's 
still missing.

Taking the custom elements path also raises questions of backwards 
compatibility (should the browsers be convinced to implement), and also 
maintenance and upkeep of the custom elements (if the browsers do not).

  Lisa mentioned on the TF call two weeks ago that the TF has access to 
resources that will enable positive steps to be taken, but that those 
resources are only available for a limited amount of time. At this stage 
I would urge the TF to get something out there, find out whether it 
works, iterate and/or change it if need be.

Léonie.
[1] 
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes

[2] 
https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes
-- 
@TetraLogical TetraLogical.com

Received on Tuesday, 12 March 2019 10:08:08 UTC