Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
I don't want to get anyone's hopes up but there's an interesting comment from Lawrence Meckan on the WaSP blog post: http://www.webstandards.org/2007/04/27/haccessibility/#comment-57838 He's getting good results from up-to-date screen readers with advance verbosity settings and this little caveat about the markup: I’ve also expanded the abbr pattern to include a span inside it, essentially duplicating the semantic structure, in order to do a fix for IE6 not styling abbrevations. If there's a chance that adding an extra span inside the abbr element somehow helps screen readers, then that should probably be included in the test cases: http://microformats.org/wiki/assistive-technology-abbr-results Like I said, we shouldn't get our hopes but it's certainly worth investigating. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
I've been following this thread with some interest, and I have a question: what is the ideal amount of human interface with machine- readable content (when different from human-readable content) in microformats? In visual browsers, the current common interface is a minimal readability of machine-readable content only while a cursor is hovering over the abbr. Is this middle ground between full readability (e.g. span class=dtstart2007-05-10 23:30:00-06:00/ span) and zero readability (e.g. external RDF) a goal, or an unintended side effect of using abbr? If the latter, I think we should probably focus on potential solutions that would remove this kind of exceptional not-for-human-consumption machine-readable content from both aural and visual browsers. And if the former, we should focus on solutions which simply improve the interface of such content. But I'm not clear on what the goal is here. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: changing abbr-design-pattern to title-design-pattern?
Lawrence wrote: I should have more results uploaded late Wednesday AEST (I forgot to record the audio outputs in the initial test for this behaviour), which should mean they should go live around midday in Brighton. Excellent! I really appreciate you doing this. I see three possible outcomes: 1) I've done something horribly wrong to get the results I have. 2) That extra span fixes it, somehow. 3) Something else..? If we can other people (probably WaSP ATF folks) to run the same tests (especially on JAWS pre-version 8) then I think we'll get an answer pretty quickly. Fingers crossed that it's number 2. ;-) Again, a big thank you, Lawrence (and Benjamin, James, Patrick and anyone else taking the time to run these kind of tests). Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Authority (was: Text::Microformat - a uf parser for Perl)
Hi Andy, On Apr 28, 2007, at 12:57 PM, Andy Mabbett wrote: I can't prevent people from calling cats dogs either, but I'm certainly going to say something when it happens. This isn't case of people calling cats dogs; it's closer to the dispute over whether a Jack Russell Terrier is a breed or a mongrel. Trust me -- you don't want to offend the Jack Russell lobby. :-) http://www.dogbreedinfo.com/jackrussellterrier.htm In fact, the analogy is actually pretty apt. A breed association is nothing more than an association of people who are passionate about something to they point where they have decided to pursue and defend a particular definition. Sure, eventually they get registered by the AKC so we recognize them as a official, but the passionate pursuit exists (and is considered legitimate) even before the formal recognition. In fact, it is the very purity of their definition which entitles them to formal recognition. Something to think about... -- Ernie P. http://www.akc.org/reg/fss_details.cfm ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [rethinking abbr] Does object deserve another look?
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
[uf-discuss] hReview type question
I know this is partially addressed in the first hReview FAQ on the microformats wiki, but I have a more general question. I have been reading a lot about microformats, and have used hCard, but am fairly new to them overall. The possible values of 'type' are limited to: product | business | event | person | place | website | url. Why? It seems quite strange and indirect, even undesirable, to me to add a link to the Wikipedia definition of a book (as a tag, suggested in the FAQ) to my academic book review as a way of simply saying I am reviewing a book. So my question is, why do the types have to be limited to this list? And, if there is a good technical reason why they should be, why not allow a sub-type, that is open to any value? As it is, the extremely general nature of the types available make them much less useful. No one is ever looking for a review of any old business in Santa Cruz, CA, they are looking for a restaurant or movie theater. Any information on this topic is really appreciated. ___ 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: I don't want to get anyone's hopes up but there's an interesting comment from Lawrence Meckan on the WaSP blog post: http://www.webstandards.org/2007/04/27/haccessibility/#comment-57838 He's getting good results from up-to-date screen readers with advance verbosity settings and this little caveat about the markup: I’ve also expanded the abbr pattern to include a span inside it, essentially duplicating the semantic structure, in order to do a fix for IE6 not styling abbrevations. If there's a chance that adding an extra span inside the abbr element somehow helps screen readers, then that should probably be included in the test cases: http://microformats.org/wiki/assistive-technology-abbr-results Like I said, we shouldn't get our hopes but it's certainly worth investigating. Just spoke quickly to Jon Gibbins on the phone, and he mentioned that it appears to be more of a bug in JAWS due to the use of sIFR (which causes JAWS to sometimes read titles, and sometimes not)...but he'll be testing this further to come to some hard evidence on that. 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] hReview type question
I think this is a great question Nora. We're building a review publisher/aggregator built on hReview and we ended up dropping type from our reviews as it was confusing our beta testers and not really adding any value to our site. What is a movie? Most testers did not consider it a product, some thought it might be an event if they saw it in a movie theatre. Many even found the difference between product and business confusing. So we removed type and just have add address details if you have them to cover business-style reviews. We let tags take care of everything else. I can see the logic of saying if type=business then hCard mandatory and if type=event then hCalendar mandatory but I'd be interested to hear about more uses of this limited list. Conor Nora Brown wrote: I know this is partially addressed in the first hReview FAQ on the microformats wiki, but I have a more general question. I have been reading a lot about microformats, and have used hCard, but am fairly new to them overall. The possible values of 'type' are limited to: product | business | event | person | place | website | url. Why? It seems quite strange and indirect, even undesirable, to me to add a link to the Wikipedia definition of a book (as a tag, suggested in the FAQ) to my academic book review as a way of simply saying I am reviewing a book. So my question is, why do the types have to be limited to this list? And, if there is a good technical reason why they should be, why not allow a sub-type, that is open to any value? As it is, the extremely general nature of the types available make them much less useful. No one is ever looking for a review of any old business in Santa Cruz, CA, they are looking for a restaurant or movie theater. Any information on this topic is really appreciated. ___ 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] User Interface for Firefox/Operator
On 4/27/07, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Mike, Is this going to be replacing XUL, XBL, etc etc? Actually, we're looking more for discussion just around how you would interact with microformats in the browser. For instance, do people like the Siderbar interface for Tails Export? Or do they prefer Tails? Or the Operator toolbar? should there be a button on the toolbar for Contacts/hCards? Or should microformat interaction be limited to buttons that perform actions (like add to Google Calendar). I'd really like to try to have a discussion with folks on this subject. Again, the forum is: https://labs.mozilla.com/forum/index.php/topic,77.0.html Thanks! Mike Kaply ___ 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?
Patrick H. Lauke wrote: Jeremy Keith wrote: snip If there's a chance that adding an extra span inside the abbr element somehow helps screen readers, then that should probably be included in the test cases: http://microformats.org/wiki/assistive-technology-abbr-results Like I said, we shouldn't get our hopes but it's certainly worth investigating. Just spoke quickly to Jon Gibbins on the phone, and he mentioned that it appears to be more of a bug in JAWS due to the use of sIFR (which causes JAWS to sometimes read titles, and sometimes not)...but he'll be testing this further to come to some hard evidence on that. P Hi all - and thanks, Pat. I've just joined the mailing list and am catching up with the discussions. I'm in the process of running more tests. I'll post results on my test pages and add to the wiki where I can. I've moved my microformats tests and results to a dedicated page here: http://dotjay.co.uk/tests/screen-readers/microformats/datetime-design-pattern/ I'll try to include the test-cases mentioned on the wiki: http://microformats.org/wiki/assistive-technology-abbr-results To comment on the redundant span test-case... A cursory test of that in context on absalom.biz using IE 7 resulted in JAWS behaving strangely. I intend to test this more, but my observations are as follows: JAWS wasn't reading out the title attribute in place of the element's content (a human-readable date) when set to expand abbreviations. Probing the element information (Ins+Shift+F1) didn't report a title attribute on the element. After restarting JAWS and IE 7, the not-so-nice ISO date in the title attribute was read out in place of the human-readable date. The discrepancy seems to have indicated a false positive - the human-readable date was heard when expecting the title expansion to be spoken in its place. I figure it might be something to do with the sIFR in use on the page tested on absalom.biz, as it was causing other issues when reading past the h3 just above the microformatted date. It could be something to do with using the redundant span, but it's unlikely. Jon -- gr0w.com dotjay.co.uk ___ 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?
On Apr 30, 2007, at 8:20 PM, James Craig 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. The use of namespaces is really irrelevant in this case, as 1) rel is only allowed on a and 2) dates aren't relationships. Adding namespaces wouldn't solve either of those problems. But on the topic of namespaces in general, the web already has semantic initiatives using namespaces, e.g. RDF. Microformats are currently an alternative. Adding namespaces to microformats would remove that alternative. Even if you think namespaces are good, removing alternatives is a bad method of testing theories. Peace, Scott ___ 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?
Le 1 mai 2007 à 09:53, James Craig a écrit : 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 See what has been done in [duri and tdb URN namespaces based on dated URIs][1] urn:tdb:date:encoded-URI Then let's see if it is possible to do something like. object class=dtstart data=urn:date:2005-01-25January 25/object It could be easily defined at IETF. And I wonder about a class=dtstart href=urn:date:2005-01-25January 25/a [1]: http://larry.masinter.net/duri.html#dates -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: Fwd: [uf-discuss] Legal implications of using Microformats
Friday, April 27, 2007 9:23 AM, Manu Sporny wrote: Brian Suda wrote: --- if you can give-us any other information, who exactly the company is, etc and any other information from the legal team we can attempt to work around these problems or debunk the FUD. [snip] For those of you that don't know where this discussion started - it was started by Guy Fraser on microformats-new: http://microformats.org/discuss/mail/microformats-new/2007-April/000241.html The concern is that there is no standard copyright or patent statement or policy that applies to the entire Microformats website. Specifically the examples, formats, brainstorming, proposal, draft and specification pages have a mix of copyright statements (some not at all). This can cause problems if an individual authors a Microformat without releasing copyright or patent claims. Microformats can stick around in the draft process for a long time. Often they have a statement of intent to release it under a certain copyright/royalty-free licensing model. Intent to provide under no restrictions is very different from provide under no restrictions. [snip] I share Manu's concern and have had minimal luck trying to get traction on this topic on the open-issues section of the wiki and in my conversations with Rohit and others. Despite the terminology, Brian, it isn't simply a matter of FUD. It's a matter of the actual legal rights and licenses. The disconnect between the copyright statements on the microformats themselves and the blanket assertion on the website and elsewhere that uFs are released under creative commons is a misrepresentation, one that may or may not create liabilities for the admins, but it certainly creates uncertainties for any potential uF user and developer. The problem is this: when I place a bet on a technology like microformats, I'm betting that the underlying licenses will allow me to do business effectively on predictable terms throughout the lifetime of my business. In fact, I'm betting not just my effort, but the considerable investments made in my company by others. The first ramification is that the current licenses are de facto and may not be securable should a dispute arise. I'm not a lawyer so I won't dive into the issue of whether or not there is an implied license and whether or not that would be upheld in a court. I shouldn't have to speculate about some potential future licensing arrangement by the holders of the uF copyrights. It should be known today, at the point that I contribute to, and utilize, the IP being developed by this community. Second, it's even worse if a copyright holder or admin is simultaneously attempting to secure patents that read on uFs. That's coercive and manipulative, and given the assertions by the admins that uF will be CC, could constitute anti-trust behavior should a patent holder later attempt to assert such a patent after establishing a uF as a de facto industry standard. Fortunately, I know of no one who is actually making such an attempt. However, without a clear, binding statement on behalf of those creating the IP, it is always a possibility. Third, there is no actual legal entity to license from, negotiate with, and seek redress from should such a problem arise. If the IP for microformats was owned by a single entity, such as a trade association or standards body, then one would at least have a single point of recourse in case the promises run into problems, such as perhaps not being owned by the individuals who offered it to the community (because it is owned by their employer, for example). Instead, the copyrights and liability for community action are disturbingly spread throughout a number of individuals. Any one of whom could make a frustrating choice, or overlook a complicating situation, and thereby trigger a cascade of issues and potential lawsuits. Having the IP in an ambiguous state is a mess. I'm well aware of the anti-trust concerns of several members of the cabal, as well as the apparent belief that ignoring these issues is the lightweight way to grow this movement. However, several companies have already backed off their involvement in uF precisely because the licensing and liability issues are so murky. A particular challenge is that the vast majority of companies who make similar decisions will not bother to explain it to the rest of the community. Once the choice to move on is made, there is precious little return from trying to convince a governance-challenged cabal to actually change their behavior. A dismissal of the legal issues does not make the legal issues go away. It makes those who understand the legal issues go away. I understand that some members of the cabal have been discussing these issues, but I've yet to see or hear of any proposals to address them. Brian's most recent response leads me to believe that the do nothing faction is carrying the day, hence this email. My
