[uf-discuss] accessibility test pattern alternatives for abbr-design-pattern
Since Mike, Tantek, and Andy brought up abbr pattern accessibility recently, I should mention to the list that we're finished with the test cases for the abbr alternatives. Any help with testing screen readers and other AT is greatly appreciated. Wiki page: http://microformats.org/wiki/abbr-design-pattern-alternatives Test Cases: http://cookiecrook.com/test/uf/testcases/?printMarkup=true Thanks, James Craig ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] dfn design pattern (proposal)
Michael MD wrote: http://microformats.org/wiki/dfn-design-pattern * Feedback from the people building parsers (Mike Kaply, Brian Suda, etc.) on whether this would be tricky or easy to implement. quite easy I think... my own scripts that parse hcalendar don't really care what tag is used for dtstart or dtend - they look for those class names (and the title attribute) Let's don't jump the gun on implemention. The dfn-design-pattern has yet to prove any benefit over the abbr-design-pattern. For now, it's just one of several good ideas to be tested in this list. http://microformats.org/wiki/assistive-technology-abbr-results James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] abbr and accessibility - a work around.
Apologies for not responding sooner. I've been working on a test case script for all of the possibilities listed on the assistive- technology-abbr-results pages, but side work always falls behind work work. I'm getting close, I swear. Please add this format to the list if you'd like us to test it, though on first glance, I don't think it will be any better for the sake of AT. It might actually be worse, because the agents that speak the title attribute node out loud would also speak the following text node. http://microformats.org/wiki/assistive-technology-abbr-results Andy Mabbett wrote: I've been working with Great Circle Mapper to add hCard and geo microformats to their website. This has been done; for example on: http://gc.kls2.com/cgi-bin/gc?PATH=BHX-HKG%0D%0A%0D% 0ARANGE=PATH-COLOR=redPATH-UNITS=nmSPEED-GROUND=SPEED- UNITS=ktsRANGE- STYLE=bestRANGE-COLOR=navyMAP-STYLE= (aka http://tinyurl.com/yrlj9t) and they've come up with this way of working-around recent concerns about mis-use of abbr: span class=smaller geo abbr class=latitude title=52.453856/abbr52^27'14N abbr class=longitude title=-1.748028/abbr01^44'53W /span (degree symbols replaced with ASCII ^) I admire the lateral thinking, but I wonder if this is any better, from the PoV of people using assistive technology? If it is, it would seem to provide a simple work-around to recent concerns. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Empty anchor tag-pairs and accessibility (was: Questionabout telephone numbers)
Paul Wilkins wrote: From: Andy Mabbett [EMAIL PROTECTED] I thought we'd decided that empty anchor tag-pairs were bad, from an accessibility PoV? Is the object tag to be used instead for the include pattern? The object include pattern has some performance problems, it would be best to use the anchor include pattern but include some text indicated the marker that was being included. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Empty anchor tag-pairs and accessibility (was: Questionabout telephone numbers)
James Craig wrote: Paul Wilkins wrote: From: Andy Mabbett [EMAIL PROTECTED] I thought we'd decided that empty anchor tag-pairs were bad, from an accessibility PoV? Is the object tag to be used instead for the include pattern? The object include pattern has some performance problems, it would be best to use the anchor include pattern but include some text indicated the marker that was being included. In my medicated stupor, I thought that made sense. Let me try it again. The object include pattern has some performance problems (see http://microformats.org/wiki/include-pattern-feedback), so it would be best to use the anchor include pattern but include some link text indicating the content that is being included. Such as: a href=#sharedcompany class=includeWidgets, Inc./a ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Proposal: hArgument Microformat
Hey Roger, Looks interesting. Check out the Microformats process. http://microformats.org/wiki/process Then propose on the [microformats-new] list. Cheers, James On May 20, 2007, at 2:37 PM, Costello, Roger L. wrote: Hi Folks, Michael Crichton says: The greatest challenge facing mankind is the challenge of distinguishing reality from fantasy, truth from propaganda. Perceiving the truth has always been a challenge to mankind, but in the information age (or as I think of it, the disinformation age) it takes on a special urgency and importance. One of the keys to distinguishing information from disinformation is to have a clear understanding of the assumptions an author is making. Typically, it takes a great deal of effort to distill an author's assumptions. Bring clearly to light the assumptions being made would go a long way towards facilitating a web of trust. I propose an hArgument Microformat with two properties: hArgument assumption (repeatable): a statement of what the author assumes to be true, and upon which his/her conclusion follows. [If it can be demonstrated that the assumption is false, then the conclusion is invalid] conclusion (repeatable): a statement that derives from the assumption(s) Example: below is an example of an argument. The argument can be immediately discredited because the assumptions can be shown to be fallacious: p class=hArgument span class=assumptionMicroformats are a disruptive technology/span span class=assumptionMicroformats are attempting to supplant XML documents with HTML and XHTML documents/span span class=assumptionThe main benefit of Microformats is that it allows graceful degradation/span span class=conclusionMicroformats go too far./span span class=conclusionIt's almost better to use a more suited format in such cases/span /p The advantage of this is that there is no need to guess what are the author's assumptions. They are clearly identified. Use Cases: any web page that tries to convince you of something. The examples are endless. Comments? /Roger ___ 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
[uf-discuss] a[name] as machine data?
Just a thought: Haven't thought too much about this, but are there any obvious gotchas to using an anchor element with name attribute as a potential replacement for the abbr-design-pattern? The only things I can foresee are the plus sign (+) in pre-UTC time zones and the semicolon (;) in GEO. Those could both be escaped though, perhaps as underscores. It wouldn't leave as much room for growth as a full CDATA attribute, but may be able to a class=dtstart name=iso8601:20070713July 13th/a a class=geo name=geo:30.300474_-97.747247Austin/a http://www.w3.org/TR/html4/types.html#type-cdata ...NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (-), underscores (_), colons (:), and periods (.). Anyway, kick it back here if there is something obvious I'm missing. I'm certainly not proposing it as the best solution yet, but I have added it to the wiki and don't want to waste time with an AT test case if I don't have to. http://microformats.org/wiki/assistive-technology-abbr- results#Markup_Possibilities Cheers, James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a[name] as machine data?
Ryan King wrote: James Craig wrote: Haven't thought too much about this, but are there any obvious gotchas to using an anchor element with name attribute as a potential replacement for the abbr-design-pattern? I believe a[name] and @id need to be unique across an entire page. This would make it impossible to have two events with the the same dtstart, dtend or dtstamp on the same page. I think that makes it unworkable. Only ID has that restriction. Radio buttons, for example, require elements have unique IDs but the same NAME. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a[name] as machine data?
Ryan King wrote: a[name has restrictions that input[name] does not have. ...snip... 1. http://www.w3.org/TR/html401/struct/links.html#h-12.2.1 Note and removed. Thanks! http://microformats.org/wiki/assistive-technology-abbr- results#Markup_Possibilities James ___ 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] human readable date parsing
I almost completely disagree with this. If people are actually *using* Microformats as intended, there will be plenty of times when the machine data will pass in front of the user (in their calendar program for example) for verification. I do however, agree with the following. expressed in as little-encoded form as can be gotten away with. I concur, but what is in dispute here is what can be gotten away with. The abbr-design-pattern has failed for machine data. Copied the entire email below for context. Tantek, if you post this to the wiki, please note it as opinion and give a link to the thread. Marking this as fact would misrepresent the views of the Microformats group as a whole. On May 4, 2007, at 7:53 AM, Tantek Çelik wrote: (apologies for top posting but this is in response to Al's entire message, not to any specific point in particular) Al, VERY well written. That's perhaps the clearest explanation I have seen of why it is important to have visible information, even somewhat visible rather than invisible. May I quote what you wrote in part or in full on microformats wiki? Thanks, Tantek On 5/3/07 6:18 PM, Al Gilman [EMAIL PROTECTED] wrote: At 12:24 AM +0100 4 05 2007, Patrick H. Lauke wrote: Tantek Çelik wrote: 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. For the sake of argument, though: assuming that those human eyes/ears use a microformat-consuming tool/extension/etc, this can still happen. If I have a page with, say, contact details marked as a hcard, and human users export it to Outlook, they'll be able to see (and ensure) whether or not the generated vcard details in the add to address book dialog match the page's visible details or not. After all, isn't that what microformats are there for? Being consumed by machines that can make something useful with them? Almost. They are there so that people and machines can share info. If the machineable info is not routinely passing through the consciousness of the communicating principals (that is, people), then it must be expected that the machine and the person will frequently have different values for the same datum. Not a good thing. The old saw is, out of sight, out of mind. In this case it is use it or lose it (it's validity) for data. Microformats are to eliminate the mumbo-jumbo quality of the data the machines deal with; rather to give them the same many-eyeballs 'bazaar' checking support as the virally-maintained meanings of plain English (Chinese, Arabic or what have you...). That's a little overstated, but the devil is in the details. If in some community of communication, the data is routinely extracted into view often enough so that bad data tend to get weeded out, then the storage or transmission form doesn't have to be directly comprehensible by people. But one of the virtues of markup languages is just how much of the info is directly under the quality control of people; expressed in as little-encoded form as can be gotten away with. Al ___ 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] human readable date parsing
Scott Reynen wrote: Tantek Çelik wrote: To minimize the negative impact of that violation, the datetime design pattern does two things: 1. Keep both copies of the data on the same element (the further apart two copies of data, the greater the chance that that copies will diverge). 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. None of the markup possibilities in the wiki do #2 above (except the current recommendation): http://microformats.org/wiki/assistive-technology-abbr- results#Markup_Possibilities Look again. * Span with title property. It sounds like these aren't really possibilities at all. I don't see how we can possibly reach any sort of consensus solution here when we seem to have completely opposed goals intermingled as if they're the same. Some people are clearly trying to *minimize* the visibility while others are trying to *maximize* the visibility of machine-readable dates. Let's try to get everyone on the same page here. In addition to span[titile] existing Microformat plug-ins and parsers do the following quite nicely, making all of the listed markup formats very real possibilities. 2. Keep both copies of the data at least somewhat visible to humans ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On May 4, 2007, at 8:24 AM, Tantek Çelik wrote: On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote: I almost completely disagree with this. If people are actually *using* Microformats as intended, there will be plenty of times when the machine data will pass in front of the user (in their calendar program for example) No the in their calendar program is totally insufficient because it is nearly completely detached from the other representation of the data. In a separate window etc. etc. People don't tend to switch between two windows to check to see if the info was the same. I also mentioned Tails which displays the data in the same window. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Andy Mabbett wrote: Tantek Çelik writes Al's explanation provides good reasons *in general* why visible data works (and why invisible does not work), Consider: a href=cheese lang=frFromagea Where's the visible data there? By your logic, tags should only work on the anchor element's content, not the tail of it's URL. You appear to be operating double standards. I agree. Using an optional title on the following would be a much better solution for rel-tag than the current implementation. Though, as indicated, the french tag should probably still remain in French. a rel=tag href=/username/tags/cheese title=CheeseYour Cheesea a rel=tag href=/tags/cheese title=CheeseEveryone's Cheesea a rel=tag href=/tags/fromage title=Fromage lang=frFromagea Using title would also allow proper internationalization of rel-tag. For example, the restful katakana tag space is readable only to machines. a rel=tag href=/tags/%u30D4%u30D5/ title=ピフピフ/a ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
victor jalencas wrote: Since using ISO8601 is a w3c recommendation, I wondered where specifically they were recommending its use. Looks like there is an element (a couple of them, actually) with an attribute that can legally contain an ISO datetime: INS and DEL. Technically, that should only be used when the textual content of the element has been inserted or deleted, but I don't have an issue with the empty ins or del. I've added it to the wiki test cases. Other parts of the spec that look interesting, and that I had forgotten long ago, are script macros [1]; and perhaps even specifying datetime info as script data, put on an event handler (in the ABBR or SPAN element) that we know we won't trigger normally (for example, an onblur on an empty element). onchange would be even less likely. I've added both the test cases. http://microformats.org/wiki/assistive-technology-abbr- results#Valid_HTML4 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Breton Slivka wrote: span class=vmonthJuly/span span class=vday26/spanth, span class=vyear2005/span This solution is certainly more verbose, but note that it follows all restrictions except for 7. I don't think this will work, for the same reason tel-type and adr- type don't work: l10n/i18n. They require displayed machine values to be in English. span class=vmonth lang=enJuly/span span class=vmonth lang=esjulio/span span class=vmonth lang=jp7 月/span span class=vmonth lang=ruиюль/span ___ 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: 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: [uf-discuss] [rethinking abbr] Does object deserve another look?
The main problem, as I understood it, is that object[data] expects a URI, even if it doesn't know how to handle it, so the first suggestion is actually requesting the relative path ./20050125 which causes extra junk 404s (Ex. 1; not necessarily a bug). Some UAs even requested relative paths for anchored resources in the page as with the object include-pattern (Ex. 2; probably a bug and definitely a reason to ditch it). 1. object class=dtstart data=20050125January 25/object 2. object class=include data=#foo/object Problem noted here: http://microformats.org/wiki/include-pattern- feedback The next problem was browser display inconsistency with the human- readable text being the innerHTML of the object. The object example listed in the WaSP post circumvented both of these problems, but wasn't very elegant markup and even looked sloppy without the accompanying CSS. The solution was basically to ditch object[data] and use object param[value] instead. The inelegant– but working–object version was: span class=dtstart January 25 spanobjectparam name=value value=20050125 //object/span /span There may be an additional problem of performance–what happens when you load up 300 empty objects on a page even if they aren't trying to reload the page 300 times–but it's as yet undocumented. I would have spent more time finding out if the solution had been more elegant. As is, I wasn't seriously suggesting it, but I wanted to leave the possibility in there for consideration. This was as much homework as I deemed necessary to commit. James On Apr 30, 2007, at 10:27 AM, Ryan Cannon wrote: Perhaps I'm getting into this a bit late and this has already been brought up, but I've skimmed through the conversation and haven't seen it. Tantek's original proposal[1] was scrapped because it didn't work in Safari 1.2.1 (WebKit v125). Hasn't that particular browser version been obsoleted to that point that we can reconsider using it? The latest Safari version for OS X.3 is 1.3.9, which is soon to be two OS versions back. Any idea precisely when this bug was fixed? While few browser stats break Safari versions down to the WebKit version, my site has received 1 hit from from WebKit v125, and that tiny marketshare is reflected in other stats I've found[2]. If we are going to talk about 1% browsers, why are we holding back an otherwise ideal design pattern for an obsoleted version of a minor browser? object is ideal, as Tantek described it, and it is both simple to write and backwards-compatible. [1]: http://tantek.com/log/2005/01.html#d26t0100 [2]: http://www.webreference.com/stats/browser.html -- Ryan Cannon Interactive Developer http://RyanCannon.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] 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?
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] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek Çelik wrote: Patrick H. Lauke wrote: Forgive my newness to this, but: could you provide some examples of where the generalised title-design-pattern would be problematic? Here is a simple (theoretical) example (hReview fragment) span class=rating title=Three means fair3/span There is no ambiguity here. From the spec, the parser should understand that the integer is the machine-readable data. Quoting from the Microformats wiki entry for hReview: rating. optional. fixed point integer [1.0-5.0], with optional alternate worst (default:1.0) and/or best (default:5.0), also fixed point integers, and explicit value. Would this noise be a problem for end users, or just for the tools that consume microformats? Neither directly. Rather, it would be a problem for the sites who have already published microformats, because we would be redefining something they are already doing. We're not suggesting that existing Microformat parsers remove their support for abbr-design-pattern. We're suggesting that Microformat authors stop using abbr-design-pattern for data not mean to be consumed by humans. I would expect that sites like Technorati and plug-ins like Operator and Tails, continue parsing abbr-design-pattern as-is to avoid breaking backwards compatibility. In otherwords, while *currently*, the use of a title attribute on non-abbr microformatted elements has *NO IMPACT* on the microformat semantics of that non-abbr element, with the title-design-pattern, those sites that were using 'title' for advisory information would suddenly find that that advisory information had been redefined to take the place of a microformat value, thus very likely breaking their microformatted content. Only if that advisory information matched the expected data format for that particular class. Do you know of any current implementation where this would fail? Examples in the wild of course. ;-) 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] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek Çelik wrote: And though it may seem odd that I'm simultaneously arguing against the proposed title-design-pattern and attempting to improve it, even if I am against a particular proposal, I would much rather attempt to improve it in good faith, for the benefit of having the best possible proposals be discussed, than not. This is wise, and I will follow your example: The seconds in ISO 8601 are optional, and are almost always 00... Since screen readers sometimes pronounce HH:MM correctly but rarely get HH:MM:SS correctly, it would be better to avoid using seconds, too. Although I don't believe it's good enough, omitting the seconds would make time pronunciations slightly better, as including the dashes makes date pronunciations slightly better. 2007-04-29T12:30:00+06:00 would be two thousand seven dash zero four dash twenty nine tee twelve thirty zero zero plus six o'clock 2007-04-29T12:30+06:00 would be two thousand seven dash zero four dash twenty nine tee twelve thirty plus six o'clock Note: In negative time zones (i.e. Pacific is -08:00), the hyphen is usually pronounced as dash. I am not aware of any non-custom verbosity defaults than pronounce the hyphen as minus. Therefore, though two o'clock plus five o'clock makes *some* vague sense as a time zone adjustment to 7 AM, two o'clock dash five o'clock implies a 3-hour duration from 2 AM until 5 AM rather than the intended meaning of 9 PM the previous day. Quoting a recurrence example from the Microformats wiki at: http://microformats.org/wiki/hcalendar-brainstorming#Laughing_Squid Then we put in the quite lengthy explicit specification of every other time the event occurs, marked up around the human readable description. abbr class=rdate title=20050407T1200-0700/PT7H, 20050408T1200-0700/PT7H, 20050409T1200-0700/PT7H, 20050410T1200-0700/PT6H, 20050412T1200-0700/PT4H, 20050413T1200-0700/PT4H, 200504014T1200-0700/PT7H, 20050415T1200-0700/PT7H, 20050416T1200-0700/PT7H, 20050417T1200-0700/PT6H, 20050419T1200-0700/PT4H, 20050420T1200-0700/PT4H, 20050421T1200-0700/PT7H Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm /abbr In Jaws 8 on Windows XP, this is pronounced, Hey you... yeah you, 'Blindey.' F**k off. ;-) Cheers, 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] proposed title-design-pattern is not backwards compatible, too big of a change
Tantek Çelik wrote: Generalizing this overloading of the title attribute to *any* element seems like a really bad idea from the perspective of minimal change. Any element, but only on specific Microformat classes, each of which has expected RegEx-matchable values. DTSTART, DTEND, DURATION, RDATE, RRULE expect values defined in RFC 2445. TYPE and GEO expect values defined in RFC 2426. This would eliminate the ambiguity of title-or- contents. span class=type title=foopref/spanerred em class=type title=homecasa/em li class=geo title=30.300474;-97.747247Austin/li ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] proposed title-design-pattern is not backwards compatible, too big of a change
Brian Suda wrote: the whole discussion begs the question about what people with assistive technologies ACTUALLY think? A while ago there was a whole report about who screen readers fail with AJAX apps, then someone actually ASKED some blind folks if they could navigate the site... they managed to do so just fine. To what report and response are you referring? Do you have a link? We skirt the issue by moving data to the title attribute of alternative elements, how do we know screen-readers now or later won´t read out those as well? The article states: With custom verbosity settings, it is possible that a screen reader user may hear the text spoken in [the span]..., but that circumstance is much less likely than a fully-expanded ABBR. Screen readers allow custom verbosity settings, so it's possible that someone could enable *[title] to be read, but it is less likely than reading abbr[title] due to the implied expansion semantics of abbr. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Best practice for the abbr pattern
Dr. Ernie Prabhakar wrote: title=2007-03-12T17:00:00 Can you confirm that: a) This will in fact solve the screen reader problem It will not. Though I agree with Jeremy and Tantek that this solution is slightly better than the current recommendation. It is still far from accessible. Tantek and I discussed this format at SXSW as a possible solution, but its only moderately helps for dates, and doesn't help much for datetimes: 2007-04-27 is mostly accessible as it's usually read as either two thousand seven. four. twenty-seven. or two thousand seven dash four dash twenty-seven. Sometimes the leading zero is spoken, too. It's important to note however, that everything past the T is usually gibberish. Even given the *ideal* situation where the ':'s are not spoken as colon, the time zone delimiter is spoken as minus, and the colon separated pairs are spoken as o'clock, the result is still less than ideal. T12:00:00-06:00 Best case scenario tee twelve o'clock zero zero minus six o'clock. Worst case scenario: tee one two colon zero zero colon zero zero dash zero six colon zero zero This also doesn't account for screen readers set to read in other languages. Besides pronunciation phonemes, reader languages have all sorts of rules for writing conventions (i.e. sometime speaking five o'clock for 5:00 in English). I can't begin to guess what problems that that would entail. We'd need to talk to the internationalization team at the manufacturers. I can try to meet with the i18n people on the Voiceover team, but as today, Voiceover doesn't read any title attributes and so doesn't have an issue with abbr-design-pattern. The problem is with the more popular readers, Jaws and Window Eyes. b) This still conforms with all the relevant W3C recommendations It conforms to the ISO spec for dates, and the W3C specs for markup, but the article points to a WCAG reference that indicates abbr [title], acronym[title], td[abbr], and th[abbr] are meant for speaking. Ex. 20 lbs should be spoken twenty pounds. This is not implied for other elements like span[title], em[title], etc. The article proposes keeping abbr-design-pattern for uses such as: abbr class=country-name title=JapanJP/abbr But abolishing its misuse in the following: dates, long/lat, and RFC type values. abbr class=dtstart title=2007-03-27T12:00:00-06:00Noon Central/ abbr abbr class=geo title=30.300474;-97.747247Austin/abbr abbr class=type title=home xml:lang=esCasa/abbr Cheers, James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Best practice for the abbr pattern
Dan Champion wrote: Webadmin - Tenbus wrote: Mike Kaply wrote: Both upcoming and eventful do not have dashes in their dates. They will need to be evangelized. Wikevent.org's got it right http://wikevent.org/en/ Joan_Armatrading_2007_5_7 we don't need evangelising ;-) Ditto for Revish - http://www.revish.com/reviews/090613725X/ danchamp/ :-) You guys are missing the point. Do you talk that way? Is anyone gonna be in thirty point three. Dash ninety-seven point seventy-five anytime soon? I should be there at two thousand seven six nine tee fifteen thirty zero zero dash six o'clock. Explanation: Austin, Texas, USA on June 9th at 3:30PM in spoken ISO (2007-06-09T15:30:00-06:00) and rounded Geo (30.300474;-97.747247). James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[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
Re: [uf-discuss] An Inconvenient hCard
Paul Wilkins wrote: This is a misuse of abbr at best. See: open issue! 2007-01-26 http://microformats.org/wiki/hcard-issues I also see that you are the author of that open issue, and that it's been rejected. Look again. The original rejection was for a different issue. The real issue is open and valid. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] An Inconvenient hCard
On Mar 13, 2007, at 7:56 PM, James Craig wrote: Look again. The original rejection was for a different issue. The real issue is open and valid. Sorry, I sent this two weeks ago but must've been offline until this morning. I've been out of the country and am just now catching up on the threads. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] An Inconvenient hCard
Paul Wilkins wrote: With the abbr design pattern, you encode the machine-readable info around the human-readable words. p class=telabbr class=type title=faxTéléc/abbr: span class=value(514) 123-4568/span/p http://microformats.org/wiki/abbr-design-pattern has more details on the abbre design pattern. This is a misuse of abbr at best. See: open issue! 2007-01-26 http://microformats.org/wiki/hcard-issues James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar
Bob Jonkman wrote: Hi all: Today I had the urge to mark up an arbitrary date, not one that is part of an hCalendar event, eg. Use version 7.0.2 from abbr title=2007-03-055 March 2007/span This is to provide some standarization in presenting dates, but keep them human- readable in arbitrary format. dtstart and dtend aren't appropriate semantic classes in this example. Is there a proper microformat for arbitrary dates? In this case, I think what you are looking for is the 'datetime' attribute on INS and DEL elements. ins datetime=2007-03-055 March 2007/ins This has nothing to do with microformats; it's just semantic HTML. It specifies the time of the insertion or deletion, so I think it's quite appropriate for specifying when a version was released. From the HTML 4 DTD attribute list for INS or DEL. cite%URI; #IMPLIED -- info on reason for change -- datetime%Datetime; #IMPLIED -- date and time of change -- Given that, you might also want to specify the URI for version changes. ins cite=/whatsnew/7.0.2/ datetime=2007-03-05Use version 7.0.2 from 5 March 2007./ins Opinionated rant: ins[datetime] has the added benefit of not sounding like absolute dreck in the more popular screen readers, which is more than one can claim for the Datetime Design Pattern. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Formatting arbitrary dates, not part of hCalendar
Paul Wilkins wrote: While it specifies the time of insertion or deletion, the semantics of that don't match up with what we're wanting to do here. Unless you and Bob are working on that project together, the semantics of the use can only be determined by Bob. The INS and DEL elements are supposed to markup changes to the document Yes, and the line in question referred to a specific date when that copy was inserted OR when that line of text became relevant due to the release of the new version of software. Unfortunately here we have a case similar to BLOCKQUOTE, where an element is used for a purpose that it's was never intended for, and that new purpose eliminates reasonable chances of its actual intended use. I disagree. By your logic, use of DL as a data structure in XOXO would also be a misuse because it's key:value data pairs instead of an actual definition term and description. I'll save the list the semantics argument, but I believe this is well within the proper use of INS. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag title as tag value
Mike Kaply wrote: Microformats that require specific settings on your web server, and access by the user to configure that web server if necessary and a very specific syntax that you might not be able to accomplish with your configuration: rel-tag Don't forget it's also the only one that goes against the microformats mantra: simple conventions for embedding semantic markup. It is neither markup, nor simple. Rather, it's not simple in the majority of cases. Regarding simplicity: 1. Linking to others' tagspace. Simple? Yes. Practical? Probably not. 2. Creating a physical directory for every tag I create. Simple? Yes. Tedious? You bet. Fully localizable with a full UTF-8 character set? Only if you want to escape them all. That'd be pretty. 3. URL rewriting. Practical? Very. Recommended? Yes. Simple? Certainly not. Low barrier to entry? I'd argue that anything requiring RegEx does not entail a low barrier to entry... therefore, not simple. I believe we all agree that a restful tagspace is best. I also think no one here suggests *requiring* a title if the tagspace is there. We are only requesting an alternative that is both simple and markup. Something anyone can implement. James PS. Have you seen the emperor's lovely new clothes? ;-) PPS. If that counts as snarky, call me out on it. It's meant in fun. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] issue rejection governance? (Was: rel-tag title as tag value)
Mike Kaply wrote: I want a solution that involves the web page, NOT the server. I agree, but my response here is not about rel-tag. It uses rel-tag as an example in a larger issue regarding issue rejection. In the month or so I've been on the discussion list, the rel-tag title issue has been raised many times, indicating a valid need for a less-than-ideal alternative. Many of the stake-holders seem to have tagspace-enabled sites (Technorati, Flickr, etc.) and, while that is the ideal situation, they also seem defiant in their willingness to admit creating a tagspace is problematic for many users. I tracked down what I believe to be the documentation of the first time this issue was rejected. Quoted from: http://microformats.org/wiki?title=rel-tag- issuesdiff=4885oldid=4881 Issue 3: It's not reasonable to restrict the host's REST implementation according to this spec's rather limited idea of a 'good' tag URL. The idea of tags as query parameters is rejected without justification, for example. Query parameters are a perfectly legitimate means of denoting state.' REJECTED, IGNORES ESTABLISHED PRACTICE. Flickr and del.icio.us and other tagging sites established the defacto standard of having the tag term be denoted by the last segment in the URL and thus defined what makes a 'good' tag URL. rel- tag has codified this good practice. I was not on the list at the time, and therefore cannot verify that this issue was not discussed openly, but I also cannot find on the wiki the due process of issue rejection. Format rejection is defined, but issue rejection seems arbitrary. The closest thing I can find is some issues are REJECTED for a number of obvious reasons and others contain longer discussions on the Microformat Issues page. I am not implying the uf group step to the deliberation level of ISO or the W3C, but some issues should not be noted as REJECTED by an individual, at least not without fair consideration and voting. If this process exists, or if there is a process for rejection APPEAL, it needs to be documented. If it does not exist, it needs to be defined. For example, the previously noted rejection statement seems opinionated to me. If for no other reason, the frequency of this request demands that it receive more consideration and deliberation. Thanks for your consideration, James Craig ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] country-code may be missing from hCard/adr spec
Nic James Ferrier wrote: James Craig wrote: i18n note: country-code may be missing. Usually a postal-code prefix, such as FIN-00630 Helsinki or L-4750 Petange (Luxembourg), used in addition to, or in lieu of, the country-name. Thoughts? I do abbr class=country-name title=UKUnited Kingdom/abbr when I want a country code. Assuming you meant this: abbr class=country-name title=United KingdomUK/abbr That's fine, but country-name and country-code are not mutually exclusive. See in addition to comment above. For example: Pazmaniteng 24-9 A-1020 Vienna AUSTRIA Sølvgade 83, opg. S DK-1307 København K. DENMARK ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] country-code may be missing from hCard/adr spec
Michael MD wrote: It looks like what is really needed is a standard way to represent standard country codes - so that machines can look up related information for the country without the hit and miss problems of freeform text names for places. (but keeping it simple for parsers or authors) No, there are international standard two- and three-letter country codes, but these are not used consistently within each country's postal service. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] country-code may be missing from hCard/adr spec
i18n note: country-code may be missing. Usually a postal-code prefix, such as FIN-00630 Helsinki or L-4750 Petange (Luxembourg), used in addition to, or in lieu of, the country-name. Thoughts? http://microformats.org/wiki/adr#Property_List ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)
Benjamin West wrote:
a href=javascript:ahah('Waldorf-Astoria-
Photo.html','Photo');photo/a
The best practice is to wire the event up, and to use a button
when
the element is not truly a link.
How is this not a link?
You can link to a template that takes the data as a parameter:
a href=hotels.php?h=waldorf id=photophoto/a
The difference, of course, is the first example doesn't have a URI.
Your example does have a URI. If clicking on an anchor element won't
ever take you to a new page (because there is no URI), don't use the
anchor element!
I disagree. You should be practicing accessible, progressive
enhancement. The first example does have a URI, it's the relative
path to Waldorf-Astoria-Photo.html and should be set up to work from
a spider, script disabled browser, or even a right-click to open
link in new tab. Your practice of wiring javascript to a button is
effectively hijacking the user's browser will do nothing except
ensure the content is inaccessible to all but a few targeted user
agents.
a href=Waldorf-Astoria-Photo.html class=ahah-photophoto/a
Works as a regular link and–once the right event handlers are
assigned–will work as a JS-enhanced interface.
James
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [advocacy] Contacting Blogger (was Re: [uf-discuss] Rel-tag issues...)
On Feb 12, 2007, at 7:37 AM, Mike Kaply wrote: On 2/11/07, Kevin Marks [EMAIL PROTECTED] wrote: Try making a fresh post, or republishing that one. This may be a blogger issue with publishing via ftp? When I debugged this problem, that is exactly what I discovered. It is only broke when you publish via FTP. It is not broke when you are hosted by blogger. I switched to WordPress because of this problem. Exactly. But this is not a problem with Blogger, this is a solution to a larger, more practical problem than rel-tag. The Blogger developers have to support plain-old web hosts without modification of the server config; a link URL to a restful tag space is not going to work on most simple web hosts. The Blogger developers know this and have to append .html onto the files they publish. The fact that the Blogger developers cannot implement to spec–or would need an even hackier workaround* in order to implement the rel-tag spec–is indicative of a problem with the spec. I'm not saying we all need to agree to the solution, I'm merely suggesting that it's either naive or arrogant to defiantly deny there is a problem. Cheers, James PS. The hackier workaround for Blogger; feel free to forward to your contacts there if you think this is a viable solution (I don't): myURL.com links tagspace to blogger redirect site like so: blogger.com/tags/redirect/siteID/tagspace with a 301 to back to the actual tagspace on the hosted site. myURL.com links to: a rel=tag href=http://blogger.com/tagredirect/mySiteId/foo;foo/a http://blogger.com/tagredirect/mySiteId/foo responds with a 301 (moved perm) to http://myURL.com/labels/foo.html Though this is a solution (finger quotes emphasized), I hope the ridiculousness of it hammers home our point that there is a problem with the rel-tag spec. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [advocacy] Contacting Blogger (was Re: [uf-discuss] Rel-tag issues...)
Scott Reynen wrote: This may not solve 100% of issues, but I think Blogger could make over 90% of plain-old web hosts work with the current rel-tag spec by simply uploading tagname/index.html instead of tagname.html and then point links to tagname/ (which resolves to index.html on most plain-old web hosts). The simplest solution is usually the best, eh? Good idea. *slaps forehead* For the record though, I still think there should be markup-only fallback, such as putting the tagName in a title attribute. either a rel=tag href=/search/tag/fooAll uses of FOO/a or a rel=tag title=foo href=/search?tag=fooAll uses of FOO/a ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Rel-tag issues, i can't create my own tagspace!
Brian Suda wrote: I would love to have my host have the latest, greatest version of PHP technology. If they don't i don't go complain to PHP and ask them to back-port functionality to an earlier version. I buck it up and either move hosts, pay for the better service or co-locate my own box. It is silly to think that it is a problem with the specification. Quoting from About Microformats: Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. This also implies they should be easy to implement. Co-locating your own box and rocking mod_rewrite can hardly be considered easy implementation of a simple data format. while i understand a given server setup might have limitations, that's not a microformats problem, that is your problem. Your taking the elitist way out. I believe it's a microformats problem to encourage adoption and to figure out a standard that will work for the most people. Which is better? A massive dissemination of usable tag metadata, or a smaller subset of tag metadata with pretty URLs? James PS. Nice change of the subject line. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] rel-tag title as tag value (Was: Should microformat features (like rel-tag) have explicit scope?)
Edward O'Connor wrote: James Craig wrote: Requiring a restful URL for rel-tag (though the ideal solution) is expecting a lot more of a µf author than requiring authors to add a bit of markup. While properly implementing a tag space may be slightly more difficult[1] than other methods for some developers or organizations, I think the benefits far, far outweigh the cost. I'm not arguing that, and I certainly agree. I'm asking about an acceptable fallback for those few circumstances where implementing a tag space is technically–or more likely, politically–not an option. James Craig wrote: Practical alternative for some cases (using title value): a rel=tag title=tagName href=/ theOtherDevelopersHideouslyComplexUrl.extension? queryJunk=tagNametext/a If the ugly URL isn't enough of an explanation, consider that front-end developers make up a majority of the converts in the area of web standards. It is not unthinkable that a front-end developer would want to implement rel-tag even when the server- side developer is unwilling to implement a restful URL. There ought to be a markup fallback. Thanks, James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
