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

On 4/28/07 3:16 AM, "Jeremy Keith" <jeremyadactio.com> wrote:

> James Craig wrote:
>> Due to opening up the pattern a bit more, there
will also need to
>> be a flag to indicate when to use title attribute
versus contents.
>> Something like this "useTitle" class:
> 
> No, this smells like a really bad idea. That class is
now an
> instruction for machines.

I concur with Jeremy - this is a really bad idea.

In addition, using span title is less semantic than abbr
title thus it is
undesirable.


To be frank - the blog post on hAccessibility WaSP was
seriously flawed.

1. It used a strawman example to argue against.

2. It recommended known unworkable solutions (using object?
are you kidding
me? that's already been tried and failed - did you not do
your homework? see
my original abbr post, and include-pattern-feedback).  In
addition I told
James Craig *in person* about this at SXSW, so I was a bit
surprised it
still made it to the blog post.


As I wrote on IRC yesterday:

I for one have always tried to push things (browsers,
content) towards at
least being accessibility-friendly, and I still think that's
a good policy.

However, I'm against contorting microformats because of bugs
or suboptimal
behaviors in <1% marketshare browsers.

So I'm for adding "-" and ":" to get a
better and even *usable* result in
screen readers, but I'm against dropping techniques that
expose bugs in <1%
browsers.

I think there needs to be a balance.

On the one hand, being both practical, and frankly,
accessibility-friendly
when we don't have to compromise the standards or semantics
(e.g. abbr vs
span title), hence, my proposal to make use of "-"
and ":" a SHOULD for
content authors in microformats that use the
abbr-date-time-design-pattern.

OTOH, not allowing bugs and stubbornness of implementers to
retard/slow/stop
progress and nor taking a step backward and using span
instead.

In addition I think this is a case where a little bit of
pain now with abbr
and some tools actually opens up the potential for *much*
better
accessibility/usability tools (once UAs actually recognize
ISO dates as such
and can speak/rewrite them for a user's
datetime/language/locality
preferences).  I for one think this tradeoff is more than
reasonable.

Thanks,

Tantek

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

Tantek Çelik wrote:

> In addition I think this is a case where a little bit
of pain now with abbr
> and some tools actually opens up the potential for
*much* better
> accessibility/usability tools (once UAs actually
recognize ISO dates as such
> and can speak/rewrite them for a user's
datetime/language/locality
> preferences).  I for one think this tradeoff is more
than reasonable.

So you don't see the fact that *NO* current UA (particularly
screen 
readers) recognises ISO dates and turns them into fluffy
human readable 
output as a problem? And you're saying that you'd rather
knowingly 
inflict a "little bit of pain" on end users in a
move to force UA 
vendors to change their behaviour to ease that pain? Or am I
misreading 
that part?

P
-- 
Patrick H. Lauke
____________________________________________________________
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.c
om
____________________________________________________________
__
Co-lead, Web Standards Project (WaSP) Accessibility Task
Force
http://webstandards.org/

____________________________________________________________
__
Take it to the streets ... join the WaSP Street Team
http://streetteam
.webstandards.org/
____________________________________________________________
__
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <C258D832.8D1AD%tantekcs.stanford.edu>, Tantek
Çelik
<tantekcs.stanford.edu> writes

>As I wrote on IRC yesterday:
>
>I for one have always tried to push things (browsers,
content) towards
>at least being accessibility-friendly, and I still think
that's a good
>policy.

For the benefit of new list members, the IRC logs are at:

        <http://rba
ch.priv.at/Microformats-IRC/>

The discussion referred to begins at:

        <http://rbach.priv.at/Microformats-IRC/2007-04-27#T15
4600>

and Tantek's specific comment, above, is at:

        <http://rbach.priv.at/Microformats-IRC/2007-04-27#T18
0505>

-- 
Andy Mabbett
            *  Say "NO!" to compulsory ID Cards: 
<http://www.no2id.net/>
            *  Free Our Data:  <http://www.freeourd
