Re: [uf-discuss] Best practice for the abbr pattern

[Dan Champion]

James Craig wrote:

Dan Champion wrote:


Webadmin - Tenbus wrote:

Mike Kaply wrote:

Both upcoming and eventful do not have dashes in their dates.
They will need to be evangelized.

Wikevent.org's got it right 
 we don't need 
evangelising ;-)


Ditto for Revish - 
http://www.revish.com/reviews/090613725X/danchamp/   :-)


You guys are missing the point.


I'm well aware of the point of the broader discussion. You missed the 
point of my post (and I imagine Spike's) which was to show some 
immediate support for the interim suggestion that Tantek and others have 
endorsed.


I felt it important to demonstrate that the discussion here is of some 
practical consequence and is being listened to by those of us actively 
promoting microformats in the field, and who are also painfully aware of 
the accessibility issues: Bruce Lawson and I had a brief chat about 
microformat "abuse" of abbr while he was (presumably) working with you 
to highlight the issue.


Do you talk that way? 


Yes, actually. I'm not the most effective communicator in any space.

Let's not side-track the discussion though. As a solution emerges I will 
continue to adopt it as I see fit, but will think twice about 
publicising that effort through this channel.


Cheers,

Dan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] changing abbr-design-pattern to title-design-pattern?

[James Craig]

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 editing the page in the microformats wiki about abbr- 
design-pattern to quite clearly state that, because of abbr’s  
semantics, which assistive technologies like screen readers rely  
upon, the pattern should only ever be used if the machine-readable  
part in the title is also very clearly human-readable (and by that  
we don’t mean somebody who’s into geocaching and therefore loves to  
hear lat and long, or somebody who really likes their time to be  
read out in full ISO format).


2) introducing a new design pattern page…i’d call it the title- 
design-pattern. this can show pretty much what the current abbr- 
design-pattern page has, just with a variety of other elements  
(like span, div, p, object) and a clear warning that this pattern  
should not be used with elements where title has been given  
slightly “special” meaning and/or are used by current AT. should  
also include a note that this replaces the abbr pattern of old, and  
that abbr-design-pattern in its new form is a very limited subset  
of the title-design-pattern


3) trawling the rest of the microformats wiki to remove examples of  
problematic abbr-design-pattern use and replace them with more  
generic title-design-pattern examples


I would emphasize that we should indicate title-design-pattern should  
not be used to hide human-readable data, but only be used in the  
problem cases where the data is not human readable, or in i18n cases,  
where the human readable version is in another language. 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:


Uses title value:
Noon  
Central


Does not use title value:
http://example.com/"; class="fn org url" title="Visit the  
company web site!">Widgets, Inc.


Thoughts?
James


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, James Craig
<[EMAIL PROTECTED]> writes

>You guys are missing the point. Do you talk that way?
>
>Is anyone gonna be in thirty point three. Dash ninety-seven point
>seventy-five anytime soon? I should be there at two thousand seven  six
>nine tee fifteen thirty zero zero dash six o'clock.

It gets worse:

April 22, 1997

Since when was "twenty-second" an abbreviation of "23"?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[James Craig]

Dan Champion wrote:


Webadmin - Tenbus wrote:

Mike Kaply wrote:

Both upcoming and eventful do not have dashes in their dates.
They will need to be evangelized.

Wikevent.org's got it right  we don't need evangelising ;-)


Ditto for Revish - http://www.revish.com/reviews/090613725X/ 
danchamp/   :-)


You guys are missing the point. Do you talk that way?

Is anyone gonna be in thirty point three. Dash ninety-seven point  
seventy-five anytime soon? I should be there at two thousand seven  
six nine tee fifteen thirty zero zero dash six o'clock.


Explanation: Austin, Texas, USA on June 9th at 3:30PM in spoken ISO  
(2007-06-09T15:30:00-06:00) and rounded Geo (30.300474;-97.747247).


James

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[James Craig]

Dr. Ernie Prabhakar wrote:


