On 5/1/07, Andy Mabbett [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Dan Champion [EMAIL PROTECTED]
writes
If the aim is to retain the data in the body, yet render it invisible
to all users, including those of assistive technologies, what about
using a comment as the data container:
On 4/30/07 5:20 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED] wrote:
span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD Month/span
I'm guessing not, due to invalid characters.
Worse, it hides data in the *rel* attribute which is an anti-design-pattern,
as is putting data in the *class*
On 4/30/07 6:20 PM, James Craig [EMAIL PROTECTED] wrote:
but this battle has been fought and
lost before. If you want to mount another advance, my +1 will be
right behind you, but my morale in the fight will not be very high.
The target is very well-entrenched.
Namespaced content on the Web
On 01/05/2007 07:26, Tantek Çelik wrote:
It's been tried by numerous groups, before microformats, and after. It's
even been tried in the context of RSS and RDF, and in practice people write
scrapers that look for namespace prefixes as if they are part of the element
name, not as mere shorthands
Tantek Çelik wrote:
On 4/30/07 5:20 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED] wrote:
span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD Month/span
I'm guessing not, due to invalid characters.
Worse, it hides data in the *rel* attribute which is an anti-design-pattern,
as is putting
Jon Gibbins (dotjay) wrote:
Tantek Çelik wrote:
On 4/30/07 5:20 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED]
wrote:
span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD
Month/span
An alternative would be to reference a unique meta element in the
document head.
Also bad - requiring
Dan Champion wrote:
If the aim is to retain the data in the body, yet render it invisible to
all users, including those of assistive technologies, what about using a
comment as the data container:
span class=dtstart!--MMDDTHHMMSSZ+HHMM--DD Month/span
This may be totally off the mark and
On 5/1/07 1:01 AM, Ian Davis [EMAIL PROTECTED] wrote:
On 01/05/2007 07:26, Tantek Çelik wrote:
It's been tried by numerous groups, before microformats, and after. It's
even been tried in the context of RSS and RDF, and in practice people write
scrapers that look for namespace prefixes as if
Hello Tantek,
I think Ian may have meant... what about using (for Microformats)
namespaces with pre-defined (and never changing) namespace prefixes
(like in Java and Perl), instead of variable namespace prefixes (like
in XML).
See ya
On 5/1/07, Tantek Çelik [EMAIL PROTECTED] wrote:
On 5/1/07
On 5/1/07 9:03 AM, Charles Iliya Krempeaux [EMAIL PROTECTED]
wrote:
Hello Tantek,
I think Ian may have meant... what about using (for Microformats)
namespaces with pre-defined (and never changing) namespace prefixes
(like in Java and Perl), instead of variable namespace prefixes (like
in
Tantek Çelik wrote:
If you want to carry on a theoretical discussion of namespaces,
please do so
elsewhere, for in practice, discussing them is a waste of time, and
off-topic for microformats lists.
Namespacing is not off-topic for Microformats. Note the hAudio proposal.
On 01/05/2007 17:03, Charles Iliya Krempeaux wrote:
Hello Tantek,
I think Ian may have meant... what about using (for Microformats)
namespaces with pre-defined (and never changing) namespace prefixes
(like in Java and Perl), instead of variable namespace prefixes (like
in XML).
Yes. Of
In message [EMAIL PROTECTED], Dan Champion [EMAIL PROTECTED]
writes
If the aim is to retain the data in the body, yet render it invisible
to all users, including those of assistive technologies, what about
using a comment as the data container:
span class=dtstart!--MMDDTHHMMSSZ+HHMM--DD
Ian Davis wrote:
On 01/05/2007 17:03, Charles Iliya Krempeaux wrote:
Hello Tantek,
I think Ian may have meant... what about using (for Microformats)
namespaces with pre-defined (and never changing) namespace prefixes
(like in Java and Perl), instead of variable namespace prefixes (like
in
On 5/1/07 11:26 AM, James Craig [EMAIL PROTECTED] wrote:
Tantek Çelik wrote:
If you want to carry on a theoretical discussion of namespaces,
please do so
elsewhere, for in practice, discussing them is a waste of time, and
off-topic for microformats lists.
Namespacing is not off-topic
I don't want to get anyone's hopes up but there's an interesting
comment from Lawrence Meckan on the WaSP blog post:
http://www.webstandards.org/2007/04/27/haccessibility/#comment-57838
He's getting good results from up-to-date screen readers with advance
verbosity settings and this little
I've been following this thread with some interest, and I have a
question: what is the ideal amount of human interface with machine-
readable content (when different from human-readable content) in
microformats? In visual browsers, the current common interface is a
minimal readability of
Jeremy Keith wrote:
I don't want to get anyone's hopes up but there's an interesting comment
from Lawrence Meckan on the WaSP blog post:
http://www.webstandards.org/2007/04/27/haccessibility/#comment-57838
He's getting good results from up-to-date screen readers with advance
verbosity
Patrick H. Lauke wrote:
Jeremy Keith wrote:
snip
If there's a chance that adding an extra span inside the abbr element somehow
helps screen readers, then that should probably be included in the test cases:
http://microformats.org/wiki/assistive-technology-abbr-results
Like I said, we
Jon Gibbins wrote:
We can use rel on links, but could rel be used to permit something
like this on a span:
span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD
Month/span
Hi John, I'm glad you mentioned this. It's been discussed before and
shot down given the reference, namespaces
On Apr 30, 2007, at 8:20 PM, James Craig wrote:
We can use rel on links, but could rel be used to permit something
like this on a span:
span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD
Month/span
Hi John, I'm glad you mentioned this. It's been discussed before
and shot down given
Andy Mabbett wrote:
Tantek Çelik 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
Jeremy Keith 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
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
Absalom Media wrote:
Although in all my testing on this issue, the date-time-pattern still
announced the date correct (at least for hAtom, with dashes and
colons)
in terms of screenreader testing (JAWS 8 at advanced verbosity, Window
Eyes 6 and Firevox).
I'm still somewhat confused as to
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:
On 4/28/07, Jeremy Keith [EMAIL PROTECTED] 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
Le 29 avr. 2007 à 02:53, Tantek Çelik a écrit :
However, I'm against contorting microformats because of bugs or
suboptimal
behaviors in 1% marketshare browsers.
Reading loudly the content of title attribute is *not* a bug or
suboptimal behavior for a vocal browser.
That would be
Tantek Çelik wrote:
However, I'm against contorting microformats because of bugs or
suboptimal behaviors in 1% marketshare browsers.
On my reading of the HTML 4.01 specification and WCAG 1.0, the title
attribute was clearly intended to provide additional /human readable/
information:
Welcome to microformats-discuss Benjamin!
On 4/29/07 3:14 PM, Benjamin Hawkes-Lewis [EMAIL PROTECTED]
wrote:
Tantek Çelik wrote:
However, I'm against contorting microformats because of bugs or
suboptimal behaviors in 1% marketshare browsers.
On my reading of the HTML 4.01 specification
Tantek Çelik wrote:
Certainly formatted for machines and *unreadable* to people would be yes,
e.g. a datetime in pure binary, or even just an integer such as seconds
since 1970-01-01T00:00Z.
ISO8601 dates (and datetimes) are actually quite readable for many people
(e.g. it might have taken you
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.
One of the
On 4/28/07 3:16 AM, Jeremy Keith [EMAIL PROTECTED] 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
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
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] 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
Andy Mabbett wrote:
For the benefit of new list members, the IRC logs are at:
http://rbach.priv.at/Microformats-IRC/
The discussion referred to begins at:
http://rbach.priv.at/Microformats-IRC/2007-04-27#T154600
Cheers Andy.
I'm sorry, but this comment is revealing
tantek
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
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
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
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,
On 4/28/07 1:33 PM, Andy Mabbett [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Tantek Çelik
[EMAIL PROTECTED] 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
Bringing, for discussion, a proposal from the WaSP ATF co-lead in
response to today's article.
http://www.webstandards.org/2007/04/27/haccessibility/#comment-57820
Patrick Lauke wrote:
so, looking at some “harmonisation” ideas then, what i would
suggest a way forward may be:
1) heavily
42 matches
Mail list logo