ata.org.uk>
            *  Are you using Microformats, yet: <http://microformats.org/
> ?

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

Tantek wrote:
> I concur with Jeremy - this is a really bad idea.

I think we can all agree that the addition of an extra class
for the  
benefit of parsers "smells" bad so we can probably
ditch that  
suggestion.

> In addition, using span title is less semantic than
abbr title thus  
> it is
> undesirable.

Ah, now here's where we differ.

I agree that it is technically less semantic. A title
attribute on an  
abbr element means something different to a title attribute
on any  
other element. I agree that storing machine-readable data in
the  
title attribute of an arbitrary element is less than
ideal...  
although storing machine-readable data in the title
attribute of an  
abbr element has always felt more than a little shady
anyway.

> To be frank - the blog post on hAccessibility WaSP was
seriously  
> flawed.

It's true that the example was extreme--including timezone
info and  
leaving out dashes and colons--but the fundamental point was
still a  
good one.

> I for one have always tried to push things (browsers,
content)  
> towards at
> least being accessibility-friendly, and I still think
that's a good  
> policy.
>
> However, I'm against contorting microformats because of
bugs or  
> suboptimal
> behaviors in <1% marketshare browsers.

Normally I would agree with you here. But the situation with
screen  
readers is somewhat different. We're not talking about a
regular  
browser here: if someone is using a sub-optimal or outdated
web  
browser and they don't get the full benefits, then that's
something  
that can be brushed over but for a blind person using the
most up-to- 
date technology available to have to put up with an
illegible piece  
of data isn't acceptable. In this particular case, the
market share  
numbers are--to my mind--irrelevant.

> I think there needs to be a balance.

I agree completely. And I find the title-design-pattern to
be a good  
compromise.

It's true that it is semantically less correct than the
abbr-design- 
pattern but given that pattern's dubious grounding, it's
probably  
more accurate to refer to the title-design-pattern as
"slightly more  
semantically dubious" rather than "worse."

> In addition I think this is a case where a little bit
of pain now  
> with abbr
> and some tools actually opens up the potential for
*much* better
> accessibility/usability tools (once UAs actually
recognize ISO  
> dates as such
> and can speak/rewrite them for a user's
datetime/language/locality
> preferences).  I for one think this tradeoff is more
than reasonable.

If we were talking about anybody other than screen reader  
manufacturers, I would agree with you. But history has shown
us that  
these people, frankly, don't give a shit.

I've made it very clear (on the WaSP blog post and
elsewhere) that  
microformats represent a huge opportunity for screen reader 

manufacturers. Derek Featherstone gave me goose bumps at the
Web  
Directions conference in Sydney last September when he
mocked up a  
demo of what it might sound like for a screen reader not
just to  
announce the number of links and headings on a page but also
"There  
are X number of contacts and Y number of events on this
page."  
Inspiring stuff! But... in the here and now we have to deal
with the  
current (craptacular) technology that screen reader users
have no  
choice but to use.

In this instance, we could stick by our semantic guns and
say that  
the more semantically correct solution (the title attribute
on abbr)  
is preferable to a slightly less semantic solution (the
title  
attribute on any other element). But I strongly feel that,
in this  
particular case, that would be a grave mistake.

The theory of the abbr-design-pattern is pretty good. The  
practicalities are problematic.

The theory of the title-design-pattern is problematic. The 

practicalities are pretty good.

So what do we choose?

I firmly believe that the strength of microformats lies in
their  
*practical* value. Microformats have always been a
here-and-now  
technology rather than a utopian idea for some future
Semantic Web  
(see: RDF and other noble but failed W3C technologies).

It's a somewhat bitter pill to swallow but I believe that we
need to  
balance the practical and the semantic angles to embedding
machine- 
readable data inside markup and come down on the side of
practicalities.

Therefore, I fully support the title-design-pattern. I don't
believe  
it will be a slippery slope that leads to any semantic
watering-down  
of microformats. I believe it's a necessary step to take to
deal with  
the situation on the ground with screenreaders.