title="2007-03-12T17:00:00"


Can you confirm that:
a) This will in fact solve the screen reader problem


It will not. Though I agree with Jeremy and Tantek that this solution  
is slightly better than the current recommendation. It is still far  
from accessible. Tantek and I discussed this format at SXSW as a  
possible solution, but its only moderately helps for dates, and  
doesn't help much for datetimes:


"2007-04-27" is mostly accessible as it's usually read as either "two  
thousand seven. four. twenty-seven." or "two thousand seven dash four  
dash twenty-seven." Sometimes the leading zero is spoken, too.


It's important to note however, that everything past the T is usually  
gibberish. Even given the *ideal* situation where the ':'s are not  
spoken as "colon", the time zone delimiter is spoken as "minus", and  
the colon separated pairs are spoken as "o'clock," the result is  
still less than ideal.


T12:00:00-06:00
Best case scenario "tee twelve o'clock zero zero minus six o'clock."
Worst case scenario: "tee one two colon zero zero colon zero zero  
dash zero six colon zero zero"


This also doesn't account for screen readers set to read in other  
languages. Besides pronunciation phonemes, reader languages have all  
sorts of rules for writing conventions (i.e. sometime speaking "five  
o'clock" for "5:00" in English). I can't begin to guess what problems  
that that would entail. We'd need to talk to the internationalization  
team at the manufacturers.


I can try to meet with the i18n people on the Voiceover team, but as  
today, Voiceover doesn't read any title attributes and so doesn't  
have an issue with abbr-design-pattern. The problem is with the more  
popular readers, Jaws and Window Eyes.



b) This still conforms with all the relevant W3C recommendations


It conforms to the ISO spec for dates, and the W3C specs for markup,  
but the article points to a WCAG reference that indicates abbr 
[title], acronym[title], td[abbr], and th[abbr] are meant for  
speaking. Ex. "20 lbs" should be spoken "twenty pounds." This is not  
implied for other elements like span[title], em[title], etc.


The article proposes keeping abbr-design-pattern for uses such as:

JP

But abolishing its misuse in the following: dates, long/lat, and RFC  
type values.


Noon Centralabbr>

Austin
Casa

Cheers,
James

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] User Interface for Firefox/Operator

[Charles Iliya Krempeaux]

Hello Mike,

Is this going to be replacing XUL, XBL, etc etc?


See ya

On 4/27/07, Mike Kaply <[EMAIL PROTECTED]> wrote:

If anyone is interested in helping define the user interface for
microformat in Firefox 3 and Operator, we're trying to have a
discussion at:

https://labs.mozilla.com/forum/index.php/topic,77.0.html

I'm open to any and all opinions/suggestions.

Thanks

Mike Kaply




--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Dan Champion]

Webadmin - Tenbus wrote:

Mike Kaply wrote:

Both upcoming and eventful do not have dashes in their dates.

They will need to be evangelized.

Mike

Wikevent.org's got it right 
 we don't need 
evangelising ;-)


Spike


Ditto for Revish - http://www.revish.com/reviews/090613725X/danchamp/   :-)

Dan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Expanding the abbr pattern

[Aaron Gustafson]

[EMAIL PROTECTED] wrote:
>>> Jeremy wrote:
 The simplest solution is to simply expand the pattern to allow the
 same usage of class and title on elements other than abbr (span is
 specifically mentioned but this would potentially apply to any
 element). . I'd be interested in hearing other arguments
 for or against this idea. 
