[whatwg] Trying to work out the problems solved by RDFa

[Calogero Alex Baldacchino]

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