Re: [uf-discuss] User Interface for Firefox/Operator
1. Suppose a web page has multiple geo Microformats. The Operator Find a Google Map currently allows only a mashup of one geo Microformat at a time with Google Maps. I would like an option that would display all the geo Microformats simultaneously. For example, a web page that shows the route of an airplane may have a geo Microformat for each waypoint. I would like to be able to view on Google Maps all the waypoints simultaneously. sounds nice but wouldn't Google's requirement for an API key make this difficult? A single point could be shown by just creating a link to Google Maps but to show multiple points would probably mean creating a page in the browser using the Google Maps API. (Microsoft's map API might be easier - they seem to have less red tape associated with showing a map and putting stuff on it) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] User Interface for Firefox/Operator
Hello Michael, I think Mozilla Corporation (the main backers of Firefox) have a special relation with Google. So, it's probably not so much of an issue. See ya On 5/2/07, Michael MD [EMAIL PROTECTED] wrote: 1. Suppose a web page has multiple geo Microformats. The Operator Find a Google Map currently allows only a mashup of one geo Microformat at a time with Google Maps. I would like an option that would display all the geo Microformats simultaneously. For example, a web page that shows the route of an airplane may have a geo Microformat for each waypoint. I would like to be able to view on Google Maps all the waypoints simultaneously. sounds nice but wouldn't Google's requirement for an API key make this difficult? A single point could be shown by just creating a link to Google Maps but to show multiple points would probably mean creating a page in the browser using the Google Maps API. (Microsoft's map API might be easier - they seem to have less red tape associated with showing a map and putting stuff on it) -- 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
UPDATE: Re: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes AndyMabbett and Gazza, apologies for the inconvenience of the temporary blocking. Thanks very much for your patience. Blocks have been removed. You appear to have not received; to have overlooked; or to have deliberately ignored my e-mail on the subject: http://microformats.org/discuss/mail/microformats-discuss/2007-May/009461.html Please answer it, on this mailing list. -- 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] User Interface for Firefox/Operator
In message [EMAIL PROTECTED], Mike Kaply [EMAIL PROTECTED] writes Thanks Roger, I really want feedback like this! On 5/1/07, Costello, Roger L. [EMAIL PROTECTED] wrote: Hey Mike, Here's my wish list for Operator: 1. Suppose a web page has multiple geo Microformats. The Operator Find a Google Map currently allows only a mashup of one geo Microformat at a time with Google Maps. I would like an option that would display all the geo Microformats simultaneously. For example, a web page that shows the route of an airplane may have a geo Microformat for each waypoint. I would like to be able to view on Google Maps all the waypoints simultaneously. I'm pretty sure to do this, I'd have to have a website somewhere that accepted the points and displayed the page. Google Maps right now has no way to display multiple points at the same time from just a URL. Suggestions welcome. Offer Export as KML, so that people can achieve the same result, in Google Earth. Please also offer Export as GPX, at the same time, so that people can also import waymarks into GPS devices, as discussed previously, and on the 'wiki'. 2. Suppose the geo Microformat is part of an hCard. The Find a Google Map currently only shows the lat/lon values on the Google Map. It would be nice if Operator would scoop up some of the other information in the hCard, such as name and address, and display it on the Google Map. The hCard also has a Find with google maps. So you could use the address as well. Honestly, this is one of the things that always confused my about geo. How often to you need a geo vs an address? I understand if you are in the middle of the desert... Physical features (bridges, road junctions, etc.) can have hCards with fn and geo, but no address. -- 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?
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] 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
[uf-discuss] RecentChangesCamp Montreal (RoCoCoCamp), 18-20 May 2007
Hello, all! I'm writing to let µF folks know about this upcoming event. Some of you have already received personal invitations, but I wanted to send a broadcast for all the people I don't know personally. RecentChangesCamp is the international unconference for wiki developers, users, theorists and practitioners. It's been held for the last two years in Portland, OR; this year we're having it in Montreal, over the weekend of 18-20 May. http://www.recentchangescamp.org/ http://www.rocococamp.info/ There aren't scheduled speakers, keynotes, or panels -- as an un-conference, the emphasis is on peer-to-peer communications, hands-on development, productive face-to-face meetings. The event is free of charge for all participants. I'm extending this personal invitation to microformats advocates for two reasons. First, there will be an opportunity to talk about µFs with project leads for some of the most important wiki software. Second, microformats are the only open standard I know of developed using a wiki; this is a practical experience that I think more wiki practitioners should know about. Registration is as simple as signing up on our wiki: http://www.rocococamp.info/Participants We've made some travel arrangements for out-of-town visitors; there's more info on the wiki. Feel free to email me off-list if you have any questions. Thanks, -Evan Evan Prodromou [EMAIL PROTECTED] http://evan.prodromou.name/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Legal implications of using Microformats
M. Jackson Wilkinson wrote: If a patent were granted, then the holders could approach users of the now-patented process and hold them accountable for royalties and licensing fees. All of a sudden, anyone from Microsoft to your small business can be threatened with, at minimum, a long legal battle. Exactly the point - the Microformats community is not doing enough to protect the implementors of their technology. This fear can be soothed fairly simply by releasing all work on the wiki into the public domain, or something of the sort. All wiki pages could be under the LGPL, the GDL, or some other open licenses if not in the public domain. There are several options here. Right on the money, again. The challenge now is that every editor of the wiki would, I believe, need to either approve of the change in license, or their work would need to be stripped out of the wiki. This kind of process has happened several times in open source software projects. The microformats wiki may be sufficiently young as to make this somewhat possible, but it would certainly involve significant effort. It's one of those things that really needs to be handled right at the beginning. Another brilliant statement! Deal with the problem now while it is manageable - or later, when there are going to be multi-million dollar lawsuits being bandied about. The Microformats community WILL be blamed for not performing proper due diligence before placing their standards online. Again, this is all just based on my personal experience and research, and is not legal advice, but may be useful as a way of understanding why some may be concerned. The reason this issue was raised was because we have authored and filed several patents and know what we are talking about regarding the dangers of submarine patents. If you want an official letter from a legal firm specializing in copyright and patent law, stating how tenuous the Microformats community's copyright and patent policy is - we could arrange that. However, it is going to cost us a sizeable chunk of change and we wanted to make sure that the community was listening before we went out and arranged to have that happen. -- manu -- Manu Sporny President/CEO, Digital Bazaar, Inc. http://blog.digitalbazaar.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Migrating from Custom XML to XHTML to (XHTML + Microformats)
Hi Folks, I have written a short wiki article describing how an information design may evolve from custom XML tags, to XHTML tags, to XHTML + Microformats: http://www.xfront-wiki.com/wiki/index.php?title=Alternative_Information _Designs Comments are welcome. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Migrating from Custom XML to XHTML to (XHTML + Microformats)
On 5/2/07, Costello, Roger L. [EMAIL PROTECTED] wrote: Hi Folks, I have written a short wiki article describing how an information design may evolve from custom XML tags, to XHTML tags, to XHTML + Microformats: http://www.xfront-wiki.com/wiki/index.php?title=Alternative_Information _Designs --- excellent, glad to see it is a wiki where anyone can edit. I encouage you to add the information to the microformats wiki as well. Awhile ago i wrote some XSLT code to convert any XML into XOXO. http://suda.co.uk/projects/microformats/xoxo/ http://suda.co.uk/projects/microformats/xoxo/xml2xoxo.xsl (i hope it still works, it has been awhile). When converting the XML into XHTML if it is converted to XOXO as well, then XOXO aware apps and libraries can internalise the data into arrays easily. You should have an example for XOXO output as well. if you have any specific question about implementations and code to do this you should consider asking the dev list as well. -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] microshow
Two of my recent edits, soon reverted by Tantek, were to remove a red link, under the heading see also to from: http://microformats.org/wiki/show-formats and from: http://microformats.org/wiki/showroll-brainstorming The red link was to: /microshow and had existed since 15/ 16 December 2005 - over 16 months ago The page: http://microformats.org/wiki/microshow was created at the same time as those red links: http://rbach.priv.at/Microformats-IRC/2005-12-16#T092823 but was deleted by Tantek less than one hour later: http://rbach.priv.at/Microformats-IRC/2005-12-16#T101728 with the edit summary: deleted microshow: 1. This is a shell page. 2. It is based on a premature *-brainstorming page. 3. It ignores existing media-metadata work. Tantek then noted, on both /show-brainstroimng and /showroll-brainstorming: This page has been prematurely created ... Any microformat about a show, or video, or tv should be worked on within the context of media-metadata-examples, rather than creating new pages for it. http://microformats.org/wiki?title=show-formatsdiff=3340oldid=3335 I can find no other reference to microshow on IRC or the WIki. It was briefly discussed in this December 2005 mailing list thread: http://microformats.org/discuss/mail/microformats-discuss/2005-December/002292.html in which Tantek commented: I also noticed this: http://microformats.org/wiki/microshow [...] Please do not create a microformat page for something for which there isn't even a strawman specification in the *-brainstorming page. Shell pages like this one will be deleted.. Can anyone tell me why these red links should remain on the Wiki? What information do they convey, and what purpose do they serve, other than inviting and enticing people to create /microshow, apparently outside the beloved process? -- 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] video-metadata-models
Andy Mabbett wrote: /video-metadata-models /microshow That's incredibly strange - both of these links appear under the Related and See Also sections of those pages. Should red-link items be placed under each of those sections? There isn't anything at the end of the links to relate to or see? The media-info examples page is the only one that is current. I see no reason to keep blank pages attached to abandoned/out-of-date initiatives around, especially since these red links are over 2 years old. Especially since there is no information that is being destroyed. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] human readable date parsing
With all of the discussion about iso dates being unreadable and that an iso date isn't necessarily required when someone enters a date (i.e. saying 24th June doesn't translate into a single date, neither does 'thursday'). Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). Just a thought... Tim -- Tim Parkin, Pollenation Internet Ltd, Leeds, UK ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Tim Parkin wrote: With all of the discussion about iso dates being unreadable and that an iso date isn't necessarily required when someone enters a date (i.e. saying 24th June doesn't translate into a single date, neither does 'thursday'). Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). I disagree. If you try to make other, human readable formats into a standard, they will fall short when it comes time to internationaliz (s)e it. If you can come up with a better format readable to all machine and all humans in all languages, I'll recant. I think the ISO 8601 is the best machine data format for the job. I just don't think it should be in abbr. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
From: James Craig [EMAIL PROTECTED]
To: Microformats Discuss microformats-discuss@microformats.org
Sent: Thursday, May 03, 2007 8:56 AM
Subject: Re: [uf-discuss] human readable date parsing
Tim Parkin wrote:
With all of the discussion about iso dates being unreadable and that an
iso date isn't necessarily required when someone enters a date (i.e.
saying 24th June doesn't translate into a single date, neither does
'thursday'). Shouldn't the focus be on trying to standardise date
formats rather than trying to hide the iso date? If we can get a parser
to recognise 'human readable' dates (which *is* possible, if not totally
easy, http://labix.org/python-dateutil for a python version).
I disagree. If you try to make other, human readable formats into a
standard, they will fall short when it comes time to internationaliz (s)e
it. If you can come up with a better format readable to all machine and
all humans in all languages, I'll recant.
I think the ISO 8601 is the best machine data format for the job. I just
don't think it should be in abbr.
So as machine-readable information shouldn't be presented in a
human-readable manner, that rules out having the information in-the-clear,
and in title tags.
This leads us to having a hidden class for machine-readable information that
will be hidden by default and not presented to people.
A class with a suitable name would have to be used, something like the
existing value but modified to infer that it's for the computer only and
isn't to be read.
What if the value class was to be used with a hidden class. Then they would
serve their purpose, they wouldn't interfere with existing styles and could
be interpreted correctly.
.hidden {display: hidden}
Then the human-readable and machine-readable can be mashed together. If the
screen-reading software honor hidden styles this could be the right path to
take.
span class=dtstartFriday the 13th span class=hidden
value20070713/span/span
--
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Paul Wilkins wrote:
What if the value class was to be used with a hidden class. Then they
would serve their purpose, they wouldn't interfere with existing styles
and could be interpreted correctly.
.hidden {display: hidden}
Then the human-readable and machine-readable can be mashed together. If
the screen-reading software honor hidden styles this could be the right
path to take.
That would still render the machine-readable part in the clear on
platforms with incomplete or missing support for CSS, such as some
current mobile devices. Also, it feels conceptually wrong to have
machine-readable stuff sprinkled into what should just be content.
Note that, based on current practice adopted by screen readers, only
TITLE on ABBR is explicitly being given status as human-readable.
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.
http://www.w3.org/TR/html401/struct/text.html#edef-ABBR
So, although the spec tempers this with a may, it does suggest this
kind of use by screen readers.
Values of the title attribute may be rendered by user agents in a
variety of ways. [...] For example, setting the attribute on a link
allows user agents (visual and non-visual) to tell users about the
nature of the linked resource:
http://www.w3.org/TR/html401/struct/global.html#adef-title
There's a may here as well, but the generic definition for title
(which could then be used on something like a span) seems far more lax
to me, and in that respect more suited to be plied/bent for microformat
data use. IMHO, of course.
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] human readable date parsing
James Craig wrote: Tim Parkin wrote: With all of the discussion about iso dates being unreadable and that an iso date isn't necessarily required when someone enters a date (i.e. saying 24th June doesn't translate into a single date, neither does 'thursday'). Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). I disagree. If you try to make other, human readable formats into a standard, they will fall short when it comes time to internationaliz(s)e it. If you can come up with a better format readable to all machine and all humans in all languages, I'll recant. I think the ISO 8601 is the best machine data format for the job. I just don't think it should be in abbr. Yes, indeed.. And I was wrong to say shouldn't the focus be.. I was just approaching the problem from a different angle to see if it looked more tractable, not from this angle obviously :-) In the vein of approaching things from a totally different angle, how about using hidden input field for the value? (I realise there are many problems with this but it might be worth documenting some of the negatives for future reference - I'm happy to start by saying Visual Developers propensity to formify the whole page could cause issues.. but then again VD may just be an issue in itself). Tim ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
James Craig wrote: Tim Parkin wrote: [...] Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). I disagree. If you try to make other, human readable formats into a standard, they will fall short when it comes time to internationaliz(s)e it. If you can come up with a better format readable to all machine and all humans in all languages, I'll recant. I think the ISO 8601 is the best machine data format for the job. I just don't think it should be in abbr. Agreed, James. ISO 8601 is the best format. There may be an option to have a space in the notation between the date and time thus removing the T [1],[2]. E.g: 2007-05-20 12:34 This is read by JAWS 8.0 in IE6 and IE7 as two thousand seven dash zero five dash twenty twelve thirty-four (via Jon Gibbins [3]). However, RFC 3339 [4] or W3C Date and Time format note [5] doesn't feature a space in the available examples. The issue for me is we're trying to fit a machine readable date in to a human readable form. All users (whether visually impaired or not) still need to know the format or learn it as they have to learn every interface element at first contact. No matter what the notation is, it will always be fairly ambiguous. Prepending the value still seems to me to be worthy of consideration in order to provide context and help users to learn the notation in a some way. After first coming across it, at least screen reader users (and everyone else) can choose not expand attribute values for dates and times (choosing not to learn it as irrelevant), or search to learn more about the notation. Jon Tan http://gr0w.com [1] http://www.cl.cam.ac.uk/~mgk25/iso-time.html (Time of day section) [2] http://www.cs.tut.fi/~jkorpela/iso8601.html (in the summary) [3] http://dotjay.co.uk/tests/screen-readers/microformats/datetime-design-pattern/-MM-DD%20HH-MM.php [4] http://www.ietf.org/rfc/rfc3339.txt [5] http://www.w3.org/TR/NOTE-datetime ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
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
