Re: data-* attributes (and regrets)

Boris Zbarsky:

> Indeed.  I don't think there's a web compat issue here; the only issue is
> whether we want to just dictate that all XML vocabularies going forward
> have these global attributes that they're not allowed to use for anything
> internal to the vocabulary.

I think, these pseudo-attribute-group data-* cares only about 
specific problems of the HTML5 tag soup variant without any 
use for other formats, including the XML variant of HTML5.
Due to namespaces XML based formats have already a more 
advanced, thought through older solution for this problem,
therefore  no reason here to reinvent the wheel again
(not being round anymore).
Yet another example, that it would have been much more 
effective to forget about the  HTML5 tag soup variant right 
from the start instead of 'solving' once more already solved 
problems in a strange way, that would have not appeared 
without the needless HTML5 tag soup variant at all ;o)
From an authors point of view, all these special ways of
HTML5 are wasted time, if implementors care about this
instead of fixing bugs and gaps in viewers or implementing
really new issues.

And if a developer of an XML format decides to define the
meaning of 'data-set' or 'data-fomat' etc for his format, 
it is defined in this way for this format and is not related to any 
HTML5 tag soup definitions.
For formats caring about computation and transformation
of data, something starting with 'data-' is obvious as a
name of attributes or elements with a format specific 
special meaning ...

This applies as well to an attribute with the name 'id' -
some viewer did get it wrong and interpreted as in a
similar way than 'xml:id' - similar stupid bugs may appear
if viewers implicate a specific behaviour for attributes
starting with 'data-', wasting time of people again.
If there is a need for some 'data-*' in XML, there should
be a definition with the prefix 'xml' as usual.
But I cannot see a usecase for this, that is not already
satisfied.

Concering SVG - the use of attributes from other namespaces
is already widely in use (sodipodi, inkscape, adobe ...),
therefore no need to confuse authors with yet another
method with strange HTML5 tag soup syntax and rules ...
No need to blow up source code with yet another 
syntax variant to indicate content to be ignored by normal
viewers.
Maybe it will result in no specific problems, if SVG
defines all relevant 'data-*' attributes individually,
but already if * is only a small letter, these are already
about 26 definitions for what benefit? Nothing than 
wasting time of people with needless issues!

If these pseudo-attributes are defined for the
XML variant of HTML5 as well (are they?),
it should be no problem for SVG authors to use 
such attributes with an HTML5 namespace or the 
general XHTML namespace in SVG, why to worry?


Olaf

Received on Sunday, 14 December 2014 14:46:27 UTC