Re: microformats, profiles, and taking back rel/class names [standardizedFieldValues-51]

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/">

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/">

So the problem is not with @profile, but with @class.

In that regard, why not make @class do the "Right Thing" instead of
inventing @class2?

>> Perhaps I am missing something, but I find introducing new elements and
>> attributes with the same semantics and behavior as previously defined
>> elements confusing.
> Granted, it will be confusing to some authors.  But I'd rather have
> some confusion than break backwards compatibility.
I mean, if backward compatibility means the software was just doing what
the spec says and the spec leaves that undefined, then I don't see how
defining it in the next version of the spec breaks anything.


[1] http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3
> Mark.


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Wednesday, 18 July 2007 14:41:21 UTC