Re: changing abbr-design-pattern to title-design-pattern?

_______________________________________________
MICROFORMATS-DISCUSS MAILING LIST
MICROFORMATS-DISCUSSMICROFORMATS.ORG
HTTP://MICROFORMATS.ORG/MAILMAN/LISTINFO/MICROFORMATS-DISCUS
S

Hi all,

I'm not sure how many here (a few at least?) have been
following  
developments with the W3's HTML WG.

In essence, the future of HTML will be HTML5:

"We are resolved, then, that the W3C's next-generation
HTML  
specification be named "HTML 5" and to start
review of the text of  
the HTML 5 and WF2 specifications, and we welcome Ian
Hickson and  
Dave Hyatt as editors (while remaining open to the
possibility of  
other editors in the future)." [1]

Of particular relevance to this mailing list is the way in
which  
HTML5 provides mechanisms for extending the semantics of
HTML - and  
the discussions around the issue of semantics in HTML
generally. This  
thread on the very busy mailing list (which is in effect is
now the  
official communications channel for the development of HTML)
should  
give a sense of the general way in which people involved are
 
thinking. [2]
I'd argue that things don't look overly promising on that
front at  
present. Two mechanisms are currently used in HTML5

1. A small number of new HTML elements, like
<copyright>
2. "reserved" class values that coincide with
currently widely used  
class values in the wild (though whether any two instances
of the  
same class value will always imply the same thing is open to
 
consideration, at the very least).

Unfortunately the HTML WG mailing list is ludicrously busy -
1000+  
messages a week, so keeping up with it, and participating
is,  
frankly, impossible, but I do think it is an area in which 

participants in this community have a significant amount of 

theoretical and practical experience with, and the HTML 5
efforts  
would definitely benefit from that. In the associated
threads I've  
seen very little mention of ufs, and where they have been
mentioned,  
somewhat critical (abbr pattern problems, even with ufs no
one uses  
profiles so HTML 5 should get rid of them ...)

 From the outside, the whole enterprise does look like
possibly  
falling into a heap of political/religious/theoretical
debates, and  
does make me feel that at time arguably restrictive policies
of  
what's on topic for these mailing lists in fact serve the
community  
very well in many ways.

Anyway, just a little update on something that is without
doubt very  
relevant to the efforts of the uf community, and hopefully
many of  
the lessons hard learned over the last few years developing
ufs might  
benefit the HTML  WG efforts

[1] http://lists.w3.org/Archives/Public/public-html
/2007May/0909.html
[2] http://lists.w3.org/Archives/Public/public-html
/2007May/0881.html

john

John Allsopp

style master :: css editor :: http://westciv.com/st
yle_master
about me :: http://johnfallsopp.com
Web Directions Conferences :: http://webdirections.org

My Microformats book :: http://microformatiqu
e.com/book

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On May 11, 2007, at 3:15 PM, John Allsopp wrote:

> Hi all,
>
> I'm not sure how many here (a few at least?) have been
following  
> developments with the W3's HTML WG.
>
> In essence, the future of HTML will be HTML5:
>
> "We are resolved, then, that the W3C's
next-generation HTML  
> specification be named "HTML 5" and to start
review of the text of  
> the HTML 5 and WF2 specifications, and we welcome Ian
Hickson and  
> Dave Hyatt as editors (while remaining open to the
possibility of  
> other editors in the future)." [1]
>
> Of particular relevance to this mailing list is the way
in which  
> HTML5 provides mechanisms for extending the semantics
of HTML - and  
> the discussions around the issue of semantics in HTML
generally.  
> This thread on the very busy mailing list (which is in
effect is  
> now the official communications channel for the
development of  
> HTML) should give a sense of the general way in which
people  
> involved are thinking. [2]
> I'd argue that things don't look overly promising on
that front at  
> present. Two mechanisms are currently used in HTML5
>
> 1. A small number of new HTML elements, like
<copyright>

HTML5 does have new elements, some of which are mainly for
semantic  
purposes, but it does not at present have a
<copyright> element. Some  
of the new elements include <header>, <footer>,
<section>, <article>  
and <aside>. HTML5 also applies semantics to some
formerly  
presentation elements based on their most common use, for
instance  
<small> is defined to be appropriate for details that
would normally  
be in fine print.

> 2. "reserved" class values that coincide with
currently widely used  
> class values in the wild (though whether any two
instances of the  
> same class value will always imply the same thing is
open to  
> consideration, at the very least).

The current proposal does have a predefined
"copyright" class though.

> Unfortunately the HTML WG mailing list is ludicrously
busy - 1000+  
> messages a week, so keeping up with it, and
participating is,  
> frankly, impossible, but I do think it is an area in
which  
> participants in this community have a significant
amount of  
> theoretical and practical experience with, and the HTML
5 efforts  
> would definitely benefit from that. In the associated
threads I've  
> seen very little mention of ufs, and where they have
been  
> mentioned, somewhat critical (abbr pattern problems,
even with ufs  
> no one uses profiles so HTML 5 should get rid of them
...)
>
> From the outside, the whole enterprise does look like
possibly  
> falling into a heap of political/religious/theoretical
debates, and  
> does make me feel that at time arguably restrictive
policies of  
> what's on topic for these mailing lists in fact serve
the community  
> very well in many ways.
>
> Anyway, just a little update on something that is
without doubt  
> very relevant to the efforts of the uf community, and
hopefully  
> many of the lessons hard learned over the last few
years developing  
> ufs might benefit the HTML  WG efforts