>>> 
>>> I have another one for.  This isn't from a screen reader
>>> perspective, but an IE perspective.
>>> 
>>> Because IE doesn't support the abbr element it is very difficult to
>>> target anything written using the abbr design pattern with CSS.
>> 
>> This is no longer true.  IE7 supports the abbr element.
> 
> Sorry, I meant to say IE6, not IE in general.
> 
>>> If we could use, say, a span this would solve that problem.
>> 
>> If you must have pixel-perfect rendering for your content/site in
>> older browsers that don't support abbr, and you need abbr-specific
>> styling, then yes, a workaround is to add a  element as a
>> styling hook for those older browsers.  However we MUST NOT
>> compromise microformats for browsers that failed to implement *an
>> entire HTML4 element*. 
> 
> Agreed. However, not being able to style an entire element in
> a browser that still has the lion's share of the market is a
> real pain in the behind.  I don't need a pixel-perfect
> rendering, but some control would be nice without CSS
> calisthenics.  Maybe we should just evangelize FF and/or IE7 more.

You could also use Dean Edwards' IE7 scripts [1] and deliver them via
conditional comments to IE6 and under. They add support for ABBR to IE6.
Then you will cover IE7 + all IE6 and under with JS support and can go on
about your business.

[1] http://dean.edwards.name/IE7/compatibility/

It isn't a perfect solution, for sure, but will likely get you 70-80% of the
way there, which is pretty good (and perhaps the best we can hope for).

Cheers,

Aaron


Aaron Gustafson
Easy! Designs, LLC
http://www.easy-designs.net
http://www.easy-reader.net 

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] hCard names - n vs. fn

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, Ciaran
McNulty <[EMAIL PROTECTED]> writes

>On a side-note, the issue of what to do with user-entered names where
>one isn't sure of the formatting is one I've also had issues with and
>could do with some attention - for now hCard is only going to be
>useful in applications where the author has the users' names split
>into the relevant fields and for me it's a major stumbling block.

In the case I cited, there are three template fields:

honorific-prefix
name
honorific suffix

given that, in any individual case, the makeup of the name field is
unknown, and could be:

FirstName Surname

FirstName "Nickname" Surname

FirstName MiddleName Surname

FirstName Surname Surname

FirstName MiddleName Surname Surname

EasternFamilyName EasternGivenName

or even:

OneWordName

how would people suggest applying name-related hCard properties?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Webadmin - Tenbus]

Mike Kaply wrote:

Both upcoming and eventful do not have dashes in their dates.

They will need to be evangelized.

Mike

Wikevent.org's got it right 
 we don't need 
evangelising ;-)


Spike

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] User Interface for Firefox/Operator

[Mike Kaply]

If anyone is interested in helping define the user interface for
microformat in Firefox 3 and Operator, we're trying to have a
discussion at:

https://labs.mozilla.com/forum/index.php/topic,77.0.html

I'm open to any and all opinions/suggestions.

Thanks

Mike Kaply
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Mike Kaply]

Both upcoming and eventful do not have dashes in their dates.

They will need to be evangelized.

Mike
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Jeremy
Keith <[EMAIL PROTECTED]> writes

>title="20070312T17"
[...]
>can also be written with dashes and colons like  this:
>
>title="2007-03-12T17:00:00"

>Would everyone agree that, for the sake of screen reader users, we
>should update the wiki to strongly encourage this more verbose  version
>of datetimes and strongly discourage the contracted version?

Yes; but I suspect that, from an accessibility PoV, the most we can say
of the latter is that it's the lesser of two evils.

I would also suggest raising the matter on forums used by blind (and
other) people who use text readers - Accessify being one such forum:



-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] evangelizing browsers: modern, with microformats plugins, & especially with built-in microformats support

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>Even more so, we should evangelize browsers that have plugins and
>extensions for microformats.
>
>And most of all, browsers that have built-in support for microformats.

Other than FireFox, what browsers do? Are there any moves to offer
microformat add-ons for Opera, for instance?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Dr. Ernie
Prabhakar <[EMAIL PROTECTED]> writes

>On Apr 27, 2007, at 11:21 AM, Andy Mabbett wrote:
>> In message <[EMAIL PROTECTED]>, Dr. Ernie
>> Prabhakar <[EMAIL PROTECTED]> writes
>>
 That's a point-of view, but not a definitive fact. Who says it's
 not a microformat? With what authority?
