W3C home > Mailing lists > Public > www-archive@w3.org > July 2007

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

From: Mark Baker <distobj@acm.org>
Date: Wed, 18 Jul 2007 14:34:42 -0400
Message-ID: <e9dffd640707181134y283b65f1w222fed2a26be3e44@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:07 GMT