I'd also like to point out one of the beauties of the
proposed title- 
design-pattern: it's completely backwards compatible with
the abbr- 
design-pattern. The abbr-design-pattern uses the title
attribute of a  
*specific* element: the title-design-pattern uses the title
attribute  
of *any* element. abbr is an element therefore the
title-design- 
pattern still applies to the abbr-design-pattern.
Already-implemented  
vevents will still work using the title-design-pattern. It
may be  
that some parsers may have to broaden their range to search
for  
datetimes in the title attribute of any elements but I
wouldn't be  
surprised if current parsers are already being liberal in
what they  
accept.

I'd be interested in hearing if anyone else feels as
strongly as I do  
that the title-design-pattern is something that should
codified as  
soon as possible. I'd be even more interested in hearing if
there's  
anybody, like Tantek, who feels that it's a bad idea... or
to be more  
accurate, who feels that the practical benefits don't
outweigh the  
semantic purity.

Bye,

Jeremy

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/


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

Jeremy Keith wrote:

>> However, I'm against contorting microformats
because of bugs or 
>> suboptimal
>> behaviors in <1% marketshare browsers.
> 
> Normally I would agree with you here. But the situation
with screen 
> readers is somewhat different. We're not talking about
a regular browser 
> here: if someone is using a sub-optimal or outdated web
browser and they 
> don't get the full benefits, then that's something that
can be brushed 
> over but for a blind person using the most up-to-date
technology 
> available to have to put up with an illegible piece of
data isn't 
> acceptable. In this particular case, the market share
numbers are--to my 
> mind--irrelevant.

Also, it strikes me as interesting that the epiphany of
using ABBR for 
storing both human and ISO dates came about mainly because
of the fact 
that the original OBJECT has such poor support in Safari.
Where was the 
"I won't let their laziness/stubbornness stand in the
way of progress" 
attitude back then? Simply marketshare, I guess...

> I'd also like to point out one of the beauties of the
proposed 
> title-design-pattern: it's completely backwards
compatible with the 
> abbr-design-pattern.

That was indeed the idea behind generalising it, yes.

> I'd be interested in hearing if anyone else feels as
strongly as I do 
> that the title-design-pattern is something that should
codified as soon 
> as possible.

I'd raise my hand, but you guessed that already, didn't
you?

P
-- 
Patrick H. Lauke
____________________________________________________________
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.c
om
____________________________________________________________
__
Co-lead, Web Standards Project (WaSP) Accessibility Task
Force
http://webstandards.org/

____________________________________________________________
__
Take it to the streets ... join the WaSP Street Team
http://streetteam
.webstandards.org/
____________________________________________________________
__
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <C258D832.8D1AD%tantekcs.stanford.edu>, Tantek
Çelik
<tantekcs.stanford.edu> writes

>the blog post on hAccessibility WaSP was seriously
flawed
[...]
>2. It recommended known unworkable solutions

Perhaps you missed this part:

        We encourage the Microformats group to consider the
problem,
        whether or not they accept any of the following,
proposed
        solutions.

before the examples and, after them:

        Again, we encourage the Microformats group to
consider the
        problem, whether or not they accept any of the
proposed
        solutions.

despite the fact that both were emboldened.

-- 
Andy Mabbett
            *  Say "NO!" to compulsory ID Cards: 
<http://www.no2id.net/>
            *  Free Our Data:  <http://www.freeourd
ata.org.uk>
            *  Are you using Microformats, yet: <http://microformats.org/
> ?

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

Jeremy,

> I'd be interested in hearing if anyone else feels as
strongly as I  
> do that the title-design-pattern is something that
should codified  
> as soon as possible. I'd be even more interested in
hearing if  
> there's anybody, like Tantek, who feels that it's a bad
idea... or  
> to be more accurate, who feels that the practical
benefits don't  
> outweigh the semantic purity.

I think you have put the case for the generalized pattern
very well,  
in the context of the general philosophies of microformats,
and agree.

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

