Comments in-lined below. This message includes responses to
two
messages from the digest.
> Message: 5
> Date: Wed, 14 May 2008 14:38:56 +0100 (BST)
> From: "Toby Inkster" <mail tobyinkster.co.uk>
> Subject: [uf-discuss] Re: One more shot at accessible
hCalendar
> To: microformats-discussmicroformats.org
> Message-ID:
<62483.81.2.120.180.1210772337.squirrelgoddamn.co.uk>
> Content-Type: text/plain;charset=iso-8859-1
>
> Charles Belov wrote:
>
> > Remember that any page these occur on would
presumably have
> a language
> > specification such as "en-us" so
computers would be able to
> deal with
> > standard month and day of week names and
abbreviations.
>
> I'm sorry, but this sounds like a really bad idea.
Parsers
> would need to maintain translation tables for day and
month
> names, plus abbreviations for them, plus some sort of
> heuristic for figuring out the language of the page.
(In
> practice, many authors leave out lang/xml:lang
attributes,
> and Content-Language headers.)
If the web page or RSS feed leaves out the language
attribute, then the
webmaster has not provided sufficient information to the
parser and
cannot be said to have implemented this alternative method.
I do not
expect any scrapers to intuit the origin language.
> Andy Mabbett's proposed "data:" prefix
already solves the
> abbr design pattern accessibility issue and can be
> implemented in just a few lines of code. All we need to
do is
> build support for it into parsers. (Cognition has
supported
> it since alpha2.1.)
>
> Closest thing to a "specification" for the
prefix:
> http://microformats.org/discuss/mail/microformats-
discuss/2008
-February/011583.html
That solution consists of title attribute contains readable
text,
followed by the word "data" followed by the actual
data. The screen
reader software will still read the data out loud, which, on
a page full
of calendar items, would be sheer torture for the listener.
And it still begs the question as to how that data is going
to get into
the page in the first place when a static HTML page is being
created
manually by a non-technical person who has no access to the
title tag.
>
> ------------------------------
>
> Message: 8
> Date: Thu, 15 May 2008 19:57:49 +1000
> From: "Michael MD" <mdagnspraci.com>
> Subject: Re: [uf-discuss] Re: One more shot at
accessible hCalendar
> To: "Microformats Discuss"
<microformats-discussmicroformats.org>
> Message-ID: <002101c8b672$2285cc20$116baccaCOMCEN>
> Content-Type: text/plain; format=flowed;
charset="iso-8859-1";
> reply-type=original
>
> >> Remember that any page these occur on would
presumably
> have a language
> >> specification such as "en-us" so
computers would be able
> to deal with
> >> standard month and day of week names and
abbreviations.
> >
> > I'm sorry, but this sounds like a really bad idea.
Parsers
> would need to
> > maintain translation tables for day and month
names, plus
> abbreviations
> > for them, plus some sort of heuristic for figuring
out the
> language of the
> > page. (In practice, many authors leave out
lang/xml:lang
> attributes, and
> > Content-Language headers.)
>
>
> If machine-readable dates were removed from the
hCalendar
> spec what would be
> the point of using it?
> Accuracy of dates is CRUCIAL for calendar applications
and
> you would not
> want to end up using unreliable heuristics to extract
them!
I'm not sure what computer cannot read "January",
"Jan", "Jan.", "1" or
"01" when surrounded by <span
"dtstartmm"> and </span> and be able to
figure out that it means the first month of the year.
As with the previous post, it still begs the question as to
how that
computer-readable data is going to get into the page in the
first place
when a static HTML page is being created manually by a
non-technical
person who has no access to the title tag.
Anyway, if you don't know what language the calendar item is
in, how are
you going to know whether the plain language description of
the event
needs to be translated? You could wind up displaying a page
full of
events that are perfectly timed but are described in plain
text in 20
different languages. Accurate, but unusable by most
people.
Or you could choose to just show English events. Or just
French. Or
just Chinese. Etc. In which case you would not have to
worry about
multilingual heuristics. I acknowledge you would still have
to worry
about typos.
Hope this helps,
Charles "Chas" Belov
SFMTA Webmaster
http://www.sfmta.com/w
ebmaster
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
