Benjamin Hawkes-Lewis ha scritto:
After all, support for unknown attributes/elements has never been a
standard "de jure", but more of a quirk
Depends what you mean by "support" I guess.
I just mean that, as far as I know, there is no official standard
requiring UAs to support (parse and expose through the DOM) attributes
and elements which are not part of the HTML language but are found in
text/html documents. Usually, browsers support them for robustness sake
and/or backward compatibility with existing pages, but they might do it
with significant differences (actually it happens for unknown elements
but not for unknown attributes, but one shouldn't assume such common
behavior might not change in the future, or that will be adopted by
newer vendors (even if that might be a quite safe assumption), thus any
hack to the language /for custom purposes and script elaboration/ should
be done by the mean of existing attributes/elements instead of creating
new ones (I mean, "data-rdfa-about" might be a bit safer than just
"about" to use a conservative approach based on the assumption "I know
what happens today, not what will happen tomorrow") -- before data-* it
was possible through the class attribute, now also data-* can be used
for custom hacks)
I really don't see the problem if a *custom* convention became widely
accepted and reused by other people
Then you I think you don't agree with the fundamental design principle
of the "data-*" attribute. The theory is that extensions to HTML
benefit from going through a community process like WHATWG or W3C, and
blessing extension points encourages people to circumvent that
process, with the result that browsers have to support poorly designed
features in order to have an interoperable web.
Yet it is *possible* to use data-* attributes to define a proper
*private* convention by choosing names carefully in order to avoid
clashes with other private conventions (for instance, a widget might
need metadata to be put within the host page, and a careful choice of
data-* names might avoid clashes with other metadata needed by other
widgets or by the page itself). More people might find a certain
convention useful and enough reusable for their purposes (because of
non-clashing names), and the result would be a clearer "caw path" that
community "cawboys" might follow to catch the free problem running away
from standards.
The *only* difference with "data-rdfa-*" here would be that a higher
number of authors/developers should agree with such a convention from
the beginning, but only if they were interested in exchanging the same
metadata with each others for their respective *custom* uses (through a
custom script or plugin, either developed independently or shared). From
this point of view, the only difference between "data-rdfa-about" and
"about" - as used for the purposes of SearchMonkey - is that the former
is immediately conforming to HTML5 spec and, thus, surely exposed
through the DOM by every possible HTML5 compliant UA, as it happens for
classes used by Microformats. I've never thought to any requirements for
UAs not coming from a clearly traced "caw path", the same way there is
no requirement for UAs not involved in SearchMonkey to support any kind
of metadata - for the purposes of SearchMonkey itself.
Unless one thinks that everyone facing a problem not solved (at all or
enough for his purposes) by an official standard should either create a
private hack disregarding any possible hacks for similar problems he
might have happened to find on the web, or start a new community process
eventually without knowing if other people are facing the same problem,
or a similar one, I really can't understand why a *custom* and
*born-private* (eventually within a group of authors/developers) and
then become a widely accepted convention should be a problem, as far as
it is based on existing, standard features and doesn't require any
additional support and results in a possible cawpath to be then
standardized as needed. And I really don't understand why class="xyz" is
a good hack whereas "data-some-thing" is not, assuming both are designed
for and used by "caws opening a path" ( :-P )
I really can't get, right now, why it should be different, for instance,
from the case of a freely reusable widget using a custom data model
based on private data-* attributes inserted by people in thousands of
websites (the widget with relitive metadata, I mean), then liked by
other people and reused in different contexts (the same data model based
on data-*, now)
Reuse of "data-*" by DHTML widgets would not impose any additional
requirements on user agents, so it would be fine from the perspective
elaborated above. It wouldn't change the language by the back door.
Really? Is it so much different from the case of the pattern attribute
(which addresses, at the UA and language level, a problem earlier solved
by scripts -- e.g. getting elements by their ids)? I don't think it's
very different. From this perspective, if data-* attributes existed
before the pattern attribute, someone might have used them to declare a
regex then used by a script implementing a generic checking, and such
might have been a good reason to add the pattern attribute to form
inputs, requiring UAs to contrast the input value to its relative
regular expression (a solution wich also works for UAs not supporting
scripts, for instance).
I guess closing a language to every kind of "back-door changes" may be
in contrast with the principle of paving a cawpath. I also guess that,
if microformats experience (or the "realworld semantics" they claim to
be based on) had suggested the need to add a new element/attribute to
the language, a new element/attribute would have been added.
WBR, Alex
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Partecipa al concorso Danone Activia e vinci MacBook Air e Nokia N96. Prova
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8550&d=12-1
