- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Tue, 17 Jul 2007 15:46:38 -0400
- To: Mark Baker <distobj@acm.org>
- Cc: noah_mendelsohn@us.ibm.com, Dan Connolly <connolly@w3.org>, www-tag <www-tag@w3.org>
Mark Baker wrote: > On 7/17/07, Harry Halpin <hhalpin@ibiblio.org> wrote: >> Why not instead of >> >> <div class2="http://example.org/human-resources/employee"> >> >> just do >> >> <div class="employee" profile="http://example.org/human-resources/"> > > Because no software which knows of @class knows about @profile, making > that snippet semantically identical to this one; > > <div class="employee" profile="http://example.org/foo/bar/"> No software which knows about @class knows about the theoretical new "@profile2" either. Software won't know about it unless 1) it's in the spec and 2) software uses it to produce value, sort of in that order. Since neither @profile or the theoretical @profile2 is in the spec, @profile is the clear winner, even if it has to remain in the header, since at least @profile is in HTML 4. > Using a new attribute makes it unambiguous. Using @profile is just as unambiguous. Changing new string names does not make something unambiguous unless the previous string name is already deployed at that location in the HTML|XML file, which neither @profile or the theoretical @profile2 is. At least with @profile you are building off something and/or extending something in HTML 4, instead of inventing whole new attributes to do something a previous attribute in HTML 4 did. I see no reason to reinvent the wheel, as there is no semantic gain from changing string names. > > Mark. -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Tuesday, 17 July 2007 19:47:05 UTC