The HTML Working Group (and the WHATWG, which is continuing
to  
operate in parallel) would welcome participation from
microformats  
experts and advocates.

Regards,
Maciej

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Thanks Maciej,

> HTML5 does have new elements, some of which are mainly
for semantic  
> purposes, but it does not at present have a
<copyright> element.

my bad, no idea where I got that idea from!

> The current proposal does have a predefined
"copyright" class though.

That would be it then.

> The HTML Working Group (and the WHATWG, which is
continuing to  
> operate in parallel) would welcome participation from
microformats  
> experts and advocates.

Which was kind of what I was hinting at 

Mind you, I find the 100 or so emails a week on this mailing
list  
sufficient to keep me occupied, so how to deal with 1000?



j 
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On May 11, 2007, at 3:15 PM, John Allsopp wrote:

> (abbr pattern problems,

Clearly, there's a need for markup for the generic pattern
of marking  
up a triple of data presented to humans, the microformat
class and a  
normalized easy-to-parse representation of the data. HTML5
<time>  
addresses only one instance of this pattern.

The problem with using <abbr> for this pattern is that
title='' is  
intended to be human-readable and the pattern contaminates 

abbreviation data, so with microformats <abbr> is now
less useful for  
e.g. non-microformat-aware but abbr-aware screen readers.

The question that needs to be asked is: Will microformat
producers  
and consumers be willing to migrate to a replacement of the
abbr  
pattern if one is provided or will they continue to use abbr
anyway  
for backwards compat?

For example, should HTML 5 define a uf-data='' attribute as
a common  
attribute such that the value of this attribute would be
considered  
in preference over textContent by microformat consumers? Or
should  
HTML 5 just mitigate the damage to the title attribute by
defining a  
boolean attribute title-is-uf='' for flagging title=''
attributes not  
meant for human consumption?

Is it too late to get rid of this?
<abbr title='uf data'>human data</abbr>

Would this be accepted by the uf community?
<span uf-data='uf data'>human data</span>

If not, would this be backwards-compatible with uf
consumers?
<span title='uf data' title-is-uf>human
data</span>

> even with ufs no one uses profiles so HTML 5 should get
rid of  
> them ...)

We already got rid of profile='' before the W3C adopted the
draft.  
There may be some pressure to put it back due to theoretical
 
considerations. This is part of the Descriptivist vs.
Prescriptivist  
debate. It looks pretty obvious that microformat consumers
experience  
more practical benefit when they ignore profile=''.

-- 
Henri Sivonen
hsivoneniki.fi
http://hsivonen.iki.fi/


_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On May 13, 2007, at 3:13 AM, Henri Sivonen wrote:
> On May 11, 2007, at 3:15 PM, John Allsopp wrote:
>
>> (abbr pattern problems,
>
> Clearly, there's a need for markup for the generic
pattern of  
> marking up a triple of data presented to humans, the
microformat  
> class and a normalized easy-to-parse representation of
the data.  
> HTML5 <time> addresses only one instance of this
pattern.

I'm not sure it's clear that we need a general mechanism.
AFAIK, the  
only real problem is with datetime fields. Everything else
seems to  
work pretty well now.

> The problem with using <abbr> for this pattern is
that title='' is  
> intended to be human-readable and the pattern
contaminates  
> abbreviation data, so with microformats <abbr> is
now less useful  
> for e.g. non-microformat-aware but abbr-aware screen
readers.
>
> The question that needs to be asked is: Will
microformat producers  
> and consumers be willing to migrate to a replacement of
the abbr  
> pattern if one is provided or will they continue to use
abbr anyway  
> for backwards compat?

There's no way that we'll get 100% of microformat producers
to switch  
to the new mechanism, but with advocacy we can get a large
number to  
upgrade. If producers switch so will consumers (and I'll put
it in  
the test suite, too ).

> For example, should HTML 5 define a uf-data=''
attribute as a  
> common attribute such that the value of this attribute
would be  
> considered in preference over textContent by
microformat consumers?  
> Or should HTML 5 just mitigate the damage to the title
attribute by  
> defining a boolean attribute title-is-uf='' for
flagging title=''  
> attributes not meant for human consumption?

I don't think so. This fails to solve a specific problem
(solves a  
general problem that I'm not sure we need to solve). It also
 
encourages hiding data, which is Not a Good Thing(tm).

> Is it too late to get rid of this?
> <abbr title='uf data'>human data</abbr>

Like I said, we probably won't be able to upgrade 100% of
the data in  
the wild, so consumers will still have to support it, but we
can  
probably get a lot.

> Would this be accepted by the uf community?
> <span uf-data='uf data'>human data</span>

Like I said, we should focus on specific problems and
solutions, of  
which <time> does a great job of solving the the
datetime-in-abbr- 
title issue.

> If not, would this be backwards-compatible with uf
consumers?
> <span title='uf data' title-is-uf>human
data</span>

Consumers would all have to be updated. So while it's
backwards  
compatible with existing content, it isn't future compatible
(if you  
started publishing this before consumers were updated, your
content  
would not be handled correctly).

-ryan


_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss