On 7/18/07, Harry Halpin <[EMAIL PROTECTED]> wrote:
Mark Baker wrote: > Taken to www-archive, as this response would just be repeating what > I've already said on www-tag. That's fine, and thanks for talking this through. [snip] >> >> In that regard, why not make @class do the "Right Thing" instead of >> inventing @class2? > > Because of the backwards compatibility reasons I've given, and the > problems it would create for already deployed software. But, if no one is using @profile in combination with class since it's undefined, why not define it as something like namespacing the class element?
Like I say, because existing software doesn't know about this change. If you did it, it could be nothing more than a "provisional namespace" in the sense that some agents will recognize it and some won't; what I was showing with the "employee" example.
Or, for that matter, div and span elements? Especially as that would be compatible with mixing and matching current microformats?
I don't think it would be compatible. Consider; <div class="vcard" profile="http://www.microformats.org/"; > ... and <div class="vcard" profile="http://example.org/some/other/url/"; > "vcard" has global scope. Trying to fix
I'm not the only one whose thinking this way - Ryan King from Technorati had this conversation with me where we thought this might be a sensible way to address the @profile/head issue.
Tantek had this XMDP thing that was supposed to address the extensibility issue (using @profile), but that was never adopted. As a result, "vcard" is now a global name because there's quite a bit of software out there that keys *only* off 'class="vcard"' without looking at @profile (which was recognized by the WHAT WG in HTML 5). We can't recall all that software, so we're stuck with that interpretation of @class. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
