[uf-discuss] accessibility test pattern alternatives for abbr-design-pattern

/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/microfo

Re: [uf-discuss] dfn design pattern (proposal)

Michael MD wrote: --- just a quick FYI, this would be an incorrect implementation. The appearance or the absence of the TITLE attribute does not control the parsing, it is the semantics of the property and the element. I guess I wasn't very clear. No, you were clear. I was talking specific

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

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 te

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 include pattern has some per

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 include pattern has some performance problems, it would be best to use t

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

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 __

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.

[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

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: Fromage Where's the visible data there? By your logic, tags should only work on the anchor element's content, not the tai

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

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.

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

Re: [uf-discuss] human readable date parsing

Tantek Çelik wrote: On 5/3/07 7:10 PM, "Patrick H. Lauke" <[EMAIL PROTECTED]> wrote: But to bring it back to the original argument, the routine extraction does not necessarily have to equate to data visible in, say, a tooltip. The routine extraction may well be mediated via some machine in

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

Re: [uf-discuss] human readable date parsing

Breton Slivka wrote: July 26th, 2005 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.

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 b

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 f

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

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: DD Month 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/namespace

Re: [uf-discuss] [rethinking abbr] Does 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

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 t

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,

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/semanticw

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 poss

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

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) 3 There is no ambiguity here. From the spec, the parser

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

idding 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, th

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 instr

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 o

[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 edi

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 we don't need evangelising ;-) Ditto for Revish - h

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. Tan

Re: using class to store type value (was Re: [uf-discuss] An Inconvenient hCard)

Tantek Çelik wrote: Andy Mabbett wrote: A further thought - this wouldn't be an issue, if we had separate classes, rather than one class and several types, thus: (514) 555-4561 (514) 555-4562 (514) 555-4563 (514) 555-4564 This was actually initially attempted and re

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 u

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

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. Téléc: class="value">(514) 123-4568 http://microformats.org/wiki/abbr-design-pattern has more details on the abbre design pattern. This is a misuse of abbr at best. See

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

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 5 March 2007 This is to provide some standarization in presenting dates, but keep them human- readable in arbitrary format. dtstart and

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

[uf-discuss] issue rejection governance? (Was: rel-tag title as tag value)

uest 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

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

[uf-discuss] adr should be

My recent adr wiki change from to class="adr"> was reverted. Why? is the most appropriate element for addresses. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-

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 United Kingdom when I

[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 __

Re: [uf-discuss] Tutorial on AHAH (such a cool technology!)

Benjamin West wrote: > > photo > > > > 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: photo The difference, of course, is the first example d

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 pl

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 yo

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 i

[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 method

Re: [uf-discuss] Should microformat features (like rel-tag) have explicit scope?

Ryan King wrote: Requiring authors to add markup in order to make rel-tag's scope explicit makes it hard to publish the data and doesn't solve any real problem. Hijacking a thread to mention another rel-tag oddity: Requiring a restful URL for rel-tag (though the ideal solution) is expect