>>>
>>> Um, is there any authority you *would* accept for that usage?
>>
>> It doesn't matter what I do, or would, accept; it's what the wider
>> public would accept which is at issue.
>
>Well, that's the experiment we are currently performing: to see
>whether we (the microformats.orf community) can encourage the outside
>world to accept our definitions of microformats vs. POSH and semantic
>HTML.  You may not think we'll succeed, but I don't see that as a
>reason not to try.

Perhaps; but then my original post on this mater was to challenge a post
which appeared to imply we'd already succeeded.

It may also be wise to consider whether what we are offering is more or
less likely to be accepted, than an alternative offer we could be making
- we may only get one bite at that particular cherry.

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Copyright concerns (was: XFN - Professionals Network microformat)

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, Brian
Suda <[EMAIL PROTECTED]> writes

>> It's not about whether they are behind the times or not - the really big
>> problem in the ambiguous copyright and patent statements, compounded by
>> the prevention of making derivative works, etc.
>
>--- is this a REAL problem, or do people keep bring this up as a
>THEORETICAL issue?

It's real; I've already given the example of eBay.

(cross-posted; please reply on Microformats Discuss)

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] evangelizing browsers: modern, with microformats plugins, & especially with built-in microformats support

[Tantek Çelik]

On 4/27/07 11:32 AM, "John Beales" <[EMAIL PROTECTED]> wrote:

> Maybe we should just
> evangelize FF and/or IE7 more.

We should evangelize modern browsers yes, and upgrades accordingly as they
help users make better use of microformats, and help content authors more
easily publish microformats.

Even more so, we should evangelize browsers that have plugins and extensions
for microformats.

And most of all, browsers that have built-in support for microformats.

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)

[Dr. Ernie Prabhakar]

Hi Andy,

On Apr 27, 2007, at 11:21 AM, Andy Mabbett wrote:

In message <[EMAIL PROTECTED]>, Dr. Ernie
Prabhakar <[EMAIL PROTECTED]> writes


That's a point-of view, but not a definitive fact. Who says it's
not a microformat? With what authority?


Um, is there any authority you *would* accept for that usage?


It doesn't matter what I do, or would, accept; it's what the wider
public would accept which is at issue.


Well, that's the experiment we are currently performing: to see  
whether we (the microformats.orf community) can encourage the outside  
world to accept our definitions of microformats vs. POSH and semantic  
HTML.  You may not think we'll succeed, but I don't see that as a  
reason not to try.


-- Ernie P.


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Expanding the abbr pattern

[John Beales]

> Jeremy wrote:
>> The simplest solution is to simply expand the pattern to allow the
>> same usage of class and title on elements other than abbr (span is
>> specifically mentioned but this would potentially apply to any element).
> .
>> I'd be interested in hearing other arguments for or against this idea.
>
> I have another one for.  This isn't from a screen reader perspective,
> but an IE perspective.
>
> Because IE doesn't support the abbr element it is very difficult to
> target anything written using the abbr design pattern with CSS.

This is no longer true.  IE7 supports the abbr element.


Sorry, I meant to say IE6, not IE in general.


> If we could use, say, a span this would solve that problem.

If you must have pixel-perfect rendering for your content/site in older
browsers that don't support abbr, and you need abbr-specific styling, then
yes, a workaround is to add a  element as a styling hook for those
older browsers.  However we MUST NOT compromise microformats for browsers
that failed to implement *an entire HTML4 element*.


Agreed. However, not being able to style an entire element in a
browser that still has the lion's share of the market is a real pain
in the behind.  I don't need a pixel-perfect rendering, but some
control would be nice without CSS calisthenics.  Maybe we should just
evangelize FF and/or IE7 more.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>> b) This still conforms with all the relevant W3C recommendations
>
>ISO8601 is an ISO standard, not W3C.

I rather suspect that this was a reference to the WCAG-WAI
recommendations, not to any date-related format.

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Tantek Çelik]

On 4/27/07 11:11 AM, "David Mead" <[EMAIL PROTECTED]> wrote:

