Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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: I'd been thinking about that, too, but, sadly, there is no guarantee that comments will be available to a parser - some CMSs (not least Wikipedia) remove them from the output HTML; as (I've read) do some web proxies, particularly those which compress pages for use on mobile devices or slow connections. I concur, an HTML parser should be allowed to ignore comments, and many will. The similar decision to 'hide' Javascript and other scripting languages inside HTML comments has been widely criticised and is no longer considered best practice in a lot of places, for similar reasons. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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* attribute. Both of these are designed for limited sets of terms/properties, not for data values. Putting data in 'rel' or 'class' is a non-starter. An alternative would be to reference a unique meta element in the document head. Also bad - requiring access to head is a non-starter (many content scenarios forbid head access). And meta, being both invisible and detached from inline content, is ill suited for storing any informantion that has *any* chance of being updated. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 has failed. This has nothing to do with any entrenchment. It's just the sad reality of namespaces. They suck in practice, and no amount of theoretical worship (+1ing etc.) will change that. 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 for namespace URIs. 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. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 for namespace URIs. Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There are many types of non-URI/QName namespacing mechanisms such as Java package name conventions, Perl module conventions etc. Are those offtopic too? 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. Apologies for this post. If the answer to the above is yes then this will be the last from me on this topic. Ian ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 data in the *class* attribute. Both of these are designed for limited sets of terms/properties, not for data values. Putting data in 'rel' or 'class' is a non-starter. As I guessed, rel is only irrelevant for links anyway, so that's no use. Didn't intend to dredge up namespaces if it's already been discussed here and dismissed. My thoughts were really geared towards leveraging the very fact that the datetime data *is* hidden in an attribute using this method or a similar method. While I understand that a key-value pair is expected and desirable, an ISO formatted datetime is not meant for general human consumption - just for über geeks like us. Devising such a mechanism for microformats would surely prove useful? An alternative would be to reference a unique meta element in the document head. Also bad - requiring access to head is a non-starter (many content scenarios forbid head access). And meta, being both invisible and detached from inline content, is ill suited for storing any informantion that has *any* chance of being updated. I guess if we've got microformatted content in a feed, we don't have a head to refer to - good point. Detached is one thing, but you're yet to convince me on the visibility part. Jon -- gr0w.com dotjay.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 access to head is a non-starter (many content scenarios forbid head access). And meta, being both invisible and detached from inline content, is ill suited for storing any informantion that has *any* chance of being updated. I guess if we've got microformatted content in a feed, we don't have a head to refer to - good point. Detached is one thing, but you're yet to convince me on the visibility part. 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 considered a hack, but comments are markup and are parseable. Dan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 considered a hack, but comments are markup and are parseable. As I've mentioned, I would provide context to the datetime in some way, but it's not a bad suggestion in my view: span class=dtstart!--datetime:MMDDTHHMMSSZ+HHMM--DD Month/span Would there be specific difficulties with parsing something like this to extract the microformat data? Jon -- gr0w.com dotjay.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 they are part of the element name, not as mere shorthands for namespace URIs. Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There are many types of non-URI/QName namespacing mechanisms such as Java package name conventions, Perl module conventions etc. Are those offtopic too? This is why I precisely said (in the paragraph that was not quoted), with emphasis added: Namespaced **content** on the Web has failed. AFAIK, Java package name conventions, Perl module conventions are *not* considered *content* that is served on the web. They're code. And they're not served, they're executed server-side. Namespaced **content** has failed because it encourages proprietary siloization of data, rather than interoperability. Namespaces perform a very different function in code (with different needs), despite the cosmetic similarities (use of : etc.). 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. Apologies for this post. If the answer to the above is yes then this will be the last from me on this topic. Why would a discussion of namespaced *code* be *on* topic? How is it relevant to microformats? At a minimum, it would be more appropriate for the microformats-dev list than the microformats-discuss list, but even then I fail to see how it is germane to the domain. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 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 they are part of the element name, not as mere shorthands for namespace URIs. Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There are many types of non-URI/QName namespacing mechanisms such as Java package name conventions, Perl module conventions etc. Are those offtopic too? This is why I precisely said (in the paragraph that was not quoted), with emphasis added: Namespaced **content** on the Web has failed. AFAIK, Java package name conventions, Perl module conventions are *not* considered *content* that is served on the web. They're code. And they're not served, they're executed server-side. Namespaced **content** has failed because it encourages proprietary siloization of data, rather than interoperability. Namespaces perform a very different function in code (with different needs), despite the cosmetic similarities (use of : etc.). 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. Apologies for this post. If the answer to the above is yes then this will be the last from me on this topic. Why would a discussion of namespaced *code* be *on* topic? How is it relevant to microformats? At a minimum, it would be more appropriate for the microformats-dev list than the microformats-discuss list, but even then I fail to see how it is germane to the domain. Tantek -- 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: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 XML). Even fixed namespace prefixes on content have the siloization/balkanization effects and are thus undesirable. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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. http://microformats.org/wiki/grouping-brainstorming#Option_. 233:_Explicit_class-based_grouping div class=haudio grouping.today-podcast.810-interview div class=haudio grouping.today-podcast.the-today-lead-interviews ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 course I understand the distinction between code and content. But I suggested Java and Perl practices as illustrations of conventions for namespacing things. I'm interested in looking at patterns of naming that may allow more decentralised collaboration. Ian ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 Month/span This may be totally off the mark and considered a hack, but comments are markup and are parseable. I'd been thinking about that, too, but, sadly, there is no guarantee that comments will be available to a parser - some CMSs (not least Wikipedia) remove them from the output HTML; as (I've read) do some web proxies, particularly those which compress pages for use on mobile devices or slow connections. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 XML). Yes. Of course I understand the distinction between code and content. But I suggested Java and Perl practices as illustrations of conventions for namespacing things. I'm interested in looking at patterns of naming that may allow more decentralised collaboration. I would also be good to ressurect the page called NamespacesChickenLittling, of which I can see no trace but is referred to in vote-links-faq i.e. For followup QA about VoteLinks and namespaces, see NamespacesChickenLittling. this could probably cover the hAudio namespace useage also. Tim p.s. I'm not sure namespaces can be said to have failed when http://microformats.org has two of them.. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 for Microformats. Note the hAudio proposal. http://microformats.org/wiki/grouping-brainstorming#Option_. 233:_Explicit_class-based_grouping div class=haudio grouping.today-podcast.810-interview div class=haudio grouping.today-podcast.the-today-lead-interviews That is sufficient reason to reject the proposal. Thanks for bringing it to the attention of the list. In addition, that markup example places content in the class attribute which is also unacceptable. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 caveat about the markup: I’ve also expanded the abbr pattern to include a span inside it, essentially duplicating the semantic structure, in order to do a fix for IE6 not styling abbrevations. 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 shouldn't get our hopes but it's certainly worth investigating. 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] changing abbr-design-pattern to title-design-pattern?
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 machine-readable content only while a cursor is hovering over the abbr. Is this middle ground between full readability (e.g. span class=dtstart2007-05-10 23:30:00-06:00/ span) and zero readability (e.g. external RDF) a goal, or an unintended side effect of using abbr? If the latter, I think we should probably focus on potential solutions that would remove this kind of exceptional not-for-human-consumption machine-readable content from both aural and visual browsers. And if the former, we should focus on solutions which simply improve the interface of such content. But I'm not clear on what the goal is here. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 settings and this little caveat about the markup: I’ve also expanded the abbr pattern to include a span inside it, essentially duplicating the semantic structure, in order to do a fix for IE6 not styling abbrevations. 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 shouldn't get our hopes but it's certainly worth investigating. Just spoke quickly to Jon Gibbins on the phone, and he mentioned that it appears to be more of a bug in JAWS due to the use of sIFR (which causes JAWS to sometimes read titles, and sometimes not)...but he'll be testing this further to come to some hard evidence on that. 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.com __ 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 shouldn't get our hopes but it's certainly worth investigating. Just spoke quickly to Jon Gibbins on the phone, and he mentioned that it appears to be more of a bug in JAWS due to the use of sIFR (which causes JAWS to sometimes read titles, and sometimes not)...but he'll be testing this further to come to some hard evidence on that. P Hi all - and thanks, Pat. I've just joined the mailing list and am catching up with the discussions. I'm in the process of running more tests. I'll post results on my test pages and add to the wiki where I can. I've moved my microformats tests and results to a dedicated page here: http://dotjay.co.uk/tests/screen-readers/microformats/datetime-design-pattern/ I'll try to include the test-cases mentioned on the wiki: http://microformats.org/wiki/assistive-technology-abbr-results To comment on the redundant span test-case... A cursory test of that in context on absalom.biz using IE 7 resulted in JAWS behaving strangely. I intend to test this more, but my observations are as follows: JAWS wasn't reading out the title attribute in place of the element's content (a human-readable date) when set to expand abbreviations. Probing the element information (Ins+Shift+F1) didn't report a title attribute on the element. After restarting JAWS and IE 7, the not-so-nice ISO date in the title attribute was read out in place of the human-readable date. The discrepancy seems to have indicated a false positive - the human-readable date was heard when expecting the title expansion to be spoken in its place. I figure it might be something to do with the sIFR in use on the page tested on absalom.biz, as it was causing other issues when reading past the h3 just above the microformatted date. It could be something to do with using the redundant span, but it's unlikely. Jon -- gr0w.com dotjay.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 considered harmful. http://microformats.org/wiki/namespaces-considered-harmful I consider that wiki entry to be an opinion piece. Note the comments such as: 1. Namespaces are actually a *huge* negative. 2. Namespaces encourage people to seclude themselves... 3. Microformats is leveraging the approach that is both working better and frankly dominating in practice on the Web. I would much prefer, namespaced class or rel values to the abuse of abbr[title], and I'd even prefer it to the title-design-pattern we're now proposing as a compromise, 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. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 the reference, namespaces considered harmful. http://microformats.org/wiki/namespaces-considered-harmful I consider that wiki entry to be an opinion piece. The use of namespaces is really irrelevant in this case, as 1) rel is only allowed on a and 2) dates aren't relationships. Adding namespaces wouldn't solve either of those problems. But on the topic of namespaces in general, the web already has semantic initiatives using namespaces, e.g. RDF. Microformats are currently an alternative. Adding namespaces to microformats would remove that alternative. Even if you think namespaces are good, removing alternatives is a bad method of testing theories. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 of the following, proposed solutions. There is one other part Tantek may have missed when he 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. The article also states: The Microformats group is vehemently opposed to hypothetical situations as the basis for a Microformat change. Real-world examples are often requested, or as they commonly phrase it, examples “in the wild.” We remind the Microformats group that real-world screen reader implementations existed, according to spec and “in the wild,” long before the Microformats design patterns, and we encourage the group to respect those real-world implementations, rather than focusing on hypothetical situations... The screen readers may support ISO dates someday argument is a great idea–I will laud it if it happens–but it's completely hypothetical. Surely you can admit that, and if so, maybe you can admit the argument is not a legitmate justification for the datetime- design-pattern, and especially not for the use of abbr-design-pattern in geo. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 machines. Fair enough. Retracted. I would however recommend limiting the very specific classes so that it's not abused to hide data other than specifically machine readable info like the ISO dates and Geo coords. For the record, I believe the machine-readable RFC type vales (home, work, cell, fax, etc.) also fall into this category, mainly for the sake of i18n. The spec now forces them to be visible, yet it does not make sense to force English words to be visible on pages in other languages. Hence the example: abbr class=type title=home xml:lang=esCasa/abbr James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 (-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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 why I've got different results than the ones reported on the WASP post by Jon Gibbons. http://dotjay.co.uk/tests/screen-readers/date-time/#test-microformats Any ideas? Or should I raise this with WaSP? Please do either here, on the WaSP comments, or both. We'd love to know your test results and how they differed. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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/accessibility-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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 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.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 equivalent to say that it is a bug to display the title content in visual browser as just plain text. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ 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?
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: http://www.w3.org/TR/html401/struct/global.html#adef-title http://www.w3.org/TR/html401/struct/text.html#edef-ABBR http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr On this reading, the use of title for information formatted for machines not people is a hack. So I think it's erroneous to describe reading out the ISO date time format from title as a bug. I agree having a setting to recast ISO dates into a localized, human readable format might be an optimal behaviour, but it would be best if such conversion was triggered only in contexts where the ISO format was not meant for direct human consumption. In this sense, describing it as suboptimal behaviour presumes screen reader foreknowledge of microformats, which seems to go against the already quoted credo of the microformats movement. Your interpretation of the relevant specs may be different, of course. :) With regards to the attempt to list screen readers on the microformats wiki, I'd like to draw correspondents attention to the list of past and present screen readers on Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_screen_readers The current microformats wikipage's emphasis on the latest versions is somewhat misplaced. It's important to remember that partly because popular screen reading software is prohibitively expensive, many screen reader users are using older versions. I'm subscribed to several screen reader mailing lists. The latest version of Freedom Scientific's JAWS (probably the most popular screen reader) is 8. But judging from mailing lists dedicated to JAWS and other screen readers, users of 8 are outnumbered by users of 7. Many correspondents are still on 6. Some few correspondents still use 5 or even 4.51, e.g.: http://www.freelists.org/archives/jfw/03-2007/msg00857.html http://www.freelists.org/archives/jaws-uk/03-2007/msg00125.html With web browsers, one might have a moral case for putting the onus on users to upgrade to free and technically superior alternatives, though taking such a moral position appears not to be a widely viable commercial practice. But in the case of screen readers, the free solutions still have a long way to go to be very effective replacements for their expensive peers, so a similar moral argument is difficult to construct. I'm afraid asking for estimates of the size of the userbase for each version is a bit unrealistic. There's very little public information about such matters. The World Health Organization estimated that in 2002, 37 million people around the world (0.59%) were blind and an additional 124 million (1.99%) had low vision: http://www.who.int/gb/ebwha/pdf_files/WHA59/A59_12-en.pdf 3.58% is only a little short of estimates of Safari's market share and much higher than estimates of Opera's: http://marketshare.hitslink.com/report.aspx?qprid=0 Of course, because people with visual impairments are likely to have poorer life opportunities and to be older, I'd guess they are under-represented in uptake of new technologies and the internet generally. In 2002, Chris Hofstader of Freedom Scientific testified that There are approximately 80,000 registered users of JAWS: http://web.archive.org/web/20021015235548/http://www.microsoft.com/presspass/trial/mswitness/2002/hofstader.asp I assume he meant worldwide, but it's hard to be certain. According to a study of screen reader use published in December 2003, a spokesperson for the US National Federation of the Blind estimated that in the USA, JAWS had 65% of the screen reader market and GW-Micro Window-Eyes had 35%; also JAWS was the software most commonly used by U.S. federal workers: http://www.redish.net/content/papers/interactions.html If these figures held true beyond the US, one could predict around 40,000 registered Window-Eyes users worldwide. However, non-US markets may favour other screen readers such as the Brazilian screen reader MicroPower Virtual Vision. In a published interview with Access World in March 2007 that proved controversial and has subsequently disappeared from the site, Hofstader apparently said that 2,000 copies of screen reader software are sold per month: http://blogs.sun.com/korn/date/20070309 Any sale of a Mac is also a sale of VoiceOver, an effective screen reader. Any download of Ubuntu Linux or Solaris is also a download of Orca, an increasingly competent open source screen reader. With regards to the particular issue at hand, it's fortunate that many screen reader users probably have not configured their software to read title automatically since: 1) It's not the default behaviour in JAWS or Window-Eyes. 2) Current screen readers do not (AFAIK) discriminate between familiar and unfamiliar,
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 and WCAG 1.0, the title attribute was clearly intended to provide additional /human readable/ information: http://www.w3.org/TR/html401/struct/global.html#adef-title http://www.w3.org/TR/html401/struct/text.html#edef-ABBR http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr Agreed. On this reading, the use of title for information formatted for machines not people is a hack. 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 a second or two, but I'm sure you were able to parse the previous sentenc) even though they are clearly intended to be easier for machines to read. The point is that human readability and machine readability are not necessarily in opposition/conflict. Often you can get *both*. Sometimes (as with ISO dates) you get something that is mostly or at least somewhat human readable, just so that it *can be* machine readable. One of the microformats principles is humans first, machine second. That doesn't mean machines *never*. It means that microformats *do* still aim to make machine readable formats. So I think it's erroneous to describe reading out the ISO date time format from title as a bug. Depends on the reading. Even words *could* be misread/mispronounced. I agree having a setting to recast ISO dates into a localized, human readable format might be an optimal behaviour, but it would be best if such conversion was triggered only in contexts where the ISO format was not meant for direct human consumption. In this sense, describing it as suboptimal behaviour presumes screen reader foreknowledge of microformats, which seems to go against the already quoted credo of the microformats movement. Just because microformats are designed to work today, that doesn't mean they are restricted to those solutions where *all* behaviors are expected to work today. Microformats work today very simply and immediately for *some* uses, perhaps only even *one* use today. However, by expressing semantics, they are specifically designed to enable and encourage *new* and more intelligent uses. The works today is a minimal bar to be met, not a restriction. Your interpretation of the relevant specs may be different, of course. :) With regards to the attempt to list screen readers on the microformats wiki, I'd like to draw correspondents attention to the list of past and present screen readers on Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_screen_readers Thanks very much for providing this reference. It points out that our goal should NOT be to simply duplicate the work done elsewhere with a comprhensive list of assistive technologies (including screen readers). Rather, since the goal is real world testing of actual microformats content in the wild, we restrict the technologies on that list to those which those in the community have access to, or are in direct communication with someone who has access to. I've noted this on the wiki page so that we can stay focused on actionable research: http://microformats.org/wiki/assistive-technology The current microformats wikipage's emphasis on the latest versions is somewhat misplaced. I just re-read the page and apologize for whatever I wrote that gave that impression. To be clear, I think the key focus here is (quoted from the top of the page) currently known accessibility assistive technologies (implementations) that are being used in the wild In other words, obsolete implementations that are not being used are not worth documenting for our purposes (or certainly doing so should be the lowest priority). It's important to remember that partly because popular screen reading software is prohibitively expensive, many screen reader users are using older versions. I'm subscribed to several screen reader mailing lists. The latest version of Freedom Scientific's JAWS (probably the most popular screen reader) is 8. But judging from mailing lists dedicated to JAWS and other screen readers, users of 8 are outnumbered by users of 7. Many correspondents are still on 6. Some few correspondents still use 5 or even 4.51, e.g.: http://www.freelists.org/archives/jfw/03-2007/msg00857.html http://www.freelists.org/archives/jaws-uk/03-2007/msg00125.html Thanks for that information. I have added those specific versions of JAWS to the wiki: http://microformats.org/wiki/assistive-technology#JAWS If you have additional information such as rough numbers of users, or dates of when those
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 a second or two, but I'm sure you were able to parse the previous sentenc) even though they are clearly intended to be easier for machines to read. The point is that human readability and machine readability are not necessarily in opposition/conflict. Often you can get *both*. I may interject here that there is potentially a distinction to be made between readability and hearability. If assistive technology such as screen readers doesn't know what a certain piece of text/numbers is, it will (and yes, we're organising thorough testing and documentation among WaSP ATF members as we speak) read it out character by character, digit by digit. Imagine if the text of this email was read out to you, not as words, but letter by letter...how much more difficult would it be for you to then understand it? Sure, it's certainly not impossible (you just need to keep mental track of all the characters being read out to you, then mentally form them into words again), but certainly far from ideal in the here and now. The works today is a minimal bar to be met, not a restriction. So then that bar isn't met for screen reader users for the case presented in the WaSP article. In other words, obsolete implementations that are not being used are not worth documenting for our purposes (or certainly doing so should be the lowest priority). Agree completely. But not entirely impossible nor unreasonable. The reality is that software *does* get improved over time. Just the fact that JAWS is up to version 8 demonstrates this, and demonstrates sufficient demand for new versions JAWS that the publishers keep updating it. Therefore there is a case to be made for both encouraging improvements (since history has shown that software does get improved), and clearly there is demand for better software (sufficient to support the market), for encouraging the consumers of such software to demand even better software. However (pending the testing results), in the context of screen readers and the abbr pattern this would be exactly like saying we're going to use object, even though we know safari doesn't play ball with it...as once we demonstrate sufficient demand etc etc safari team will be compelled to update their software. 2) Current screen readers do not (AFAIK) discriminate between familiar and unfamiliar, or even first-occurrence and repeated, abbreviations and acronyms when reading title attributes. Please indicate which specific screen readers and versions you know that about on the wiki page. No screen reader does this sort of thing, to my knowledge. Again, we'll try to get some testing done (geez, this is turning into a testing marathon...I understand this whole burden of proof thing is on us, but still...) 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.com __ 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 fundamental tenets of microformats is that ease of publishing should trump ease of parsing (people first, machines second). A class like useTitle would make parsing easier but it's a pain in the butt for publishers. I think we can come up with a rule for parsers that doesn't require any superfluous classes (even if it means that the parsers have to work harder). The problem: Right now it is perfectly valid to encode a datetime like this: span class=dtstart2007-05-01/span see http://microformats.org/wiki/abbr-design-pattern Under the proposed title design pattern, this would also be a valid way of encoding a datetime: span class=dtstart title=2007-05-01May 1st 2007/span Now a parser must figure out where the machine-readable datetime is. In this example, it's pretty straightforward: look in the title attribute first; if there is no title attribute, look at the value enclose between the tags. The tricky bit is when this occurs: span class=dtstart title=a day of fun on the streets of Berlin2007-05-01/span If a parser looks at the title attribute first, it won't find the machine-readable data. This is where something like James's class suggestion would clarify the situation. But I believe this to be an edge case. I think we'll get more than 80% of cases by simply saying for dtstart, dtend and geo values, look in the title attribute first and between the tags second. And to cover the edge cases, I think the onus is on the parsers to figure out whether a string looks like a machine-readable piece of data. For datetime patterns, that's simply a case of using a regular expression already documented on the wiki: http://microformats.org/wiki/datetime-design-pattern#Code In short, I don't think any kind of flag is necessary to indicate where the machine-readable data is being stored. I think that any such flag would unnecessary complexity for humans. The patterns are enough. 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] changing abbr-design-pattern to title-design-pattern?
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 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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.com __ 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 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 and Tantek's specific comment, above, is at: http://rbach.priv.at/Microformats-IRC/2007-04-27#T180505 -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 OTOH, not allowing bugs and stubbornness of implementers to retard/slow/stop progress. Basically this is a complaint that current screen readers aren't yet frantically in the process of fixing their 800+ US$ software (some of which doesn't even support web standards in most cases, i.e. ignores many accessibility hooks and benefits built right into (X)HTML itself, opting for flaky heuristics instead) to support this fringe group's interpretation of what an ABBR is, and what the TITLE attribute stands for? Forgive me, but this smacks just a bit of arrogance... 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.com __ 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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.
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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.com __ 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-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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/style_master about me :: http://johnfallsopp.com Web Directions Conferences :: http://webdirections.org My Microformats book :: http://microformatique.com/book ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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. +1 for title-design-pattern 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 why I've got different results than the ones reported on the WASP post by Jon Gibbons. http://dotjay.co.uk/tests/screen-readers/date-time/#test-microformats Any ideas? Or should I raise this with WaSP? Lawrence -- Lawrence Meckan Absalom Media Mob: (04) 1047 9633 ABN: 49 286 495 792 http://www.absalom.biz ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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 that's a good policy. 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 and Tantek's specific comment, above, is at: http://rbach.priv.at/Microformats-IRC/2007-04-27#T180505 Andy, thanks for posting the permalinks - appreciated. Tantek ___ 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?
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: span class=dtstart useTitle title=2007-03-27T12:00:00-06:00Noon Central/span Does not use title value: a href=http://example.com/; class=fn org url title=Visit the company web site!Widgets, Inc./span Thoughts? James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
