Re: [uf-discuss] Expanding the abbr pattern
On May 3, 2007, at 4:53 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ben Wiley Sittler [EMAIL PROTECTED] writes Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar- brainstorming#Simplification_of_date-end but it has, so far, been ignored. It hasn't been ignored. I know that I've read and thought about it, but there isn't much to do about it right now, since it is predicated on a new version of hCalendar which diverges from iCalendar, which is not something I think we should be considering yet. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Expanding the abbr pattern: thoughts
I've done more testing with the spanned/title solution to an abbreviated date time pattern, and finally confirmed Jon Gibbins' report. It seems JAWS has a few nuances I didn't know about. I was planning to 'bake' a forum and comment system with microformats (hAtom hReview) and I'd prefer to get the date time pattern thing solved before I start coding. Breton's solution might work, but it just seems like too many spanned elements (spanitis?). Obviously, if we're going to run with ISO8601, we need to include the dashes as JAWS does read it better (which may require the usetitle solution). Any feedback on what would be an adequate common ground for this issue as I want to start developing ? Thanks 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] Expanding the abbr pattern: thoughts
Absalom Media wrote: Obviously, if we're going to run with ISO8601, we need to include the dashes as JAWS does read it better (which may require the usetitle solution). Any feedback on what would be an adequate common ground for this issue as I want to start developing ? While ISO 8601 is the right choice, reading it to a screen reader in any form is unacceptable. We're working on test of alternatives to the abbr-design-pattern for machine data. I encourage you to contribute: http://microformats.org/wiki/assistive-technology-abbr-results In the meantime, I would suggest using your best judgement with implementation. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
In message [EMAIL PROTECTED], Paul Wilkins [EMAIL PROTECTED] writes The following from the proposal I suspect is errant. abbr class=enddate title=2007-03-3131 January 2007/abbr Were you after the following? abbr class=enddate title=2007-01-3131 January 2007/abbr Yes; I note that you've already fixed that on the 'wiki'. Thank you. -- 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] Expanding the abbr pattern
i think the abbr pattern is a valid one. moving the unambiguous timestamp to some place humans can't see it is asking for it to be removed be a third party (whether that is a screenreader, an html sanitizer, or a web browser makes little difference.) and of course in some cases you can get away with not using abbr: Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. (e.g. 2007-03-12) this seems suitable for use in an abbr title. however, the combined datetime notation is a bit awkward due to the 'T' and time zone suffix (the former needed for separation from date and the latter needed for disambiguation -- the problem is that time zones are not widely understood regardless of notation.) treating whitespace as a field separator and so allowing date time to be equivalent to dateTtime removes one of the complaints, and forcing the human-readable timestamp into GMT/UTC eliminates another (microformats and other broadly-consumed data should probably default to GMT when no timezone is specified.) however this leaves us with the still-difficult problem of explaining a time from another timezone. maybe we need a dhtml widget to localize times for display, while allowing the page to contain only GMT/UTC? anyhow, sorry for the slightly-off-topic brainstorming, -ben On 5/2/07, Ben Buchanan [EMAIL PROTECTED] wrote: So, I started this response thinking How does a full-string timestamp /not/ disambiguate a March 2 date in the following? My answer is: by not being human-readable :) The example in the original post shows the problem: abbr class=dtstart title=20070312T1700-06 March 12, 2007 at 5 PM, Central Standard Time /abbr When vocalised, that title is less useful than the text it potentially replaces (screen readers may read just the text, just the title or both). Perhaps I should have said effective disambiguation, for all human users. At any rate, I think the main problem was referring to different examples - in yours, the shorter date probably would make sense to all users and yes it disambiguates. The datestamp in the microformat however, does not disambiguate for humans. ...and I think I've used up my quota for disambiguate, so I'll end there ;) cheers, Ben -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ___ 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
Ben Wiley Sittler wrote: in some cases you can get away with not using abbr: Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. Just want to raise, at this point, the problem an author might face with regards to an organisation's house styles. For instance, at my university, we have very specific guidelines for how dates and times etc should be written (hint: it ain't ISO-anything). 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] Expanding the abbr pattern
Yes, standardization takes a long time, and it's only clear in retrospect that a standard has really stuck. In my opinion, the jury is still out on ISO 8601... However, using 8601 in an abbr title and your house style in the abbr content should work just fine, right? On 5/3/07, Patrick H. Lauke [EMAIL PROTECTED] wrote: Ben Wiley Sittler wrote: in some cases you can get away with not using abbr: Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. Just want to raise, at this point, the problem an author might face with regards to an organisation's house styles. For instance, at my university, we have very specific guidelines for how dates and times etc should be written (hint: it ain't ISO-anything). 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
Ben Wiley Sittler wrote: However, using 8601 in an abbr title and your house style in the abbr content should work just fine, right? Yes, of course. Just wanted to add the concept that, as authors, sometimes the content part of pages isn't fully up to us either :) 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] Expanding the abbr pattern
In message [EMAIL PROTECTED], Ben Wiley Sittler [EMAIL PROTECTED] writes Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end but it has, so far, been ignored. -- 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] Expanding the abbr pattern
Yes, hence all these tricks to communicate the same data in two different formats... On 5/3/07, Patrick H. Lauke [EMAIL PROTECTED] wrote: Ben Wiley Sittler wrote: However, using 8601 in an abbr title and your house style in the abbr content should work just fine, right? Yes, of course. Just wanted to add the concept that, as authors, sometimes the content part of pages isn't fully up to us either :) 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
just by the way, the current microformats behavior is in line with iso 8601's interval semantics from my reading of the specs. On 5/3/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Ben Wiley Sittler [EMAIL PROTECTED] writes Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end but it has, so far, been ignored. -- 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
From: Andy Mabbett [EMAIL PROTECTED] In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr My understanding here is that the date defaults to a time of midnight, so the end date must be exclusive otherwise a one-day event will last for no time at all. You're right to be concerned though. I suspect that it is too much to ask people marking up their code to understand such fine points. Not to mention the troubles involved with templated or scripted markup. I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end but it has, so far, been ignored. You may want to correct the proposition. The following from the proposal I suspect is errant. abbr class=enddate title=2007-03-3131 January 2007/abbr Were you after the following? abbr class=enddate title=2007-01-3131 January 2007/abbr -- Paul Wilkins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end I do agree that such counter-intuitive things could cause a lot of people to use it incorrectly I think the machine-readable part should match the human-headable part in meaning for the untrained human but I don't think a real world application could rely on it either way unless there is something visible there to state that it is exclusive or inclusive. I have found with other things where start and end dates are used I just can't trust the end date if there is only one day between them because users WILL use them differently. (In the real world I just have to assume that it's an event happening some time during the start date - possibly all-day - possibly longer - more likely shorter) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Expanding the abbr pattern
Ben Buchanan wrote: Hi Jeremy, I'd be interested in hearing other arguments for or against this idea. I think it's a humans vs. machines issue. To my mind, the ABBR element is there to provide additional information to the user (the human). In this case, it's being used to add a timestamp in a format that I've never heard a human use. To put it another way, it's not adding information for the user; it's adding data for the machine. IMHO the ABBR title should always enrich, explain or disambiguate the contents of the ABBR tag. Using a full-string timestamp doesn't do that (nor does geo data, to touch on a related problem). Although it's tremendously useful for uf parsing, I think it's trumped by the problems it causes for screen reader users. Ben, So, I started this response thinking How does a full-string timestamp /not/ disambiguate a March 2 date in the following? div class=vevent abbr class=dtstart title=20040502May 2nd/abbr div class=summaryExample/div /div May 2nd is ambiguous regarding the year of the event. The timestamp is not. I think there are compatibility problems with screen readers that may be more important, but a lack of disambiguation doesn't seem to be the issue. The fact that a human doesn't use an ISO timestamp is a bit beside the point as the title is an attribute of the tag, not content on the page. The title isn't displayed to the user. It is interpreted by the renderer and displayed or output in some fashion. The problem may be that current readers don't handle timestamps very well, but that's a reader problem (one that we would do well to resolve). As I discovered later, the fact that it is not the normal version as would be seen in running text, is a problem. For a decent rant on why ABBR is for machines and not people see http://www.smackthemouse.com/20040108 But then I read the article referred to in Jeremy's post [1] and realized ABBR pattern is neither valid nor necessary, even if convenient. And that article also gave several examples where the ABBR pattern isn't necessarily disambiguation, making my example moot. Tantek also wrote: 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 span 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*. So much for the 80/20 rule. According to the link provided in Jeremy's post [1], the ABBR pattern is not valid HTML 4, which is especially ironic given Tantek's commitment to HTML4 as the baseline for judging IE's behavior. Here's the quote from the Web Standards Project article [1], itself quoting the spec [2]: The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. (HTML 4, ABBR) Unlike the ISO date format, the full or expanded form is intended to be human-readable. Yes, machine-readable, but for the consumption of a human, and in this case, spoken literally to a human. The Web Content Accessibility Guidelines (WCAG) explicitly defines the expansion of abbreviations as an accessibility advantage, and the most popular screen readers do so. So, ABBR is unsupported in IE6 (without jumping through hoops to use special scripts). ABBR timestamps are problematic in leading screen readers. And ABBR timestamps violate the HTML 4 spec. How did it actually get adopted as a pattern for uF? Or more specifically, is there any way to fix that mistake? I would say we should at least avoid extending it into new areas, until and unless a formal standard body endorses a viable solution and that solution reaches viable 80/20 market share. The status of HTML5 and XHTML 2 are not worth getting into, but suffice to say such a trigger is likely to be far into the future. However, I do like Jeremy's suggestion for best-practices on the ABBR: 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? If we are going to continue to support a non-compliant use of ABBR, we may as well advocate a version of it that is more friendly to existing screen readers. That would also require updating the vCalendar Creator. Cheers, -j [1] http://www.webstandards.org/2007/04/27/haccessibility/ [2] http://www.w3.org/TR/html4/struct/text.html#edef-ABBR -- Joe Andrieu SwitchBook Software http://www.switchbook.com [EMAIL PROTECTED] +1 (805) 705-8651 ___ microformats-discuss mailing list microformats-discuss@microformats.org
Re: [uf-discuss] Expanding the abbr pattern
So, I started this response thinking How does a full-string timestamp /not/ disambiguate a March 2 date in the following? My answer is: by not being human-readable :) The example in the original post shows the problem: abbr class=dtstart title=20070312T1700-06 March 12, 2007 at 5 PM, Central Standard Time /abbr When vocalised, that title is less useful than the text it potentially replaces (screen readers may read just the text, just the title or both). Perhaps I should have said effective disambiguation, for all human users. At any rate, I think the main problem was referring to different examples - in yours, the shorter date probably would make sense to all users and yes it disambiguates. The datestamp in the microformat however, does not disambiguate for humans. ...and I think I've used up my quota for disambiguate, so I'll end there ;) cheers, Ben -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
Hi Jeremy, I'd be interested in hearing other arguments for or against this idea. I think it's a humans vs. machines issue. To my mind, the ABBR element is there to provide additional information to the user (the human). In this case, it's being used to add a timestamp in a format that I've never heard a human use. To put it another way, it's not adding information for the user; it's adding data for the machine. IMHO the ABBR title should always enrich, explain or disambiguate the contents of the ABBR tag. Using a full-string timestamp doesn't do that (nor does geo data, to touch on a related problem). Although it's tremendously useful for uf parsing, I think it's trumped by the problems it causes for screen reader users. So, I'd be happy to see the title shifted to a span - still not entirely perfect I suppose, but it leaves ABBR to the humans :) cheers, Ben -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Expanding the abbr pattern
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: [uf-discuss] Expanding the abbr pattern
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
Re: [uf-discuss] Expanding the abbr pattern
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 span 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] Expanding the abbr pattern
[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 span 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