> Putting hyphens/dashes in between the integers sounds like a good idea
> to me.  I do that for most file names that need a date, so personally
> I'm on board.
> 
> I'd be really interested in seeing if this does have an impact on the
> screen readers output at some point.
> 
> It's definitely worth updating the Wiki to reflect the encouragement.

I too concur.  I'm going to update the examples in hCalendar immediately and
I propose making dashes and colons separators a SHOULD for content authors,
based on the real world evidence presented by the accessibility community.

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Dr. Ernie
Prabhakar <[EMAIL PROTECTED]> writes

>> That's a point-of view, but not a definitive fact. Who says it's
>>not a microformat? With what authority?
>
>Um, is there any authority you *would* accept for that usage?

It doesn't matter what I do, or would, accept; it's what the wider
public would accept which is at issue.

>The "common usage" on this list is that "microformats" is best  applied
>that markup which follows the microformat process:
>
>> http://microformats.org/wiki/process
>
>and that other forms of semantic markup should be referred to as
>"semantic HTML" or POSH.

Indeed - but again, it's what happens *outside* this list which is at
issue.

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[David Mead]

Hi Jeremy,

Putting hyphens/dashes in between the integers sounds like a good idea
to me.  I do that for most file names that need a date, so personally
I'm on board.

I'd be really interested in seeing if this does have an impact on the
screen readers output at some point.

It's definitely worth updating the Wiki to reflect the encouragement.

Dave

On 4/27/07, Jeremy Keith <[EMAIL PROTECTED]> wrote:

This is another response to the WaSP post about screen reader issues
with the abbr pattern:
http://www.webstandards.org/2007/04/27/haccessibility/

As I pointed out in a comment on the post, their example uses the
condensed form of the datetime, e.g.:

title="20070312T17"

This currently causes problems for screen readers as they attempt to
read the numbers as one long string.

However, the datetime can also be written with dashes and colons like
this:

title="2007-03-12T17:00:00"

http://microformats.org/wiki/datetime-design-pattern

Would everyone agree that, for the sake of screen reader users, we
should update the wiki to strongly encourage this more verbose
version of datetimes and strongly discourage the contracted version?

Some test results can be found here:
http://dotjay.co.uk/tests/screen-readers/date-time/#test-microformats

Bye,

Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Expanding the abbr pattern

[Tantek Çelik]

On 4/27/07 10:18 AM, "John Beales" <[EMAIL PROTECTED]> wrote:

> Jeremy wrote:
>> The simplest solution is to simply expand the pattern to allow the
>> same usage of class and title on elements other than abbr (span is
>> specifically mentioned but this would potentially apply to any element).
> .
>> I'd be interested in hearing other arguments for or against this idea.
> 
> I have another one for.  This isn't from a screen reader perspective,
> but an IE perspective.
> 
> Because IE doesn't support the abbr element it is very difficult to
> target anything written using the abbr design pattern with CSS.

This is no longer true.  IE7 supports the abbr element.

http://msdn2.microsoft.com/en-us/library/ms649487.aspx


> If we could use, say, a span this would solve that problem.

If you must have pixel-perfect rendering for your content/site in older
browsers that don't support abbr, and you need abbr-specific styling, then
yes, a workaround is to add a  element as a styling hook for those
older browsers.  However we MUST NOT compromise microformats for browsers
that failed to implement *an entire HTML4 element*.


Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Tantek Çelik]

On 4/27/07 10:47 AM, "Dr. Ernie Prabhakar" <[EMAIL PROTECTED]>
wrote:

> Hi Jeremy,
> 
> On Apr 27, 2007, at 9:49 AM, Jeremy Keith wrote:
>> However, the datetime can also be written with dashes and colons
>> like this:
>> 
>> title="2007-03-12T17:00:00"
>> 
>> http://microformats.org/wiki/datetime-design-pattern
>> 
>> Would everyone agree that, for the sake of screen reader users, we
>> should update the wiki to strongly encourage this more verbose
>> version of datetimes and strongly discourage the contracted version?
> 
> Can you confirm that:
> 
> a) This will in fact solve the screen reader problem

