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 specifically about things like dtstart and dtend in hcalendar. My scripts do not require the title attribute to be present, but if it is there it will look at its contents for the value. That is an incorrect implementation according to the current spec. I hope that the current spec will be changed at some point (I voice my disapproval of the abbr-design-pattern frequently), but according to the current spec, this behavior should ONLY be present on the abbr element. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] dfn design pattern (proposal)
On 8/20/07, Michael MD <[EMAIL PROTECTED]> wrote: > 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) >--- 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. I was just commenting that the proposed dfn idea would be easy to implement at the parsing end and that some parsers may already handle it with little or no modification. I was talking specifically about things like dtstart and dtend in hcalendar. My scripts do not require the title attribute to be present, but if it is there it will look at its contents for the value. >http://example.com"; class="url" title="my homepage">... > >The value of URL is NOT controlled by the TITLE, but instead the class URL >and the 'A' element. for url it does look in href rather than title for the value. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] dfn design pattern (proposal)
On 8/20/07, Michael MD <[EMAIL PROTECTED]> wrote: > 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) --- 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. http://example.com"; class="url" title="my homepage">... The value of URL is NOT controlled by the TITLE, but instead the class URL and the 'A' element. If you have further parsing questions, we should take this up on the dev list. thanks, -brian -- brian suda http://suda.co.uk ___ 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] dfn design pattern (proposal)
> 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) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] dfn design pattern (proposal)
This is may be somewhat premature as the results of the assistive technology tests aren't back yet: http://microformats.org/wiki/assistive-technology-abbr-results But if we do need to look at alternatives to the abbr design pattern, one of the ideas that came up in discussion was to use the dfn element. I've put together a page on the wiki outlining the thinking behind this proposal as well as highlighting some of the potential downsides: http://microformats.org/wiki/dfn-design-pattern On the plus side, I think it's better not to widen the title design pattern to apply to any element (which is essentially what the span proposal is saying) so this would only be a slight expansion. On the down side, the semantics of "defining instance" aren't always going to be applicable for datetime, geo, etc. But I think it could well cover 80% of use cases. What's needed: * Arguments for or against the use of dfn as a container for the title design pattern: is this semantic abuse or is it simply stretching semantics (like the abbr design pattern). * Document usage of the dfn element in the wild: I believe it is often used in conjunction with the title attribute. * Test results from screen readers to find out if dfn is treated as a special case (like abbr and acronym) or whether it is "safe" to use. * Feedback from the people building parsers (Mike Kaply, Brian Suda, etc.) on whether this would be tricky or easy to implement. I'm fairly certain that this proposed design pattern would *not* cover 100% of use cases but it might cover enough situations to be viable as *an alternative* to the abbr design pattern. Note that I am not suggesting that the abbr deisgn pattern should be deprecated. I believe it has its place but I think it would be good to provide an alternative to address the accessibility question. For instance, even if the dfn design pattern is adopted, I will still use the abbr element for cases like this: August 19th That's because I believe exposing the string "2007-08-19" either to sighted or blind users is an acceptable, readable, understandable way of formating a date. But for a string like "2007-08-19T12:39:00" I would like to have an alternative that wouldn't directly expose that format to the user. That's my own call, of course. I suspect that others, offered the choice of an alternative to abbr, will always go for the alternative. And others will choose to always stick with abbr. I think that all of those positions should be accommodated. Look forward to getting your feedback, Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
