- From: Mark Baker <distobj@acm.org>
- Date: Wed, 18 Jul 2007 14:34:42 -0400
- To: "Harry Halpin" <hhalpin@ibiblio.org>
- Cc: www-archive@w3.org
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 <hhalpin@ibiblio.org> wrote: > Mark Baker wrote: > > > > On 7/17/07, Harry Halpin <hhalpin@ibiblio.org> wrote: > >> Mark Baker wrote: > >> > > >> > On 7/17/07, Harry Halpin <hhalpin@ibiblio.org> 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
Received on Wednesday, 18 July 2007 18:34:48 UTC