That's much too big a request ;)

It's also unnecessary.

As long as there is improvement, it is worth the change.

And the improvement is reading it as "two thousand seven [pause] three
[pause]... " etc. rather than  "twenty million ...".



> b) This still conforms with all the relevant W3C recommendations

ISO8601 is an ISO standard, not W3C.

That being said, the W3C *note* (not recommendation) date and time which is
a profile (subset) of ISO8601:

http://www.w3.org/TR/NOTE-datetime

actually recommends using the "-" and ":" separators explicitly.

I will add an informative reference accordingly to hCalendar for better
reference findability.


> If so, then I'd agree with you, as the hyphenated version is also
> more human-readable, and thus seems in keeping with microformat
> philosophy.

Yes the "hyphenated date is more human readable than unhyphenated" argument
has been before, and as you say, is preferred per microformat principles.

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Best practice for the abbr pattern

[Dr. Ernie Prabhakar]

Hi Jeremy,

On Apr 27, 2007, at 9:49 AM, Jeremy Keith wrote:
However, the datetime can also be written with dashes and colons  
like this:


title="2007-03-12T17:00:00"

http://microformats.org/wiki/datetime-design-pattern

Would everyone agree that, for the sake of screen reader users, we  
should update the wiki to strongly encourage this more verbose  
version of datetimes and strongly discourage the contracted version?


Can you confirm that:

a) This will in fact solve the screen reader problem

and

b) This still conforms with all the relevant W3C recommendations


If so, then I'd agree with you, as the hyphenated version is also  
more human-readable, and thus seems in keeping with microformat  
philosophy.


-enp




___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Expanding the abbr pattern

[John Beales]

Jeremy wrote:

The simplest solution is to simply expand the pattern to allow the
same usage of class and title on elements other than abbr (span is
specifically mentioned but this would potentially apply to any element).

.

I'd be interested in hearing other arguments for or against this idea.


I have another one for.  This isn't from a screen reader perspective,
but an IE perspective.

Because IE doesn't support the abbr element it is very difficult to
target anything written using the abbr design pattern with CSS.  If we
could use, say, a span this would solve that problem.

However, I understand the title-abuse issue too.  We seem to be in a dilemma.

John
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Best practice for the abbr pattern

[Jeremy Keith]

This is another response to the WaSP post about screen reader issues  
with the abbr pattern:

http://www.webstandards.org/2007/04/27/haccessibility/

As I pointed out in a comment on the post, their example uses the  
condensed form of the datetime, e.g.:


title="20070312T17"

This currently causes problems for screen readers as they attempt to  
read the numbers as one long string.


However, the datetime can also be written with dashes and colons like  
this:


title="2007-03-12T17:00:00"

http://microformats.org/wiki/datetime-design-pattern

Would everyone agree that, for the sake of screen reader users, we  
should update the wiki to strongly encourage this more verbose  
version of datetimes and strongly discourage the contracted version?


Some test results can be found here:
http://dotjay.co.uk/tests/screen-readers/date-time/#test-microformats

Bye,

Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Expanding the abbr pattern

[Jeremy Keith]

Hi everyone,

Have you seen this post over on the WaSP blog?
http://www.webstandards.org/2007/04/27/haccessibility/

It's a well-reasoned and calm look at the problems caused by the abbr  
pattern in today's screenreaders (though some of the comments are a  
little less calm). Rather than just bitching about this issue, James  
and Craig have proposed some potential solutions.


The simplest solution is to simply expand the pattern to allow the  
same usage of class and title on elements other than abbr (span is  
specifically mentioned but this would potentially apply to any element).


The argument against:

The reason why the abbr pattern currently uses the abbr element is  
because of the semantic power of this element. The HTML spec  
explicitly states the text between the opening and closing tags of  
the abbr element are an abbreviation of the title attribute of that  
element. That is not true of any other element. Using the title  
attribute of an element other than abbr to hold abbreviated content  
could be justifiably considered an abuse of the title attribute:

http://www.w3.org/TR/html401/struct/global.html#h-7.4.3
"This attribute offers advisory information about the element for  
which it is set."


The argument for:

Microformats are a practical, rather than a theoretical, technology.  
They need to work in today's browsers. The abbr pattern isn't working  
in today's screenreaders. I believe this to be a failure on the part  
of the screenreader manufacturers but my beliefs are irrelevant  
(remember: practical trumps theoretical). While restricting this  
pattern to the abbr element is semantically correct, it is  
impractical for today's technology.


I'd be interested in hearing other arguments for or against this idea.

Meanwhile, there's another step we can take now to help mitigate the  
confusion that the abbr pattern can cause in screen readers but I'll  
start another thread for that.


Bye,

Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Fwd: [uf-discuss] Legal implications of using Microformats

[Manu Sporny]

Brian Suda wrote:
> --- if you can give-us any other information, who exactly the company
> is, etc and any other information from the legal team we can attempt
> to work around these problems or debunk the FUD.

Our company is Digital Bazaar, Inc. we provide digital content delivery
services (buying and selling music, TV, film and books online) and want
to use several Microformats in development for Bitmunk as well as
integration into Firefox, Songbird, and Democracy Media Player (we're
currently talking with each team about Microformats).

Bitmunk website:
http://www.bitmunk.com/news/

DB corporate website:
http://www.digitalbazaar.com/

For those of you that don't know where this discussion started - it was
started by Guy Fraser on microformats-new:

http://microformats.org/discuss/mail/microformats-new/2007-April/000241.html

The concern is that there is no standard copyright or patent statement
or policy that applies to the entire Microformats website. Specifically
the examples, formats, brainstorming, proposal, draft and specification
pages have a mix of copyright statements (some not at all). This can
cause problems if an individual authors a Microformat without releasing
copyright or patent claims.

Microformats can stick around in the "draft" process for a long time.
Often they have a statement of "intent" to release it under a certain
copyright/royalty-free licensing model. "Intent to provide under no
restrictions" is very different from "provide under no restrictions".

This could affect anybody implementing Microformats like so:

1. Author pulls together examples, formats, brainstorming, proposal and
draft of a Microformat with "intent" to release royalty-free.
2. Author applies for patent without notifying Microformats community.
3. Invented Microformat gets very popular over the next 2 years.
4. Author decides not to follow through with "intent" and instead
decides to sue for patent infringement. OR Author decides not to
relinquish copyright and becomes a nuisance to the community.

While this will probably not happen, a simple change to the Microformats
wiki can ENSURE that it doesn't happen.

-- manu
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Fwd: [uf-discuss] Legal implications of using Microformats

[Brian Suda]

-- Forwarded message --
From: Manu Sporny <[EMAIL PROTECTED]>
Date: Apr 27, 2007 3:42 PM
Subject: Re: [uf-new] Legal implications of using Microformats
To: "For discussion of new microformats." <[EMAIL PROTECTED]>