Tantek Çelik wrote:

> To be frank - the blog post on hAccessibility WaSP was
seriously  
> flawed.
> 1. It used a strawman example to argue against.

What about our example was a straw man? Just yesterday it
was  
mentioned that Yahoo uses dates without dashes and wikevent
was given  
as an example of using the "slightly better dates with
dashes." Let's  
use wikevent's "in the wild" example (that
includes timezones) and  
talk about what happens with the date portion of this ISO
string:  
"2007-05-07T20:00:00+01:00."

I don't have Jaws in front of me, but the time is either
going to be  
read as "twenty o'clock zero zero plus one
o'clock" or as "twenty  
zero zero zero zero plus one o'clock." Both are nearly
useless to  
human ears.

> 2. It recommended known unworkable solutions (using
object? are you  
> kidding
> me? that's already been tried and failed - did you not
do your  
> homework? see
> my original abbr post, and include-pattern-feedback). 
In addition  
> I told
> James Craig *in person* about this at SXSW, so I was a
bit  
> surprised it
> still made it to the blog post.

As Andy pointed out, the point of the article was not the
proposed  
solutions, but I want to point out that your reason for
being hung up  
on the object example is because it was "tried and
failed" due to UA  
implementation bugs. The argument you're making here
completely  
contradicts the argument you make later in this same email
here  
(quoted, but out of order):

> OTOH, not allowing bugs and stubbornness of
implementers to retard/ 
> slow/stop
> progress and nor taking a step backward and using span
instead.

[...]

> However, I'm against contorting microformats because of
bugs or  
> suboptimal
> behaviors in <1% marketshare browsers.

I don't really consider screen readers as
"browsers." People who use  
<1% market share browsers have a choice to change or
upgrade. The  
people who use screen readers really have no other way to
access  
online content. Yes, they could turn off the title attribute
 
verbosity, but this would then cause ambiguity of
understanding  
other, valid uses of abbr.

I doubt you would agree with the following statement:

"I'm against contorting building code regulations to
require  
wheelchairs ramps and elevators in public buildings because
of the  
<1% of citizens with mobility impairments."

> So I'm for adding "-" and ":" to
get a better and even *usable*  
> result in
> screen readers,

I agree with you that the date portion (yyyy-mm-dd) with
dashes,  
though sub-optimal, is better. I told you this in our
discussion at  
SXSW. I also immediately mentioned that's only the case with
dates,  
not datetimes. The complete ISO timecode is gibberish with
or without  
punctuation; I completely deny your claim that it's
"usable."

> I think there needs to be a balance.

I agree. I know we all have the specifications' best
interests in  
mind, and I'm glad it's finally in full discussion.

James


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

Jeremy Keith wrote:

> Microformats have always been a here-and-now technology
rather than  
> a utopian idea for some future Semantic Web (see: RDF
and other  
> noble but failed W3C technologies).

LOL. Poor RDF. There is an RDF thread about the article
going on here:
http://burningbird.net/semanticweb/accessi
bility-microformats-and-rdf- 
as-the-bezoar-stone/

"It could have been worse. It could have been
RDF."

> I'd be interested in hearing if anyone else feels as
strongly as I  
> do that the title-design-pattern is something that
should codified  
> as soon as possible.

+1, but you knew that already. 

James

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

On 4/28/07, Jeremy Keith <jeremyadactio.com> wrote:
> I'd be interested in hearing if anyone else feels as
strongly as I do
> that the title-design-pattern is something that should
codified as
> soon as possible. I'd be even more interested in
hearing if there's
> anybody, like Tantek, who feels that it's a bad idea...
or to be more
> accurate, who feels that the practical benefits don't
outweigh the
> semantic purity.

Can we start a Wikipage, with the alternatives/variants and
listing
their advantages & disadvantages? If there isn't a
pressing crisis:
measure thrice, cut once. Also would be a better place to
record votes
than e-mails.

Regards, etc...
David

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.bl
ogmatrix.com
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss