Taken to www-archive, as this response would just be repeating what I've already said on www-tag.
On 7/18/07, Harry Halpin <[EMAIL PROTECTED]> wrote:
Mark Baker wrote: > > On 7/17/07, Harry Halpin <[EMAIL PROTECTED]> wrote: >> Mark Baker wrote: >> > >> > On 7/17/07, Harry Halpin <[EMAIL PROTECTED]> wrote: >> >> So inventing *two* new things, i.e. a new attribute and a new >> element, >> >> is superior than simply using @profile as it stands in the header in >> >> HTML 4 and *maybe* expanding it to work off an existing class >> element? >> > >> > Yes, I believe so. I'm all for extending existing mechanisms when the >> > extension won't break backwards compatibility (i.e. where existing >> > clients won't misinterpret the meaning of the document). But the >> > change you're suggesting would confuse them, as I believe I >> > demonstrated with my last example. >> I have to disagree respectfully. What precisely is confusing with the >> last example and how does it break backward compatibility? > > Here's the document snippets which demonstrate the backwards > incompatibility; existing software treats them as semantically > equivalent when they're not. > > <div class="employee" profile="http://example.org/human-resources/";> > > <div class="employee" profile="http://example.org/foo/bar/";> Does the *spec* say they should be treated semantically equivalent, or is it just default behavior with regard to any thing besides @id on a class element? At least last time I checked [1], @profile was not technically defined anywhere except the header. So, existing software would also have these two as equivalent, no? <div class="employee" profile2="http://example.org/human-resources/";> <div class="employee" profile2="http://example.org/foo/bar/";>
Right, but that's not what I'm suggesting.
So in that manner, this could be non-equivalent <div class2="employee" profile="http://example.org/human-resources/";> <div class2="employee" profile="http://example.org/foo/bar/";>
Non-equivalent, yes.
So the problem is not with @profile, but with @class.
Yes.
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. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