Brian, to answer your question -
(from 
http://microformats.org/discuss/mail/microformats-new/2007-April/000242.html)

our company was under the impression
that all of this copyright and patent policy had been worked out. After
speaking with our legal team, it is clear to us that is has not been. We
cannot be first adopters of Microformats unless there is a clear
statement on the Microformats pages stating something to the effect of:

All authors provide these microformat proposals, drafts and
specifications under a cc-by-1.0 or later license (or something to that
effect). All authors do not claim any patent rights to concepts
described in proposals, drafts and specifications.

--- if you can give-us any other information, who exactly the company
is, etc and any other information from the legal team we can attempt
to work around these problems or debunk the FUD.

--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Article about why microformats are cool

[Keith Grennan]

Hi,

I was inspired to write an article about why microformats are cool and
important.  Feel free to take a look.

http://nearlyfree.org/microformats-sip-sea-water

"...there are 14 billion websites, but like the scattered builders of the
tower of Babel, these sites are all speaking different languages. Well,
that's not entirely true - they all speak HTML, but HTML was not
meant to do much beyond describing how a page of information should be
displayed to a human (ideally 32 pixels large, without serifs, pink and
blinking), or declaring that some kind of link between two documents
exists ("Click here to see pictures of my pet mongoose"). So
yes, this system was designed to be able to publish all human knowledge,
but only in a very, very unorganized way, which makes higher-order
functions like categorization, aggregation, and notification very very
difficult. For instance, we need Google, the most powerful supercomputer
brain on the planet, constantly sorting through the muck, just to help
us find things, which it sometimes might do for you, if you're
lucky. But being able to find things, though important, is really only
part of what a useful knowledge system should be able to do. Information
is much more valuable when it is stored in such a way that higher-order
operations on it are possible, and better yet, are easy."

Cheers,
Keith
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)

[Jeremy Keith]

Keith Grennan wrote:

I agree.  I really hope "microformat" won't turn into just another
term for "semantic HTML."  Clear communication is difficult enough
already without additional ambiguity.



I think it already has.

It's like Adobe trying to control how people use the word 'photoshop'.


It certainly seems to be heading that way. But now that we recognise  
this problem (it was discussed quite a bit at the microformats dinner  
in SF recently), we can't try to take steps to help clarify the  
situation. POSH advocacy is a good start. It may be a silly name but  
it's an important step in making it clear that microformats are  
narrowly defined but built on top of semantic markup -- a much wider  
pool:

http://microformats.org/wiki/posh

As the popularity of the term microformat grows, you might have to  
look
for higher ground that's easier to defend.  Because really, who  
wants to

spend their time and energy being language police?


I hope it won't come to that but you're right about the language  
police: I feel like I've spent most of today blogging, leaving  
comments and responding to emails in an attempt to set people  
straight on what does and doesn't constitute a microformat. But like  
I said, at least now that we recognise the problem, we can make a  
concerted effort to deal with it. I hope that work won't be Sisyphean.



ps. I realize that I'm a newcomer to this community, so I hope I'm not
offending anyone.  Hopefully my comments are valuable as an outsider's
first impression.


As an newcomer, your comments are probably the most valuable and  
relevant on this issue. Much appreciated.


Bye,

Jeremy

--
Jeremy Keith

a d a c t i o

http://adactio.com/


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)

[Keith Grennan]

On Thu, Apr 26, 2007 at 07:40:01PM -0500, Scott Reynen wrote:
> On Apr 26, 2007, at 5:54 PM, Dr. Ernie Prabhakar wrote:
> 
> >I realize you may not like that distinction, and we may or may not  
> >have any ability to enforce that, but I think it is only reasonable  
> >for us to attempt to enforce community standards, if only through  
> >peer pressure.
> 
> I agree.  I really hope "microformat" won't turn into just another  
> term for "semantic HTML."  Clear communication is difficult enough  
> already without additional ambiguity.

I think it already has.

It's like Adobe trying to control how people use the word 'photoshop'.

You end up with single interest group that keeps repeating "That thing
your refer to is not actually FooBar - these are the real FooBars over
here".  But no one else cares, because people will use language to suit
their needs.

As the popularity of the term microformat grows, you might have to look
for higher ground that's easier to defend.  Because really, who wants to
spend their time and energy being language police?

Keith

ps. I realize that I'm a newcomer to this community, so I hope I'm not
offending anyone.  Hopefully my comments are valuable as an outsider's
first impression.

> 
> Peace,
> Scott
> 
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)

[Ciaran McNulty]

On 4/26/07, Andy Mabbett <[EMAIL PROTECTED]> wrote:

That's a point-of view, but not a definitive fact. Who says it's not a
microformat? With what authority?


Microformats are the things that are following the process on microformats.org.

The authority presumably comes from whoever made up the term (Tantek?)

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss