From brian.suda at gmail.com Fri Jun 1 06:36:25 2007 From: brian.suda at gmail.com (Brian Suda) Date: Fri Jun 1 06:36:29 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> Message-ID: <21e770780706010636n4616ba4bu6cec799d3a1f14b6@mail.gmail.com> On 5/31/07, David Janes wrote: > I thought it did markup! I totally see what you are saying here > though; the question here is whether we include the DOM nodes that > specify entry-content. This isn't in the spec, and you wouldn't want > to do it everywhere (entry-title, for example) but it would make sense > if it did. --- maybe i mis-interpreted this, but do you mean that in a

Content

the should be carried through? or converted to *Content*? -brian -- brian suda http://suda.co.uk From davidjanes at blogmatrix.com Fri Jun 1 07:03:49 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Jun 1 07:03:52 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e770780706010636n4616ba4bu6cec799d3a1f14b6@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <21e770780706010636n4616ba4bu6cec799d3a1f14b6@mail.gmail.com> Message-ID: <21e523c20706010703u65aee949m99b1dffee3bd2a44@mail.gmail.com> On 6/1/07, Brian Suda wrote: > On 5/31/07, David Janes wrote: > > I thought it did markup! I totally see what you are saying here > > though; the question here is whether we include the DOM nodes that > > specify entry-content. This isn't in the spec, and you wouldn't want > > to do it everywhere (entry-title, for example) but it would make sense > > if it did. > > --- maybe i mis-interpreted this, but do you mean that in a >

Content

> > the should be carried through? or converted to *Content*? The strongs (i.e., and all other HTML) should be carried through. Interesting -- are people reading the spec such that only text is implied? Regards, etc... David -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From brian.suda at gmail.com Fri Jun 1 07:25:54 2007 From: brian.suda at gmail.com (Brian Suda) Date: Fri Jun 1 07:25:56 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e523c20706010703u65aee949m99b1dffee3bd2a44@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <21e770780706010636n4616ba4bu6cec799d3a1f14b6@mail.gmail.com> <21e523c20706010703u65aee949m99b1dffee3bd2a44@mail.gmail.com> Message-ID: <21e770780706010725y6c910cb6ld43669bbc825164c@mail.gmail.com> On 6/1/07, David Janes wrote: > > --- maybe i mis-interpreted this, but do you mean that in a > >

Content

> > > > the should be carried through? or converted to *Content*? > > The strongs (i.e., and all other HTML) should be carried through. > > Interesting -- are people reading the spec such that only text is implied? --- maybe that is a good thing, if i am converting hFeed into something that is NOT html, say MySQL statements, or a simple CSV list. Should it have the HTML mark-up or should the app be allowed it to be 'down-cast' to simple ASCII? is this a spec issue? i don't think the spec should mandate that it NEEDS to be HTML, it should be left upto the transforming app. It makes complete sense to do so when going from HTML+hAtom->atom, but not much sense when converting to TXT or something else. For instance, in hCalendar there is a NOTES field, the spec doesn't say what to do with any HTML formatted text and how to style it. X2V attempts to add some fancy ASCII code around *strong* and others, but this is above and beyond the spec. This is because the ics file does not understand HTML mark-up, but maybe google calendars does, so for another app it makes sense to preserve that HTML mark-up in the NOTES field. Maybe there is a way to clarify this on the wiki as some sort of SHOULD depending on the intended output? -brian -- brian suda http://suda.co.uk From mail at ciaranmcnulty.com Fri Jun 1 07:45:49 2007 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Jun 1 07:45:53 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e770780706010725y6c910cb6ld43669bbc825164c@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <21e770780706010636n4616ba4bu6cec799d3a1f14b6@mail.gmail.com> <21e523c20706010703u65aee949m99b1dffee3bd2a44@mail.gmail.com> <21e770780706010725y6c910cb6ld43669bbc825164c@mail.gmail.com> Message-ID: On 6/1/07, Brian Suda wrote: > --- maybe that is a good thing, if i am converting hFeed into > something that is NOT html, say MySQL statements, or a simple CSV > list. Should it have the HTML mark-up or should the app be allowed it > to be 'down-cast' to simple ASCII? is this a spec issue? I don't think it's a spec issue at all. Nearly ALL* of the fields in hAtom are going to be (X)HTML (for instance entities will be escaped) and if the consuming application needs them in a specific text format then it's up to the application to determine how/why it should downconvert them to text. The hCard-Parsing wiki describes a recommended method[1] for converting (X)HTML to plaintext, but I'm dubious about whether it's particularly within the Microformats domain (I wouldn't argue it's not useful!). If we do want a generic recommendation for how to parse HTML into text, it's a good place to start. -Ciaran McNulty * I'm thinking the exceptions are that that dates are ISO8601 and that category names will be rel-tag and therefore RFC3986 encoded [1] http://microformats.org/wiki/hcard-parsing #Plain_Text_Formatting_of_Structural.2FSemantic_HTML From ryan at technorati.com Fri Jun 1 10:55:23 2007 From: ryan at technorati.com (Ryan King) Date: Fri Jun 1 10:55:34 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> Message-ID: <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> On May 31, 2007, at 11:29 AM, David Janes wrote: > On 5/31/07, Ryan King wrote: > >> Another option is that entry content is: >> >>

Content

>>

More Content

>> >> >> Is there a reason why hAtom as currently spec'ed only does text, not >> markup? > > I thought it did markup! I totally see what you are saying here > though; the question here is whether we include the DOM nodes that > specify entry-content. This isn't in the spec, and you wouldn't want > to do it everywhere (entry-title, for example) but it would make sense > if it did. You're right, I'm suggesting that only for entry-content (and maybe entry-summary) that we take the nodes that have the class name on them. The reason? I've seen this several times: <... class="hentry"> ...

...

...

It makes sense, to me, to put the paragraph nodes, intact, in the content. -ryan From ryan at technorati.com Fri Jun 1 10:57:23 2007 From: ryan at technorati.com (Ryan King) Date: Fri Jun 1 10:57:27 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e770780706010725y6c910cb6ld43669bbc825164c@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <21e770780706010636n4616ba4bu6cec799d3a1f14b6@mail.gmail.com> <21e523c20706010703u65aee949m99b1dffee3bd2a44@mail.gmail.com> <21e770780706010725y6c910cb6ld43669bbc825164c@mail.gmail.com> Message-ID: On Jun 1, 2007, at 7:25 AM, Brian Suda wrote: > On 6/1/07, David Janes wrote: >> > --- maybe i mis-interpreted this, but do you mean that in a >> >

Content

>> > >> > the should be carried through? or converted to *Content*? >> >> The strongs (i.e., and all other HTML) should be carried through. >> >> Interesting -- are people reading the spec such that only text is >> implied? > > --- maybe that is a good thing, if i am converting hFeed into > something that is NOT html, The spec just deals with how to convert to the Atom model. Your application can do whatever it wants with it from there. If a lot of people are converting to plain text, though, it would be useful to specify an algorithm (as we have on http://microformats.org/wiki/ hcard-parsing). -ryan From davidjanes at blogmatrix.com Fri Jun 1 10:59:59 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Jun 1 11:00:04 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> Message-ID: <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> On 6/1/07, Ryan King wrote: > On May 31, 2007, at 11:29 AM, David Janes wrote: > > > On 5/31/07, Ryan King wrote: > > > >> Another option is that entry content is: > >> > >>

Content

> >>

More Content

> >> > >> > >> Is there a reason why hAtom as currently spec'ed only does text, not > >> markup? > > > > I thought it did markup! I totally see what you are saying here > > though; the question here is whether we include the DOM nodes that > > specify entry-content. This isn't in the spec, and you wouldn't want > > to do it everywhere (entry-title, for example) but it would make sense > > if it did. > > You're right, I'm suggesting that only for entry-content (and maybe > entry-summary) that we take the nodes that have the class name on > them. The reason? I've seen this several times: > > <... class="hentry"> > ... >

...

> >

...

> > > > It makes sense, to me, to put the paragraph nodes, intact, in the > content. I concur. Time to start ramping up for hAtom 0.2, if I can get some blocks of free time. Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From ryan at technorati.com Fri Jun 1 11:27:24 2007 From: ryan at technorati.com (Ryan King) Date: Fri Jun 1 11:27:27 2007 Subject: [uf-discuss] atom:category scheme Message-ID: There has been some previous discussion[1] of this (in 2005!), but it seems to have been lost. I think we should use rel-tag tagspaces for atom category schemes. For those not familiar with Atom, category elements define 3 attributes: term, label and scheme. hAtom currently defines mapping to term and label (from the tag and text). I think we should map rel-tag tagspaces to atom:category schemes. I've put an entry on [2] at [3]. Any reason why we shouldn't do this? -ryan 1. http://microformats.org/wiki/hatom-issues#rel-tag 2. http://microformats.org/wiki/hatom-issues 3. http://microformats.org/wiki/hatom-issues#atom:category_scheme From ryan at technorati.com Fri Jun 1 11:41:08 2007 From: ryan at technorati.com (Ryan King) Date: Fri Jun 1 11:41:13 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> Message-ID: <62225F6C-F1ED-4AE9-ADB6-F32A36BC8F56@technorati.com> On Jun 1, 2007, at 10:59 AM, David Janes wrote: > I concur. Time to start ramping up for hAtom 0.2, if I can get some > blocks of free time. I'm more than willing to help. I have time to spend on it right now. I'll work on collecting issues to deal with. -ryan From chris.messina at gmail.com Fri Jun 1 21:38:37 2007 From: chris.messina at gmail.com (Chris Messina) Date: Fri Jun 1 21:38:41 2007 Subject: [uf-discuss] Fwd: [whatwg] Predefined classes are gone In-Reply-To: References: <84ce626f0705162212t57241902x9f7fe3f83be567db@mail.gmail.com> <1bc4603e0705180535taedb08cr517b4680f9cedd68@mail.gmail.com> <3A1EE16A-92BE-440D-AA3B-7AF376D7E367@apple.com> Message-ID: <1bc4603e0706012138i38d47095hc7b2d6ae4ff99468@mail.gmail.com> I suppose I don't disagree with Maciej's point, but primarily take umbrage with the seemingly "random" classes that were going to be used as predefined values. "Copyright" was the biggest offender -- and a symptom of fflawed thinking -- given the established and widely used rel-license microformat. If the standards groups did more of what you say they do and simply codify existing best or common practices, then I would have fewer concerns about their work. Indeed, I see a way for microformats to fit into and contribute to their work. To date, there seems little involvement (on the whole) from the standards groups in familiarizing themselves with our methodologies or work so far (please do prove me wrong if this is not the case). Furthermore, I heard that the W3C has a deadline of -- get this -- 2015 for their HTML5 work now that they've acquiesced to the WHATWG's work. By then shouldn't the Semantic Web have been built? :) In all seriousness, I think that there are some good ideas in HTML5 and XHTML2. The predefined classes that seemed arbitrarily decided upon were not among them; better would have been a request for input from the microformats community on which microformats should start making their way into the standards (if any should at all). It's great to see the progress being made in those domains, but I have to wonder whether it will be too foreign and too late by the time the standard is settled. What can be done in the meantime to make our work more relevant and practical while we wait for the next evolution of the web's markup languages? Chris On 5/23/07, Maciej Stachowiak wrote: > > On May 22, 2007, at 11:35 PM, Ciaran McNulty wrote: > > > On 5/23/07, Maciej Stachowiak wrote: > >> I find it questionable to argue that microformats.org defining > >> semantics for particular classes is generally good, but to assume > >> that W3C or WHATWG defining them is ill-conceived. Note that HTML has > >> always predefined some "rel" values, and this has not stopped > >> microformats from defining other rel values, some of which will be > >> folded back in to the HTML spec. > > > > To me the difference is that Microformats have a system for indicating > > whether they are in use (although it's not used widely) in the > > @profile mechanism, > > The fact that content does not use it and data extraction tools > ignore it makes this a meaningless distinction in practice. > > > whereas anything 'hard coded' into the HTML spec will not be optional. > > I would once again draw the analogy to "rel". > > Anyway, I think most of the predefined class names in the HTML 5 spec > were not really jusfied but I'd like to see things like the geo > microformat possibly get folded into HTML over time. > > Regards, > Maciej > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Chris Messina Citizen Provocateur & Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private From bsittler at gmail.com Sat Jun 2 06:20:30 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Sat Jun 2 06:20:33 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> Message-ID: On 6/1/07, David Janes wrote: > On 6/1/07, Ryan King wrote: > > On May 31, 2007, at 11:29 AM, David Janes wrote: > > > > > On 5/31/07, Ryan King wrote: > > > > > >> Another option is that entry content is: > > >> > > >>

Content

> > >>

More Content

> > >> > > >> > > >> Is there a reason why hAtom as currently spec'ed only does text, not > > >> markup? > > > > > > I thought it did markup! I totally see what you are saying here > > > though; the question here is whether we include the DOM nodes that > > > specify entry-content. This isn't in the spec, and you wouldn't want > > > to do it everywhere (entry-title, for example) but it would make sense > > > if it did. > > > > You're right, I'm suggesting that only for entry-content (and maybe > > entry-summary) that we take the nodes that have the class name on > > them. The reason? I've seen this several times: > > > > <... class="hentry"> > > ... > >

...

> > > >

...

> > > > > > > > It makes sense, to me, to put the paragraph nodes, intact, in the > > content. > > I concur. Time to start ramping up for hAtom 0.2, if I can get some > blocks of free time. > > Regards, etc... why not do this for the entry title, too? accroding to the atom spec, this can contain markup too (and in my experience, often does.) and yes, having some well-defined rules for xhtml ? text flattening would be good (not just for microformats, but for xhtml apps generally.) here are the ones i use: 1. ignore content of the following elements: script, style, textarea, title 2. use the alt text as the text for img elements 4. normalize all runs of one or more whitespace to a single space in all elements that do not have an encestral pre, xmp, plaintext, or listing element 3. insert breaks before and after the following elements: br, p, div, hr, h1, h2, h3, h4, h5, blockquote, address, table, tr, td, form, pre, xmp, listing, ol, ul, menu, dir, li, dl, dt and dd still to do: 4. table layout algorithm 5. conversion of content inside sup or sub to corresponding unicode characters where possible, but only when the entire non-whitespace sub or sup content can be converted. this would include e.g. TM ? ? and 2 ? ? -ben From bsittler at gmail.com Sat Jun 2 06:23:59 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Sat Jun 2 06:24:01 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> Message-ID: On 6/2/07, Ben Wiley Sittler wrote: > On 6/1/07, David Janes wrote: > > On 6/1/07, Ryan King wrote: > > > On May 31, 2007, at 11:29 AM, David Janes wrote: > > > > > > > On 5/31/07, Ryan King wrote: > > > > > > > >> Another option is that entry content is: > > > >> > > > >>

Content

> > > >>

More Content

> > > >> > > > >> > > > >> Is there a reason why hAtom as currently spec'ed only does text, not > > > >> markup? > > > > > > > > I thought it did markup! I totally see what you are saying here > > > > though; the question here is whether we include the DOM nodes that > > > > specify entry-content. This isn't in the spec, and you wouldn't want > > > > to do it everywhere (entry-title, for example) but it would make sense > > > > if it did. > > > > > > You're right, I'm suggesting that only for entry-content (and maybe > > > entry-summary) that we take the nodes that have the class name on > > > them. The reason? I've seen this several times: > > > > > > <... class="hentry"> > > > ... > > >

...

> > > > > >

...

> > > > > > > > > > > > It makes sense, to me, to put the paragraph nodes, intact, in the > > > content. > > > > I concur. Time to start ramping up for hAtom 0.2, if I can get some > > blocks of free time. > > > > Regards, etc... > > why not do this for the entry title, too? accroding to the atom spec, > this can contain markup too (and in my experience, often does.) > > and yes, having some well-defined rules for xhtml ? text flattening > would be good (not just for microformats, but for xhtml apps > generally.) here are the ones i use: > > 1. ignore content of the following elements: script, style, textarea, title > > 2. use the alt text as the text for img elements > > 4. normalize all runs of one or more whitespace to a single space in > all elements that do not have an encestral pre, xmp, plaintext, or > listing element > 3. insert breaks before and after the following elements: br, p, div, > hr, h1, h2, h3, h4, h5, blockquote, address, table, tr, td, form, pre, > xmp, listing, ol, ul, menu, dir, li, dl, dt and dd forgot this: 3.1. remove all non-linebreak space adjacent to linebreaks also forgot this: 3.2. consolidate runs of two or more line breaks into a single line break > still to do: > > 4. table layout algorithm > > 5. conversion of content inside sup or sub to corresponding unicode > characters where possible, but only when the entire non-whitespace sub > or sup content can be converted. this would include e.g. TM > ? ? and 2 ? ? > > -ben > From davidjanes at blogmatrix.com Sat Jun 2 09:05:21 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Jun 2 09:05:22 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> Message-ID: <21e523c20706020905u20b96cb1te9520e548255f54e@mail.gmail.com> On 6/2/07, Ben Wiley Sittler wrote: > why not do this for the entry title, too? accroding to the atom spec, > this can contain markup too (and in my experience, often does.) entry-title _does_ include the HTML -- it's just markup on a DOM node; there is nothing in the spec that says it doesn't. Whether one wants to use this or not is up to the parser. I hasten to add that there's reason I can see for including the DOM node where "entry-title" is indicated, since concatenation is not an issue. Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From davidjanes at blogmatrix.com Sat Jun 2 09:11:00 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Jun 2 09:11:03 2007 Subject: [uf-discuss] hAtom 0.2 (was: a question about concatenation...) Message-ID: <21e523c20706020911y1b9254d9r35d5b111ade1f77a@mail.gmail.com> On 6/1/07, Ryan King wrote: > On Jun 1, 2007, at 10:59 AM, David Janes wrote: > > I concur. Time to start ramping up for hAtom 0.2, if I can get some > > blocks of free time. > > I'm more than willing to help. I have time to spend on it right now. > I'll work on collecting issues to deal with. Excellent. Brian indicated some willingness a while ago to help with this too. As a starting point, may I _suggest_ that we restrict hAtom 0.2 to _not_ adding new fields, unless they're already documented microformats. This still gives a fair amount of scope: how does rel-tag, rel-encloure working, better defaulting rules, loosening restrictions / defining defaults for required fields such as updated and author.... I think we have a reasonable amount of practical experience to draw upon now. If we do want to add new fields, they should be appropriated documented in the -examples. Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From ryan at technorati.com Sun Jun 3 00:37:40 2007 From: ryan at technorati.com (Ryan King) Date: Sun Jun 3 00:37:42 2007 Subject: [uf-discuss] hAtom 0.2 (was: a question about concatenation...) In-Reply-To: <21e523c20706020911y1b9254d9r35d5b111ade1f77a@mail.gmail.com> References: <21e523c20706020911y1b9254d9r35d5b111ade1f77a@mail.gmail.com> Message-ID: <05E36832-21E5-4CC0-B257-AC26B555EB7F@technorati.com> On Jun 2, 2007, at 9:11 AM, David Janes wrote: > On 6/1/07, Ryan King wrote: >> On Jun 1, 2007, at 10:59 AM, David Janes wrote: >> > I concur. Time to start ramping up for hAtom 0.2, if I can get some >> > blocks of free time. >> >> I'm more than willing to help. I have time to spend on it right now. >> I'll work on collecting issues to deal with. > > Excellent. Brian indicated some willingness a while ago to help > with this too. > > As a starting point, may I _suggest_ that we restrict hAtom 0.2 to > _not_ adding new fields, unless they're already documented > microformats. This still gives a fair amount of scope: how does > rel-tag, rel-encloure working, better defaulting rules, loosening > restrictions / defining defaults for required fields such as updated > and author.... I think we have a reasonable amount of practical > experience to draw upon now. > > If we do want to add new fields, they should be appropriated > documented in the -examples. I think there may be an area where we need to consider adding new fields? as it currently stands, its actually difficult to author an hAtom instance that can be converted to valid Atom. There are just some things missing from hAtom, but all of these seem to be documented on http://microformats.org/wiki/hatom-issues , mostly thanks to Robert Bachmann. -ryan From hober0 at gmail.com Sun Jun 3 01:42:27 2007 From: hober0 at gmail.com (Edward O'Connor) Date: Sun Jun 3 01:42:50 2007 Subject: [uf-discuss] Re: atom:category scheme References: Message-ID: <86myzhe8ek.fsf@rakim.cfhp.org> Ryan King wrote: > I think we should use rel-tag tagspaces for atom category schemes. Sounds good to me. I wrote a bit about how to represent tags within atom:category here: http://edward.oconnor.cx/2007/02/representing-tags-in-atom Ted -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From msporny at digitalbazaar.com Sun Jun 3 12:42:32 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Jun 3 12:42:36 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI Message-ID: <466319A8.6050409@digitalbazaar.com> Things can still change, but after talking a bit with the Firefox 3 folks - Microformats are starting to look more and more like they're going to be supported in a big way in the next major release of the browser. http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ -- manu From john at johnbeales.com Sun Jun 3 16:27:13 2007 From: john at johnbeales.com (John Beales) Date: Sun Jun 3 16:27:16 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <466319A8.6050409@digitalbazaar.com> References: <466319A8.6050409@digitalbazaar.com> Message-ID: > Things can still change, but after talking a bit with the Firefox 3 > folks - Microformats are starting to look more and more like they're > going to be supported in a big way in the next major release of the browser. > > http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ That looks great, it'll greatly improve the marketability of microformats. One thing though - and if you could tell me the correct place to let the Mozilla folks know about this - they should be careful about changing the cursor for a microformat - sometimes an hCard, for example, will be the whole page, or at least a large portion of it, so no matter where the cursor is it'll be in the microformat state. John From ryan at technorati.com Sun Jun 3 20:24:34 2007 From: ryan at technorati.com (Ryan King) Date: Sun Jun 3 20:24:40 2007 Subject: [uf-discuss] Re: atom:category scheme In-Reply-To: <86myzhe8ek.fsf@rakim.cfhp.org> References: <86myzhe8ek.fsf@rakim.cfhp.org> Message-ID: On Jun 3, 2007, at 1:42 AM, Edward O'Connor wrote: > Ryan King wrote: > >> I think we should use rel-tag tagspaces for atom category schemes. > > Sounds good to me. I wrote a bit about how to represent tags within > atom:category here: > > http://edward.oconnor.cx/2007/02/representing-tags-in-atom Could you put a summary of your ideas and a link at http:// microformats.org/wiki/hatom-issues#atom:category_scheme ? thanks, ryan From jason at sixtwothree.org Sun Jun 3 20:59:33 2007 From: jason at sixtwothree.org (Jason Garber) Date: Sun Jun 3 20:59:35 2007 Subject: [uf-discuss] Adding microformats to RoundCube Webmail Message-ID: <46638E25.9000502@sixtwothree.org> Hello all, I've been trying out RoundCube Webmail [1] for the last few days and was dismayed by its lack of hCards in the Address Book feature. So, like any good geek, I added the functionality myself and blogged it [2]. If anyone gives it a shot and finds solutions to the problems outlined (funkiness with Tails and Operator finding the hCards), let me know. An action item (as they say) out of this whole thing would be to get in touch with the RoundCube Webmail developers and work with them to add this code to the released version of the app. Jason Garber jason@sixtwothree.org [1] http://roundcube.net/ [2] http://sixtwothree.org/blog/archives/2007/06/03/adding-microformats-to-roundcube-webmail/ From microformats at kaply.com Mon Jun 4 07:11:35 2007 From: microformats at kaply.com (Mike Kaply) Date: Mon Jun 4 07:11:39 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: References: <466319A8.6050409@digitalbazaar.com> Message-ID: On 6/3/07, John Beales wrote: > > Things can still change, but after talking a bit with the Firefox 3 > > folks - Microformats are starting to look more and more like they're > > going to be supported in a big way in the next major release of the browser. > > > > http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ > > That looks great, it'll greatly improve the marketability of > microformats. One thing though - and if you could tell me the correct > place to let the Mozilla folks know about this - they should be > careful about changing the cursor for a microformat - sometimes an > hCard, for example, will be the whole page, or at least a large > portion of it, so no matter where the cursor is it'll be in the > microformat state. I'm the one to talk to. And yeah, I think the cursor isn't so good for that reason. I'm still waiting for someone to come up with the "perfect" microformats UI. Mike From taylor_cowan at yahoo.com Mon Jun 4 07:59:41 2007 From: taylor_cowan at yahoo.com (Taylor Cowan) Date: Mon Jun 4 07:59:45 2007 Subject: [uf-discuss] hListing and hReview Message-ID: <537002.42483.qm@web54110.mail.re2.yahoo.com> hReview and the proposed hListing are very similar, sharing structure and properties. They both use "item" and it seems logical that they should work exactly the same in that area...but they are just different enough to cause parsing issues. From the hReview page, it states that "fn" must be a child.... http://microformats.org/wiki/hreview Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g. class="item vcard"). However, when using item info subproperties ("fn", "url", "photo"), they MUST be nested inside the item element. However, on the hListing proposal, item and fn are used in an example like this: Parking space If we can make them agree it sure is easier to write pasers, in this case you merely take an exising hReview parser and add/change a few property names. Since there are already public examples of that on edgeio I wonder if the restriction in hReview should be relaxed regarding ("fn", "url", "photo") as child nodes. It also seems that a second identifier within the same @class attribute is really a child anyway. Parking space == Parking space Taylor ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ From tantek at cs.stanford.edu Mon Jun 4 08:07:11 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Jun 4 08:06:03 2007 Subject: [uf-discuss] hListing and hReview In-Reply-To: <537002.42483.qm@web54110.mail.re2.yahoo.com> Message-ID: On 6/4/07 7:59 AM, "Taylor Cowan" wrote: > hReview and the proposed hListing are very similar, sharing structure and > properties. They both use "item" and it seems logical that they should work > exactly the same in that area...but they are just different enough to cause > parsing issues. From the hReview page, it states that "fn" must be a > child.... > > http://microformats.org/wiki/hreview > Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set > on the item itself (e.g. class="item vcard"). However, when using item info > subproperties ("fn", "url", "photo"), they MUST be nested inside the item > element. Yes, that was one of the clarifications that went into hReview 0.3. > However, on the hListing proposal, item and fn are used in an example like > this: > > Parking space > > If we can make them agree it sure is easier to write pasers, in this case you > merely take an exising hReview parser and add/change a few property names. The hListing proposal "forked" from an earlier version of hReview and that's why it allows that. The hListing proposal needs to be updated with the same rule(s) as hReview. > Since there are already public examples of that on edgeio I wonder if the > restriction in hReview should be relaxed regarding ("fn", "url", "photo") as > child nodes. We should actually go the other direction, update hListing with the help of the Edgeio folks. It is important that microformats iterate and evolve properly, without being burdened by inertia of early implementations. We had a similar discussion a while ago about xFolk. > It also seems that a second identifier within the same @class > attribute is really a child anyway. > > Parking space == Parking > space This assumes that class name order is relevant which is false. The class attribute is a space separated *set* of class names. Thus Parking space == Parking space Thanks, Tantek From brian.suda at gmail.com Mon Jun 4 08:12:10 2007 From: brian.suda at gmail.com (Brian Suda) Date: Mon Jun 4 08:12:18 2007 Subject: [uf-discuss] hListing and hReview In-Reply-To: <537002.42483.qm@web54110.mail.re2.yahoo.com> References: <537002.42483.qm@web54110.mail.re2.yahoo.com> Message-ID: <21e770780706040812w1a21b895pa64b912ac59e6f38@mail.gmail.com> On 6/4/07, Taylor Cowan wrote: > hReview and the proposed hListing are very similar, sharing structure and properties. They both use "item" and it seems logical that they should work exactly the same in that area...but they are just different enough to cause parsing issues. From the hReview page, it states that "fn" must be a child.... > > http://microformats.org/wiki/hreview > Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g. class="item vcard"). However, when using item info subproperties ("fn", "url", "photo"), they MUST be nested inside the item element. > > However, on the hListing proposal, item and fn are used in an example like this: > > Parking space --- this is a problem and it should be implemented in the same way that hReview is, FN is a child of ITEM. > If we can make them agree it sure is easier to write pasers, in this case you merely take an exising hReview parser and add/change a few property names. Since there are already public examples of that on edgeio I wonder if the restriction in hReview should be relaxed regarding ("fn", "url", "photo") as child nodes. It also seems that a second identifier within the same @class attribute is really a child anyway. --- in the class attribute, the order of properties is not important, so you can't say that it will always be the second identifer. The ITEM property acts as a container that then has additional metadata such as FN, TYPE, PHOTO, etc. hListing should be updated to reflect this. -brian -- brian suda http://suda.co.uk From supercanadian at gmail.com Mon Jun 4 12:14:58 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Mon Jun 4 12:15:11 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: References: <466319A8.6050409@digitalbazaar.com> Message-ID: <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> Hello, On 6/4/07, Mike Kaply wrote: > On 6/3/07, John Beales wrote: > > > Things can still change, but after talking a bit with the Firefox 3 > > > folks - Microformats are starting to look more and more like they're > > > going to be supported in a big way in the next major release of the browser. > > > > > > http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ > > > > That looks great, it'll greatly improve the marketability of > > microformats. One thing though - and if you could tell me the correct > > place to let the Mozilla folks know about this - they should be > > careful about changing the cursor for a microformat - sometimes an > > hCard, for example, will be the whole page, or at least a large > > portion of it, so no matter where the cursor is it'll be in the > > microformat state. > > I'm the one to talk to. And yeah, I think the cursor isn't so good for > that reason. I'm still waiting for someone to come up with the > "perfect" microformats UI. I actually rather like the cursor idea. Why not just restrict the cursor thing to be activated over the actual "data" of a Microformat. For example... consider an hCard. It's true that the actual hCard could span the whole page. But you could make the cursor thing happen only when the cursor goes over the text of the name... the logo... and stuff like that. (Did I explain that well enough?) So... you would NOT make the cursor thing happen over the span of the Microformat. But you would make it happen over the actual "text", "image", etc, data of the Microformat. -- Charles Iliya Krempeaux, B.Sc. All the Vlogging News on One Page http://vlograzor.com/ From mejllistor at kodfabrik.se Mon Jun 4 12:40:13 2007 From: mejllistor at kodfabrik.se (Pelle W) Date: Mon Jun 4 12:40:32 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: References: <466319A8.6050409@digitalbazaar.com> Message-ID: <46646A9D.6090505@kodfabrik.se> Mike Kaply skrev: > On 6/3/07, John Beales wrote: >> > Things can still change, but after talking a bit with the Firefox 3 >> > folks - Microformats are starting to look more and more like they're >> > going to be supported in a big way in the next major release of the >> browser. >> > >> > >> http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ >> >> >> That looks great, it'll greatly improve the marketability of >> microformats. One thing though - and if you could tell me the correct >> place to let the Mozilla folks know about this - they should be >> careful about changing the cursor for a microformat - sometimes an >> hCard, for example, will be the whole page, or at least a large >> portion of it, so no matter where the cursor is it'll be in the >> microformat state. > I'm the one to talk to. And yeah, I think the cursor isn't so good for > that reason. I'm still waiting for someone to come up with the > "perfect" microformats UI. I think that since users now know that you find RSS through the Firefox UI and not on the webpage itself often then it should be the same with microformats. What if I hide some of my microformats just because I have replaced it with an image on another part of the screen? That doesn't mean that my microformats shouldn't be parsed - they should be and since they can't be showed on the webpage they have to be showed in the adressbar or similar like with the RSS - thats the expected place for metadata. There will be sort of a built in API for microformats as far as I have understood. Therefor I think that if there should be something added to the webpage it should be added by me after I have detected microformat-support with javascript and can add the proper buttons myself. Well - thats my thoughts - hope it gives something. / Pelle From bhawkeslewis at googlemail.com Mon Jun 4 13:27:02 2007 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Mon Jun 4 13:27:16 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: References: <466319A8.6050409@digitalbazaar.com> Message-ID: <46647596.6090602@googlemail.com> If an on-hover cursor change could indicate microformats for mouse-users, how might keyboard access to microformats work? -- Benjamin Hawkes-Lewis Mike Kaply wrote: > On 6/3/07, John Beales wrote: >> > Things can still change, but after talking a bit with the Firefox 3 >> > folks - Microformats are starting to look more and more like they're >> > going to be supported in a big way in the next major release of the >> browser. >> > >> > >> http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ >> >> >> That looks great, it'll greatly improve the marketability of >> microformats. One thing though - and if you could tell me the correct >> place to let the Mozilla folks know about this - they should be >> careful about changing the cursor for a microformat - sometimes an >> hCard, for example, will be the whole page, or at least a large >> portion of it, so no matter where the cursor is it'll be in the >> microformat state. > > I'm the one to talk to. And yeah, I think the cursor isn't so good for > that reason. I'm still waiting for someone to come up with the > "perfect" microformats UI. > > Mike > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From paul_wilkins at xtra.co.nz Mon Jun 4 13:31:02 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Mon Jun 4 13:31:16 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> Message-ID: <46647686.7080904@xtra.co.nz> Charles Iliya Krempeaux wrote: > Why not just restrict the cursor thing to be activated over the actual > "data" of a Microformat. That sounds like a nice idea, but then you're getting into the realms of mystery-meat navigation. http://www.webpagesthatsuck.com/mysterymeatnavigation.html > For example... consider an hCard. It's true that the actual hCard > could span the whole page. But you could make the cursor thing happen > only when the cursor goes over the text of the name... the logo... and > stuff like that. > > (Did I explain that well enough?) > > So... you would NOT make the cursor thing happen over the span of the > Microformat. But you would make it happen over the actual "text", > "image", etc, data of the Microformat. How about if a microformats icon is activated when such content is available on the page. When you click on the logo, you get a dialog box containing all of the information, while hovering over the icon makes obvious the locations on the page where the microformat information is. Even if the information is made visible on the page in some manner, there are issues with long pages that have most of the microformat information off of the visible part of the page. -- Paul Wilkins From supercanadian at gmail.com Mon Jun 4 13:49:23 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Mon Jun 4 13:49:28 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <46647686.7080904@xtra.co.nz> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> Message-ID: <84ce626f0706041349j7a051d63r276c0ceb7f91bde@mail.gmail.com> Hello Paul, On 6/4/07, Paul Wilkins wrote: > Charles Iliya Krempeaux wrote: > > Why not just restrict the cursor thing to be activated over the actual > > "data" of a Microformat. > > That sounds like a nice idea, but then you're getting into the realms of > mystery-meat navigation. > http://www.webpagesthatsuck.com/mysterymeatnavigation.html The cursor thing could be in addition to other ways (that don't exhibit MMN) of getting at Microformats. But I think having the cursor thing (in addition to other ways of getting at the Microformats) can make for a better user experience. And improve usability. For example... if I see a person's name on the web page (that I vaguely remember), I'd love to be able to right click on their name and bring up all the convo's and IM messages I've had with them in the past (to jog my memory). Sometimes doing something like that (... like right clicking to bring up a context menu...) makes more sense to the user, than instead of going through a bunch of menus on the menu bar, or something like that. The name is there on the webpage... therefore (conceptually) I'd like to do things with that name on the webpage. (Even though it is a MMN technique.) (MMN is only bad is there is no non-MMN way of doing it.) [...] See ya -- Charles Iliya Krempeaux, B.Sc. All the Vlogging News on One Page http://vlograzor.com/ From paul_wilkins at xtra.co.nz Mon Jun 4 14:21:43 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Mon Jun 4 14:21:53 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI References: <466319A8.6050409@digitalbazaar.com><84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com><46647686.7080904@xtra.co.nz> <84ce626f0706041349j7a051d63r276c0ceb7f91bde@mail.gmail.com> Message-ID: <000f01c7a6ee$59816cf0$bc08a8c0@nzto22> From: "Charles Iliya Krempeaux" >> That sounds like a nice idea, but then you're getting into the realms of >> mystery-meat navigation. >> http://www.webpagesthatsuck.com/mysterymeatnavigation.html > > The cursor thing could be in addition to other ways (that don't > exhibit MMN) of getting at Microformats. I'm happy as as long as the discovery of information maintains some form of usability. On a tangent, I was thinking about tabbed browsing and how IE7 made it easy for people to discover what it was. With microformats, how easy it will be for end-users to discover and make use of the information will be a key factor in how well it gets taken up. -- Paul Wilkins From MMontgomery at TerpSys.com Tue Jun 5 05:02:21 2007 From: MMontgomery at TerpSys.com (Montgomery, Mike) Date: Tue Jun 5 05:02:29 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <46647686.7080904@xtra.co.nz> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> Message-ID: I like the idea of an icon that is activated when microformat content is available as mentioned by Paul. It would provide an immediate visual cue that information is available without direct user interaction such as having to hover of content or right-clicking. It would also provide a way to indicate information that may be hidden on the page. I picture it being similar to the RSS feed icon. Maybe it is something that also appears in the address bar. For the record, I actually like the way the Operator add-on works in Firefox. It provides the mircoformat information broken down in different categories (contacts, calendar, maps, etc.) in the tool bar and the Options menu, it provides the ability to Highlight microformats on the page when you mouseover them (similar to the cursor concept). I also like the fact I can turn off this feature. However, I know that an entire tool bar takes up a lot of browser real estate and something more compact would be better. One last thing, are there any thoughts on which microformats would be supported by the Firefox UI? Would it be all of them? Maybe it would only be those that are specs and not drafts? Mike Montgomery -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Paul Wilkins Sent: Monday, June 04, 2007 4:31 PM To: Microformats Discuss Subject: Re: [uf-discuss] Microformats gets strong showing in Firefox 3 UI Charles Iliya Krempeaux wrote: > Why not just restrict the cursor thing to be activated over the actual > "data" of a Microformat. That sounds like a nice idea, but then you're getting into the realms of mystery-meat navigation. http://www.webpagesthatsuck.com/mysterymeatnavigation.html > For example... consider an hCard. It's true that the actual hCard > could span the whole page. But you could make the cursor thing happen > only when the cursor goes over the text of the name... the logo... and > stuff like that. > > (Did I explain that well enough?) > > So... you would NOT make the cursor thing happen over the span of the > Microformat. But you would make it happen over the actual "text", > "image", etc, data of the Microformat. How about if a microformats icon is activated when such content is available on the page. When you click on the logo, you get a dialog box containing all of the information, while hovering over the icon makes obvious the locations on the page where the microformat information is. Even if the information is made visible on the page in some manner, there are issues with long pages that have most of the microformat information off of the visible part of the page. -- Paul Wilkins _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From microformats at kaply.com Tue Jun 5 07:27:36 2007 From: microformats at kaply.com (Mike Kaply) Date: Tue Jun 5 07:27:40 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> Message-ID: On 6/5/07, Montgomery, Mike wrote: > I like the idea of an icon that is activated when microformat content is > available as mentioned by Paul. It would provide an immediate visual > cue that information is available without direct user interaction such > as having to hover of content or right-clicking. It would also provide > a way to indicate information that may be hidden on the page. I picture > it being similar to the RSS feed icon. Maybe it is something that also > appears in the address bar. I'm considering experimenting with putting a microformats icon on the URL bar similar to the RSS icon, but that would be Operator only. The Firefox folks specifically don't want to clutter up that bar. The basic problem with Firefox is that they don't want to clutter the UI with something that might not be used a lot (this is a statement about all microformats in the UI) > For the record, I actually like the way the Operator add-on works in > Firefox. It provides the mircoformat information broken down in > different categories (contacts, calendar, maps, etc.) in the tool bar > and the Options menu, it provides the ability to Highlight microformats > on the page when you mouseover them (similar to the cursor concept). I > also like the fact I can turn off this feature. However, I know that an > entire tool bar takes up a lot of browser real estate and something more > compact would be better. That was really my goal to provide as many UI paradigms as possible in Operator so that people could decide which they liked the best. If people don't like the toolbar, they can use the Operator toolbar button or the Operator status bar icon. One of the ideas I have which isn't done yet is to provide certain microformats as standalone toolbar buttons (like a Contacts toolbar button). > One last thing, are there any thoughts on which microformats would be > supported by the Firefox UI? Would it be all of them? Maybe it would > only be those that are specs and not drafts? Yes. At this point it will probably be hCard, hCalendar, Address and maybe geo. There will be no rel based microformats. The reason for no rel based microformats is because if you think about it, they are difficult to detect efficiently. For instance, detecting XFN requires seeing if the rel attribute contains one or more of 18 different things. Not very efficient. Detecting classes is much more straightforward. The reason I'm doing Address is the same reason I put it in Operator - it doesn't make sense to do things like "search google maps" on an hCard, since the hCard is not the address, and the hCard can contain more than one address. Mike Kaply From mejllistor at kodfabrik.se Tue Jun 5 13:24:53 2007 From: mejllistor at kodfabrik.se (Pelle W) Date: Tue Jun 5 13:25:15 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> Message-ID: <4665C695.6070205@kodfabrik.se> On 6/5/07, Montgomery, Mike wrote: > I like the idea of an icon that is activated when microformat content is > available as mentioned by Paul. It would provide an immediate visual > cue that information is available without direct user interaction such > as having to hover of content or right-clicking. It would also provide > a way to indicate information that may be hidden on the page. I picture > it being similar to the RSS feed icon. Maybe it is something that also > appears in the address bar. I also agree with Mike, Paul and others here. I read that someone raised the question about keyboard navigation and the only real solution to that problem I think would be to lift microformats out of the actual webpage and into the the browser UI. Mike Kaply wrote: > I'm considering experimenting with putting a microformats icon on the > URL bar similar to the RSS icon, but that would be Operator only. The > Firefox folks specifically don't want to clutter up that bar. That would be the absolutely best solution - I hope that the Operator will show the Firefox crew that Microformats isn't clitter. Mike Kaply wrote: > The basic problem with Firefox is that they don't want to clutter the UI > with something that might not be used a lot (this is a statement about > all microformats in the UI) What they referrer to here is whether the users will actually use the microformats and not if the developers will support it - right? Because if the developers don't support it it won't clutter the UI - only if the users don't use it it becomes clutter. I personally think that microformats support would be more popular than RSS-support. The latter has only been adopted by some people and have a bit of a learning curve - a microformat almost doesn't have a learning curve because it is information in a way we've all already worked with. I personally would say that what would clutter Firefox is when it intrudes into my webpage. What wouldn't clutter Firefox is a friendly notification of the presence of some hidden data. / Pelle From scott at randomchaos.com Tue Jun 5 16:46:18 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue Jun 5 16:46:26 2007 Subject: [uf-discuss] NetNewsWire 3 supports microformats Message-ID: News: http://www.newsgator.com/Individuals/NetNewsWire/ From the help: > When a news item or web page includes a contact or calendar event > as a microformat, NetNewsWire displays popup menus near the bottom > of the window. One popup shows all the calendar events on the page; > the other shows the contacts. > > You can choose an item from a popup menu to add it iCal or Address > Book. So far it doesn't seem to work on news items, only web pages, but still nice. Screenshot: http://www.newsgator.com/img/ss/nnw_microformats.png Looks like it's using the icons Wolfgang Bartelme created. http://www.factorycity.net/projects/microformats-icons/ Peace, Scott From faaborg at mozilla.com Tue Jun 5 21:09:27 2007 From: faaborg at mozilla.com (Alex Faaborg) Date: Tue Jun 5 21:09:27 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <4665C695.6070205@kodfabrik.se> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> Message-ID: <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> Hey, I'm working with Mike Kaply on microformat support in Firefox 3, and I would love to get feedback from this group on the user interface design. To answer a few questions that have been raised in this thread: > if you could tell me the correct > place to let the Mozilla folks know about this - they should be > careful about changing the cursor for a microformat - sometimes an > hCard, for example, will be the whole page Yeah, Mike Kaply and I have been thinking about edge cases like this. One possible solution would be to create some heuristics for determining if a microformatted content area is too large to change the cursor, and also provide a way for Web sites to directly control if the cursor changes or doesn't change. > I'm still waiting for someone to come up with the > "perfect" microformats UI. Changing the cursor isn't perfect, but it is the only way for the browser to provide a visual cue of contextual action without directly modifying the page itself, which is why this is the best solution I have heard so far. I think there are a few things we could do to improve the interface further include outlining the microformatted content on hover (Operator 0.7 and later tried this), and possibly flashing the microformatted content areas on page load. I also like the user interface for viewing tagged sections of images on Flickr: http:// flickr.com/photos/titanium-white/379894665/ > If an on-hover cursor change could indicate microformats for mouse- > users, how might keyboard access to microformats work? We will need to provide a keyboard interface in secondary UI for accessibility. Overall, microformats are great for accessibility due to the number of steps they eliminate for tasks like adding something to your calendar. > The cursor thing could be in addition to other ways (that don't > exhibit MMN) of getting at Microformats. The cursor change isn't technically mystery meat navigation, since you can hopefully see what you are hovering over, and the icon of the application that is going to launch is appended to the cursor. However, I have heard this UI compared to a mid 1990s adventure game :) We will likely have some type of interface to view all of the microformatted content on the page, but we haven't decided on what. A rather comprehensive list of various options is here: http://wiki.mozilla.org/Microformats/UE/ideas > I hope that the Operator will show the Firefox crew that > Microformats isn't clitter. The creator of Operator, Mike Kaply is also writing the microformat implementation for Firefox 3, so technically "Operator" and "the Firefox crew" are the same person. In terms of clutter, the right side of the location bar is quickly turning into the equivalent of the Windows system tray: the random place where you stick your extra stuff (locks and RSS icons and microformat icons, etc). As we start to rethink the overall browser UI, we will hopefully find a better place to put these types of notifications. > only if the users don't use it it becomes clutter If the user is viewing a page with microformats and RSS through a secure connection, they will have a yellow location bar containing a favicon, lock icon, feed icon, and microformat icon. We are worried that this is too much visual clutter. Options include things like merging the feed icon and microformat icon, taking security UI out of the location bar, moving some of these things to secondary UI, etc. > what would clutter Firefox is when it intrudes into my webpage In a lot of cases it is easier to directly interact with information in the page than it is to find it in a menu somewhere. For instance, if you want to map a single item in a list of 100 items, you don't want to do a visual scan for the same item in a menu, you just want to click on it. We are of course going to allow Web sites to provide their own UI for interacting with microformats as well, but I personally think we should provide a good default interface. Discussion of microformat support in Firefox 3 in the Mozilla community is going on here: http://groups.google.com/group/ mozilla.dev.apps.firefox/browse_frm/thread/19660ddf0589e15e/ d600f125dcc8b845#d600f125dcc8b845 -Alex On Jun 5, 2007, at 1:24 PM, Pelle W wrote: > On 6/5/07, Montgomery, Mike wrote: >> I like the idea of an icon that is activated when microformat >> content is >> available as mentioned by Paul. It would provide an immediate visual >> cue that information is available without direct user interaction >> such >> as having to hover of content or right-clicking. It would also >> provide >> a way to indicate information that may be hidden on the page. I >> picture >> it being similar to the RSS feed icon. Maybe it is something that >> also >> appears in the address bar. > I also agree with Mike, Paul and others here. I read that someone > raised the question about keyboard navigation and the only real > solution to that problem I think would be to lift microformats out > of the actual webpage and into the the browser UI. > > Mike Kaply wrote: >> I'm considering experimenting with putting a microformats icon on the >> URL bar similar to the RSS icon, but that would be Operator only. The >> Firefox folks specifically don't want to clutter up that bar. > That would be the absolutely best solution - I hope that the > Operator will show the Firefox crew that Microformats isn't clitter. > > Mike Kaply wrote: >> The basic problem with Firefox is that they don't want to clutter >> the UI >> with something that might not be used a lot (this is a statement >> about >> all microformats in the UI) > What they referrer to here is whether the users will actually use > the microformats and not if the developers will support it - right? > Because if the developers don't support it it won't clutter the UI > - only if the users don't use it it becomes clutter. > I personally think that microformats support would be more popular > than RSS-support. The latter has only been adopted by some people > and have a bit of a learning curve - a microformat almost doesn't > have a learning curve because it is information in a way we've all > already worked with. > > > I personally would say that what would clutter Firefox is when it > intrudes into my webpage. What wouldn't clutter Firefox is a > friendly notification of the presence of some hidden data. > > / Pelle > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From paul_wilkins at xtra.co.nz Tue Jun 5 22:57:00 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Tue Jun 5 22:57:04 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> Message-ID: <000401c7a7ff$803a4530$bc08a8c0@nzto22> From: "Alex Faaborg" > Changing the cursor isn't perfect, but it is the only way for the browser > to provide a visual cue of contextual action without directly modifying > the page itself, which is why this is the best solution I have heard so > far. Will this be able to combine with other existing extensions that change the mouse cursor? If it will interoperate, it shouldn't be the primary means by which the imformation is made known. >> The cursor thing could be in addition to other ways (that don't >> exhibit MMN) of getting at Microformats. > > The cursor change isn't technically mystery meat navigation, since you > can hopefully see what you are hovering over, and the icon of the > application that is going to launch is appended to the cursor. Strictly speaking it isn't MMN because navigation itself isn't involved. The problems surrounding the cursor change though are identical. If it is the only mechanism to find microformat content, it won't be found until someone chances across it if they notice it changing when it crosses such content. The mouse cursor operation won't be able to survive all by itself. It will need other techniques to back it up. I suggest some below. > In a lot of cases it is easier to directly interact with information in > the page than it is to find it in a menu somewhere. For instance, if you > want to map a single item in a list of 100 items, you don't want to do a > visual scan for the same item in a menu, you just want to click on it. My suggestion is: - A microformats icon appears when such information is available, and a dialog box should appear to introduce the microformat logo, with a tick box to not show it again - The microformat content is made visible (dotted border, or some other mechanism) temporarily when whe microformat logo is hovered over, or permanently (until page refresh) when clicked. - The microformat logo should have a couple of drop-down options such as "Outline Microformat Content" and another option for a modal dialog box containing the microformat content information. - The mouse can indicate the microformat type when it hovers over the content, but it should not activate the outlining of the content. That would get too messy and distracting. - The context-menu (right-click) should provide the ability to interact with the microformat content This allows several types of behaviour to take place: - you can guess at what is microformat content should you desire to - you can hover briefly on the logo to get an idea of where the microformat content is, then use the mouse to interact with the content - you can turn on the microformat outline for the page then scroll to find relevant pieces - people who don't know they can click the microformat logo can still activate it from the drop-down menu -- Paul Wilkins From timber at lava.net Tue Jun 5 23:13:45 2007 From: timber at lava.net (Colin Barrett) Date: Tue Jun 5 23:13:49 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <000401c7a7ff$803a4530$bc08a8c0@nzto22> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> <000401c7a7ff$803a4530$bc08a8c0@nzto22> Message-ID: <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> On Jun 5, 2007, at 10:57 PM, Paul Wilkins wrote: > Strictly speaking it isn't MMN because navigation itself isn't > involved. The problems surrounding the cursor change though are > identical. If it is the only mechanism to find microformat content, > it won't be found until someone chances across it if they notice it > changing when it crosses such content. I was thinking about this, and I wonder -- how did people learn the behavior that you can click on a blue, underlined piece of text? Think about a pre-web world where nobody knew what hypertext was. People needed to figure out somehow that you could click on links to make them activate. Enter, the hand cursor. If you think about it, it tells you nothing about what's actually going to happen when you click -- instead, it looks like someone about to click the mouse, so I suppose it's inviting for people to mimic the gesture? This still doesn't answer the question of how people would discover this. My guess is that people scan the page with their mouse as they read. I know I do that sometimes. Anyone have actual evidence? Perhaps we don't need to worry about discoverability of microformats further than just changing the cursor, after all. -Colin From paul_wilkins at xtra.co.nz Tue Jun 5 23:46:28 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Tue Jun 5 23:46:46 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> <000401c7a7ff$803a4530$bc08a8c0@nzto22> <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> Message-ID: <46665844.6080806@xtra.co.nz> Colin Barrett wrote: > I was thinking about this, and I wonder -- how did people learn the > behavior that you can click on a blue, underlined piece of text? > Think about a pre-web world where nobody knew what hypertext was. > People needed to figure out somehow that you could click on links to > make them activate. > > Enter, the hand cursor. If you think about it, it tells you nothing > about what's actually going to happen when you click -- instead, it > looks like someone about to click the mouse, so I suppose it's > inviting for people to mimic the gesture? This still doesn't answer > the question of how people would discover this. My guess is that > people scan the page with their mouse as they read. I know I do that > sometimes. Anyone have actual evidence? There's no need to guess. There were many issues and problems with hyperlinks when they were first used, and information about this is fully available in great detail. The following extract is by Jakob Nielsen from 1988 Architectural Component of Hypertext Systems http://www.useit.com/papers/hypertext_theory/ > Perhaps we don't need to worry about discoverability of microformats > further than just changing the cursor, after all. Your proposal for microformats provides no mechanism for people to visually distinguish what is microformat content and what is not. Imaging that you have ten different pages, all from different websites. Three of them have microformat information in them and the rest do not. Are people going to right-click on every piece of content that's of interest to them on all of those ten pages and examine the context-menu to see if that piece of content lets them use some microformat content? No they are not. After a very short while they'll tire of that game. If there is instead a visual cue of there being microformat content on the page (an icon appears, or your hovered mouse shows you something), then it becomes much easier to take action on potential information of interest. Idea for developers - for accessibility, there should be a keyboard shortcut that enables the outlining of microformat content. Then someone can quickly (without the mouse) check to see if there's something of interest to them, before moving on. -- Paul Wilkins From timber at lava.net Tue Jun 5 23:54:38 2007 From: timber at lava.net (Colin Barrett) Date: Tue Jun 5 23:54:44 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <46665844.6080806@xtra.co.nz> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> <000401c7a7ff$803a4530$bc08a8c0@nzto22> <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> <46665844.6080806@xtra.co.nz> Message-ID: <1F0876AE-CDE1-4195-BCAA-6D868297DE83@lava.net> On Jun 5, 2007, at 11:46 PM, Paul Wilkins wrote: > There's no need to guess. > There were many issues and problems with hyperlinks when they were > first used, and information about this is fully available in great > detail. > > The following extract is by Jakob Nielsen from 1988 > > Architectural Component of Hypertext Systems > http://www.useit.com/papers/hypertext_theory/ LazyWeb, Go! :) Thanks for the link. > If there is instead a visual cue of there being microformat content > on the page (an icon appears, or your hovered mouse shows you > something), then it becomes much easier to take action on potential > information of interest. Isn't that what I was advocating? A hover effect for the mouse, like Alex proposed (full disclosure, Alex is a co-worker of mine at Mozilla). -Colin From paul_wilkins at xtra.co.nz Wed Jun 6 00:11:18 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Wed Jun 6 00:11:33 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <1F0876AE-CDE1-4195-BCAA-6D868297DE83@lava.net> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> <000401c7a7ff$803a4530$bc08a8c0@nzto22> <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> <46665844.6080806@xtra.co.nz> <1F0876AE-CDE1-4195-BCAA-6D868297DE83@lava.net> Message-ID: <46665E16.4000303@xtra.co.nz> Colin Barrett wrote: > On Jun 5, 2007, at 11:46 PM, Paul Wilkins wrote: > >> There's no need to guess. >> There were many issues and problems with hyperlinks when they were >> first used, and information about this is fully available in great >> detail. >> >> The following extract is by Jakob Nielsen from 1988 > Curses - 1995 is wehen it was published, but it's all good. >> >> Architectural Component of Hypertext Systems >> http://www.useit.com/papers/hypertext_theory/ > > > LazyWeb, Go! :) Thanks for the link. > > >> If there is instead a visual cue of there being microformat content >> on the page (an icon appears, or your hovered mouse shows you >> something), then it becomes much easier to take action on potential >> information of interest. > > > Isn't that what I was advocating? A hover effect for the mouse, like > Alex proposed (full disclosure, Alex is a co-worker of mine at Mozilla). We may have different parts of the elephant here. My opinion is that the "hunt around and discover a mystery logo on some content" technique should be secondary and supplemental to aanother indicator that the microformat content is there, whether it be a visual icon, or an audible fanfare (just kidding), or *something* that alerts the user by saying "Hey, wake up!" to its presence. -- Paul Wilkins From sayrer at gmail.com Wed Jun 6 01:12:28 2007 From: sayrer at gmail.com (Robert Sayre) Date: Wed Jun 6 01:12:32 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <46665E16.4000303@xtra.co.nz> References: <466319A8.6050409@digitalbazaar.com> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> <000401c7a7ff$803a4530$bc08a8c0@nzto22> <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> <46665844.6080806@xtra.co.nz> <1F0876AE-CDE1-4195-BCAA-6D868297DE83@lava.net> <46665E16.4000303@xtra.co.nz> Message-ID: <68fba5c50706060112g1ce66ee1q1503773de7a21d4c@mail.gmail.com> On 6/6/07, Paul Wilkins wrote: > > My opinion is that the "hunt around and discover a mystery logo on some > content" technique should be secondary and supplemental to aanother > indicator that the microformat content is there, whether it be a visual > icon, or an audible fanfare (just kidding), or *something* that alerts > the user by saying "Hey, wake up!" to its presence. In order to implement this indicator that alerts the user to wake up, we'll need a method to prevent this markup from becoming a spam vector, or a popup-like UI annoyance. I'm interested to find out what the answers are. (disclosure: I work at Mozilla too, but I have never spoken to Alex or Colin about this issue) -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From joe at andrieu.net Wed Jun 6 01:13:11 2007 From: joe at andrieu.net (Joe Andrieu) Date: Wed Jun 6 01:13:06 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> Message-ID: <00b401c7a812$86b9f500$0201a8c0@andrieuhome> Colin Barrett wrote: > On Jun 5, 2007, at 10:57 PM, Paul Wilkins wrote: > > > Strictly speaking it isn't MMN because navigation itself isn't > > involved. The problems surrounding the cursor change though are > > identical. If it is the only mechanism to find microformat > content, > > it won't be found until someone chances across it if they > notice it > > changing when it crosses such content. > > I was thinking about this, and I wonder -- how did people learn the > behavior that you can click on a blue, underlined piece of > text? Think > about a pre-web world where nobody knew what hypertext was. People > needed to figure out somehow that you could click on links to make > them activate. > > Enter, the hand cursor. If you think about it, it tells you nothing > about what's actually going to happen when you click -- instead, it > looks like someone about to click the mouse, so I suppose it's > inviting for people to mimic the gesture? This still doesn't answer > the question of how people would discover this. My guess is that > people scan the page with their mouse as they read. I know I do that > sometimes. Anyone have actual evidence? > > Perhaps we don't need to worry about discoverability of microformats > further than just changing the cursor, after all. Blue hyperlinks are an idiom, which, once learned, was easy to understand. However, they are far more than just the hover effect on the cursor. They are /also/ blue and underlined. Let's not under value the importance of that. The visual presentation is an "affordance" that tells users that clicking on it navigates. Without the blue underline, you are back to the mystery meat navigation. Even today, if the text isn't blue underlined, it better have some other affordance for me to understand it's a link. IMO, cursor effects should /support/ affordance, rather than being the primary indicator. The visual presentation should show that something special happens and then the cursor effect confirms it. My gut instinct for Firefox is that we probably need three steps (1) an RSS-like microformats indicator (2) a way to "activate" uF and (3) a way for users to then interact with said uF. We might need offer multiple options for (2) and (3), we should certainly consider several. I like highlighting on a page, but that can be annoying and certainly hard to control from the HTML designers perspective. But it could be a glyph appearing near the "corner" of a uF rather than a full "highlight" effect around the uF container. Clicking on the glyph or the highlighted section then lets the user interact with the uF in some way. Unfortunately, this messes with the design and potentially puts the user in weird-mode where clicks do "abnormal" things compared to the non-uF highlighted mode (normal web interaction). I think I prefer the idea of populating a list in a pop-up or sidebar window with all of the uF available on the page. This avoids the problem of design-clash and provides an obvious place for a variety of interaction capabilities, like a right-clight to select an application to send the uF to. -j -- Joe Andrieu SwitchBook Software http://www.switchbook.com joe@switchbook.com +1 (805) 705-8651 From mdagn at spraci.com Wed Jun 6 02:52:07 2007 From: mdagn at spraci.com (Michael MD) Date: Wed Jun 6 02:52:08 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> <000401c7a7ff$803a4530$bc08a8c0@nzto22><816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> <46665844.6080806@xtra.co.nz> Message-ID: <006901c7a820$58837ae0$116bacca@COMCEN> I do very much like the idea of some native support for microformats in browsers. I also think it draws attention to the need to keep parsing rules as simple as possible so as not to significantly slow down the loading of pages! From josowski at neatreceipts.com Wed Jun 6 05:20:35 2007 From: josowski at neatreceipts.com (Joe Osowski) Date: Wed Jun 6 05:21:15 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <00b401c7a812$86b9f500$0201a8c0@andrieuhome> References: <816D86BA-5C62-4C42-ACF9-CD03753B8216@lava.net> <00b401c7a812$86b9f500$0201a8c0@andrieuhome> Message-ID: <45E36921B695A14FA56A34F29424A1EC5F515F@Apollo.neatreceipts.local> "I think I prefer the idea of populating a list in a pop-up or sidebar window with all of the uF available on the page. This avoids the problem of design-clash and provides an obvious place for a variety of interaction capabilities, like a right-clight to select an application to send the uF to." -Joe Andrieu I believe this would be the best approach. Perhaps an icon in the status bar as a visual cue that at least one uF is on the current page. Clicking on it would open up a popup or sidebar listing them. From mail at tobyinkster.co.uk Wed Jun 6 05:31:28 2007 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Jun 6 06:20:45 2007 Subject: [uf-discuss] Re: Microformats gets strong showing in Firefox 3 UI References: <466319A8.6050409@digitalbazaar.com> Message-ID: <02mij4-h76.ln1@ophelia.g5n.co.uk> Mike Kaply wrote: > I'm the one to talk to. And yeah, I think the cursor isn't so good for > that reason. I'm still waiting for someone to come up with the > "perfect" microformats UI. My vote would be (at slight risk of littering) an address bar icon with a drop-down menu to access each microformat item on a page. Accompany this with a microformats sidebar, listing all contacts, events, tags, etc on a page. A single click on an item in the sidebar, scrolls the page to that location, as if HTML element had been linked to using a URL fragment. (The page author could style the element using CSS3's :target pseudo-class.) A double click on the item in the sidebar launches the default action for that item -- e.g. adds a contact to your address bar, finds a location on Google Maps, etc. A right click on the item would offer other actions to be performed. The sidebar could have options to sort the list alphabetically, in page order, or by category (Contacts, Places, Events, Tags, etc). Specific microformats also have certain other locations where they could be used -- rel-tag might be automatically used when bookmarking a page to record keywords for the page, making searching simpler; rel-license could perhaps be used in some sensible way when a page is saved. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.12-12mdksmp, up 102 days, 19:52.] URLs in demiblog http://tobyinkster.co.uk/blog/2007/05/31/demiblog-urls/ From Michael.Smethurst at bbc.co.uk Wed Jun 6 06:31:43 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Jun 6 06:32:26 2007 Subject: [uf-discuss] Problems parsing ufs Message-ID: Two problems I'm having at the moment (very related): - If I use a hReview uf where the review doesn't have a url of its own but does include a hCard which does have a url both tails and operator seem to suggest that the url for the review is that for the hCard - If I use an event uf and the event doesn't have a url of it's own but the contact does, again both tails and operator seem to suggest that the url of the event is that of the person Seems that the url of the event or the review is taken to be the first descendent a element with a class of url rather than the first descendent a element with a class of url which is not a descendent of an hCard which is a descendent of the review/event Does this make sense? What am I doing wrong? http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From microformats at kaply.com Wed Jun 6 08:05:44 2007 From: microformats at kaply.com (Mike Kaply) Date: Wed Jun 6 08:05:48 2007 Subject: [uf-discuss] Re: Microformats gets strong showing in Firefox 3 UI In-Reply-To: <02mij4-h76.ln1@ophelia.g5n.co.uk> References: <466319A8.6050409@digitalbazaar.com> <02mij4-h76.ln1@ophelia.g5n.co.uk> Message-ID: On 6/6/07, Toby A Inkster wrote: > Mike Kaply wrote: > > > I'm the one to talk to. And yeah, I think the cursor isn't so good for > > that reason. I'm still waiting for someone to come up with the > > "perfect" microformats UI. > > My vote would be (at slight risk of littering) an address bar icon with a > drop-down menu to access each microformat item on a page. I just got the address bar icon in Operator just for fun, and I have to say that based on everything I've done, I personally like it the best. You'll be able to experiment with it in Operator 0.8b. My primary goal with Firefox 3 is to get a core microformats backend available so that UI experimentation with microformats will be much easier. It's obvious from the discussions here that everyone has great ideas, and it would be nice to see the microformats internals done by the browser so that people can focus on interesting ways to use the information. Mike From microformats at kaply.com Wed Jun 6 08:07:07 2007 From: microformats at kaply.com (Mike Kaply) Date: Wed Jun 6 08:07:10 2007 Subject: [uf-discuss] Problems parsing ufs In-Reply-To: References: Message-ID: Interesting. That's tricky. Basically what I do in Operator is look for any DOM node with the class URL that is a child of the review. Obviously I'm getting the one in the hcard/hcalendar. I'll have to think about that. Mike On 6/6/07, Michael Smethurst wrote: > Two problems I'm having at the moment (very related): > > - If I use a hReview uf where the review doesn't have a url of its own but > does include a hCard which does have a url both tails and operator seem to > suggest that the url for the review is that for the hCard > > - If I use an event uf and the event doesn't have a url of it's own but the > contact does, again both tails and operator seem to suggest that the url of > the event is that of the person > > Seems that the url of the event or the review is taken to be the first > descendent a element with a class of url rather than the first descendent a > element with a class of url which is not a descendent of an hCard which is a > descendent of the review/event > > > Does this make sense? What am I doing wrong? > > > http://www.bbc.co.uk/ > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From Michael.Smethurst at bbc.co.uk Wed Jun 6 08:50:43 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Jun 6 08:50:51 2007 Subject: [uf-discuss] Problems parsing ufs In-Reply-To: Message-ID: Cool So in the meantime I don't know whether to include the link on the hCard (and make the review more confused) or leave it off the hCard (and make that less complete) Think I'm tending toward the latter cos the point of the page is the review... Any thoughts? On 6/6/07 16:07, "Mike Kaply" wrote: > Interesting. That's tricky. Basically what I do in Operator is look > for any DOM node with the class URL that is a child of the review. > Obviously I'm getting the one in the hcard/hcalendar. I'll have to > think about that. > > Mike > > On 6/6/07, Michael Smethurst wrote: >> Two problems I'm having at the moment (very related): >> >> - If I use a hReview uf where the review doesn't have a url of its own but >> does include a hCard which does have a url both tails and operator seem to >> suggest that the url for the review is that for the hCard >> >> - If I use an event uf and the event doesn't have a url of it's own but the >> contact does, again both tails and operator seem to suggest that the url of >> the event is that of the person >> >> Seems that the url of the event or the review is taken to be the first >> descendent a element with a class of url rather than the first descendent a >> element with a class of url which is not a descendent of an hCard which is a >> descendent of the review/event >> >> >> Does this make sense? What am I doing wrong? >> >> >> http://www.bbc.co.uk/ >> This e-mail (and any attachments) is confidential and may contain personal >> views which are not the views of the BBC unless specifically stated. >> If you have received it in error, please delete it from your system. >> Do not use, copy or disclose the information in any way nor act in reliance >> on it and notify the sender immediately. >> Please note that the BBC monitors e-mails sent or received. >> Further communication will signify your consent to this. >> >> _______________________________________________ >> 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 http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From brian.suda at gmail.com Wed Jun 6 09:01:11 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Jun 6 09:01:13 2007 Subject: [uf-discuss] Problems parsing ufs In-Reply-To: References: Message-ID: <21e770780706060901w7be687a5y5d5a50f11e2847dc@mail.gmail.com> On 6/6/07, Michael Smethurst wrote: > Think I'm tending toward the latter cos the point of the page is the > review... > Any thoughts? could you provide us with a link so we can help sort out this issue? -- brian suda http://suda.co.uk From Michael.Smethurst at bbc.co.uk Wed Jun 6 09:39:50 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Jun 6 09:39:57 2007 Subject: [uf-discuss] Problems parsing ufs In-Reply-To: <21e770780706060901w7be687a5y5d5a50f11e2847dc@mail.gmail.com> Message-ID: Sorry no - still in staging Clipped markup here:

ALBUMS

The Fall, Fall Heads Roll

Picture of: Fall Heads Roll
Artist:
The Fall
Label:
Slogan/Sanctuary
Cat#:
SLOCD003
Released:
2005-10-03

TRACKLIST

  • Ride Away
  • Pacifying Joint
  • What About Us?
  • Midnight in Aspen
  • Assume
  • Aspen Reprise
  • Blindness
  • I Can Hear the Grass Grow
  • Bo Demmick
  • Youwanner
  • Clasp Hands
  • Early Days of Channel F?1?4hrer
  • Breaking the Rules
  • Trust in Me

Tracklists on /music are powered by MusicBrainz. If you spot any errors in / omissions from this list you can edit Fall Heads Roll at MusicBrainz.

REVIEW

Hearing Mark E. Smith shout over a rumbling beat is one of life's singular pleasures. He drawls like Johnny Cash after too many pints.

A newteam of young whippersnappers have been chosen to form the latest incarnation of The Fall. Honed into a brutal, head banging rock beastthey do a great Bo Diddley and thrash their way through an acid scrambled version of The Move's "I Can Hear The Grass Grow".

Smith filters dark thoughts through the broken prism of his brain. He chides those who spread "lies and discontent" on the lopsided "Ride Away" before singing "Hey, Hey". It's funny, but I'm not sure why. "What About Us" tells the story ofan East German rabbit who moves to the North of England and gets annoyed about Harold Shipman.

By his own high standards Smith's performances here are erratic. Sometimes he's as sharp as a needle, sometimes he's incomprehensible.

But "Ya Wanner" and "Clasp Hands" are classic Fall: driving riffs with Smith's lyrical gems smeared on top. When they're this good, there's no one within shouting distance.

Andrew McGregor (2007-06-06)

This review is licensed under a Creative Commons Attribution 3.0 Licence. If you choose to use this review on your site please link back to this page.

Send us your comments or read other people's.

On 6/6/07 17:01, "Brian Suda" wrote: > On 6/6/07, Michael Smethurst wrote: >> Think I'm tending toward the latter cos the point of the page is the >> review... >> Any thoughts? > > could you provide us with a link so we can help sort out this issue? http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From bruce at brucelawson.co.uk Wed Jun 6 12:00:25 2007 From: bruce at brucelawson.co.uk (bruce lawson) Date: Wed Jun 6 11:59:50 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI Message-ID: <200706061859.l56IxmUh011548@microformats.org> Good to hear that Microformats are going to get good high-profile support in FF3. Can those at Mozilla reassure those of us who those of us who care about accessibility that any microformat that uses the design pattern for geo/ datetime data will also be equally detected if the author chooses to use Austin, TX rather than the inaccessible Austin, TX? (See http://www.webstandards.org/2007/04/27/haccessibility/) Bruce Lawson Web Standards Project: Accessibility Task Force From ryan at technorati.com Wed Jun 6 12:00:06 2007 From: ryan at technorati.com (Ryan King) Date: Wed Jun 6 12:00:24 2007 Subject: [uf-discuss] a question about concatenation and hAtom entry content In-Reply-To: <62225F6C-F1ED-4AE9-ADB6-F32A36BC8F56@technorati.com> References: <61D93B7E-0D59-48DD-B28E-D1EFF9B86583@technorati.com> <21e523c20705311129w475e61d9i1da9acd6bf2cc2a2@mail.gmail.com> <92F99D94-85BF-4A6E-9479-E69716465A5C@technorati.com> <21e523c20706011059x2a5fbafepc208d569a1cb648f@mail.gmail.com> <62225F6C-F1ED-4AE9-ADB6-F32A36BC8F56@technorati.com> Message-ID: On Jun 1, 2007, at 11:41 AM, Ryan King wrote: > On Jun 1, 2007, at 10:59 AM, David Janes wrote: >> I concur. Time to start ramping up for hAtom 0.2, if I can get some >> blocks of free time. > > I'm more than willing to help. I have time to spend on it right > now. I'll work on collecting issues to deal with. Ok, FWIW, here's the already open issues I think we need to deal with for hAtom 0.2. Even if this is all we do, I think it'd be a great improvement: 1. http://microformats.org/wiki/hatom-issues#Feed_id_.28atom:id.29 2. http://microformats.org/wiki/hatom-issues#Feed_permalink_. 28atom:permalink.29 3. http://microformats.org/wiki/hatom-issues#Feed_updated_. 28atom:updated.29 4. http://microformats.org/wiki/hatom-issues#Entry_id_.28atom:id.29 All of these issues cover areas where hAtom is not expressive enough to provide all the information necessary to generate a valid Atom file. Robert Bachmann, et al, worked around these issues by adding extensions to html2Atom.xsl. I've implemented some of extensions myself and they seem to work pretty naturally (even without authors even knowing about them!). David, if you like, I can find some more test cases and/or examples for each of these. -ryan From brian.suda at gmail.com Wed Jun 6 12:52:34 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Jun 6 12:52:38 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <200706061859.l56IxmUh011548@microformats.org> References: <200706061859.l56IxmUh011548@microformats.org> Message-ID: <21e770780706061252m35369eafye702072972d8df39@mail.gmail.com> On 6/6/07, bruce lawson wrote: > Can those at Mozilla reassure those of us who those of us who care > about accessibility that any microformat that uses the design > pattern for geo/ datetime data will also be equally detected if the > author chooses to use --- i think it would be a better idea instead to work within the microformats community and make the needed changes here rather than the browser doing something contrary to microformats, and therefore potentially breaking microformats now and in the future. It would be best NOT to let others define how microformats work outside of the microformats community! This is an open community and they can certainly particate in the development and give their feedback rather than ignore our process and interpret the specs how they see fit. -brian -- brian suda http://suda.co.uk From mejllistor at kodfabrik.se Wed Jun 6 13:52:14 2007 From: mejllistor at kodfabrik.se (Pelle W) Date: Wed Jun 6 13:52:32 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> Message-ID: <46671E7E.4030108@kodfabrik.se> Alex Faaborg skrev: > If the user is viewing a page with microformats and RSS through a > secure connection, they will have a yellow location bar containing a > favicon, lock icon, feed icon, and microformat icon. We are worried > that this is too much visual clutter. Options include things like > merging the feed icon and microformat icon, taking security UI out of > the location bar, moving some of these things to secondary UI, etc. I would suggest having something like a notification pop-up, like I have modified one of your pictures into: http://pelle.vox.nu/koncept/locationBarMenu_pelle_small.jpg Yellow to emphasize that it's a notification that appears for like 10 seconds if one has that enabled - yellow is the colour for that in the ajax-world as many may know. The notification-pop-up from the URL-bar icon would show the more hidden preferences of a website - like all the metadatas in the likes of RSS, microformats etc. but it could maybe also if the site is secure. If I click the icon - maybe I should get a pop-up-thing again or maybe a sidebar or a dialog should open showing all of the info found. Perhaps that would be a good solution and just to add - I made this mockup, but I'm not behind making anything Firefoxy - I'm just a swedish webdeveloper who's interested in microformats and the modern web ;) / Pelle From andy at pigsonthewing.org.uk Wed Jun 6 14:43:00 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Jun 6 14:44:26 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <21e770780706061252m35369eafye702072972d8df39@mail.gmail.com> References: <200706061859.l56IxmUh011548@microformats.org> <21e770780706061252m35369eafye702072972d8df39@mail.gmail.com> Message-ID: <7cZkOyGkpyZGFwsr@pigsonthewing.org.uk> In message <21e770780706061252m35369eafye702072972d8df39@mail.gmail.com>, Brian Suda writes >On 6/6/07, bruce lawson wrote: >> Can those at Mozilla reassure those of us who those of us who care >> about accessibility that any microformat that uses the design >> pattern for geo/ datetime data will also be equally detected if the >> author chooses to use > >--- i think it would be a better idea instead to work within the >microformats community and make the needed changes here rather than >the browser doing something contrary to microformats, and therefore >potentially breaking microformats now and in the future. > >It would be best NOT to let others define how microformats work >outside of the microformats community! This is an open community and >they can certainly particate in the development and give their >feedback rather than ignore our process and interpret the specs how >they see fit. You're right, but that puts the onus (and the moral responsibility) onto this community, to respond in a timely manner to, and to adequately resolve, the accessibility concerns about the abuse of "abbr" raised here a few weeks ago. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From paul_wilkins at xtra.co.nz Wed Jun 6 15:14:07 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Wed Jun 6 15:14:11 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI References: <200706061859.l56IxmUh011548@microformats.org><21e770780706061252m35369eafye702072972d8df39@mail.gmail.com> <7cZkOyGkpyZGFwsr@pigsonthewing.org.uk> Message-ID: <001101c7a888$009100b0$bc08a8c0@nzto22> From: "Andy Mabbett" > Brian Suda writes >> It would be best NOT to let others define how microformats work >> outside of the microformats community! This is an open community and >> they can certainly particate in the development and give their >> feedback rather than ignore our process and interpret the specs how >> they see fit. > > You're right, but that puts the onus (and the moral responsibility) onto > this community, to respond in a timely manner to, and to adequately > resolve, the accessibility concerns about the abuse of "abbr" raised > here a few weeks ago. Has anyone taken an in-depth look at how the usage of the abbr tag affects internet explorer? As IE doesn't seem to know about the abbr tag, will this affect scripts parsing the dom on IE browsers? -- Paul Wilkins From faaborg at mozilla.com Wed Jun 6 21:11:47 2007 From: faaborg at mozilla.com (Alex Faaborg) Date: Wed Jun 6 21:11:51 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <00b401c7a812$86b9f500$0201a8c0@andrieuhome> References: <00b401c7a812$86b9f500$0201a8c0@andrieuhome> Message-ID: <5FAF8EF5-AED6-4056-B395-FAB02E714E18@mozilla.com> > The visual presentation is an "affordance" that tells users that > clicking on it > navigates. Without the blue underline, you are back to the mystery > meat navigation. I certainly agree that the interface for interacting with microformats in the context of the page would be considerably easier to use with a visual affordance, but we should probably leave these visual affordances (buttons, etc) up to the Web designer. If Firefox were to proactively detect microformats and then modify the appearance of the page, that is a line that Web browsers usually don't cross. Of course we have certainly considered doing this, here is a pretty complete list of all of our design mockups that people might find interesting: http://wiki.mozilla.org/Microformats/UE/ideas We are still in the design phase for this feature, and looking for lots of feedback and ideas. Changing the mouse cursor is currently my favorite design, but we are completely open to new ideas. -Alex On Jun 6, 2007, at 1:13 AM, Joe Andrieu wrote: > Colin Barrett wrote: >> On Jun 5, 2007, at 10:57 PM, Paul Wilkins wrote: >> >>> Strictly speaking it isn't MMN because navigation itself isn't >>> involved. The problems surrounding the cursor change though are >>> identical. If it is the only mechanism to find microformat >> content, >>> it won't be found until someone chances across it if they >> notice it >>> changing when it crosses such content. >> >> I was thinking about this, and I wonder -- how did people learn the >> behavior that you can click on a blue, underlined piece of >> text? Think >> about a pre-web world where nobody knew what hypertext was. People >> needed to figure out somehow that you could click on links to make >> them activate. >> >> Enter, the hand cursor. If you think about it, it tells you nothing >> about what's actually going to happen when you click -- instead, it >> looks like someone about to click the mouse, so I suppose it's >> inviting for people to mimic the gesture? This still doesn't answer >> the question of how people would discover this. My guess is that >> people scan the page with their mouse as they read. I know I do that >> sometimes. Anyone have actual evidence? >> >> Perhaps we don't need to worry about discoverability of microformats >> further than just changing the cursor, after all. > > Blue hyperlinks are an idiom, which, once learned, was easy to > understand. > > However, they are far more than just the hover effect on the cursor. > > They are /also/ blue and underlined. > > Let's not under value the importance of that. The visual > presentation is an "affordance" that tells users that clicking on it > navigates. Without the blue underline, you are back to the mystery > meat navigation. Even today, if the text isn't blue underlined, > it better have some other affordance for me to understand it's a link. > > IMO, cursor effects should /support/ affordance, rather than being > the primary indicator. The visual presentation should show that > something special happens and then the cursor effect confirms it. > > My gut instinct for Firefox is that we probably need three steps > (1) an RSS-like microformats indicator (2) a way to "activate" uF > and (3) a way for users to then interact with said uF. We might > need offer multiple options for (2) and (3), we should certainly > consider several. > > I like highlighting on a page, but that can be annoying and > certainly hard to control from the HTML designers perspective. But it > could be a glyph appearing near the "corner" of a uF rather than a > full "highlight" effect around the uF container. Clicking on the > glyph or the highlighted section then lets the user interact with > the uF in some way. Unfortunately, this messes with the design > and potentially puts the user in weird-mode where clicks do > "abnormal" things compared to the non-uF highlighted mode (normal web > interaction). > > I think I prefer the idea of populating a list in a pop-up or > sidebar window with all of the uF available on the page. This avoids > the problem of design-clash and provides an obvious place for a > variety of interaction capabilities, like a right-clight to select > an application to send the uF to. > > -j > > -- > Joe Andrieu > SwitchBook Software > http://www.switchbook.com > joe@switchbook.com > +1 (805) 705-8651 > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From andy at pigsonthewing.org.uk Thu Jun 7 01:55:18 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Jun 7 01:57:21 2007 Subject: [uf-discuss] "Species" Straw Man deployed on Wikipedia Message-ID: The current "straw man" for the Species microformat: has been deployed, in part, on Wikipedia. *All* Wikipedia articles with "taxoboxes" (information panels on living things; and there are thousands): now emit a species microformat. For example: (a species) (a family of species) These are recognised (with some issues, being worked on) by the "Species" user script for Operator 0.7 (and the beta version of the next release, 0.8a) It now remains to firm-up the specification, and tweak the Wikipedia deployment accordingly. Such discussion should take place on "microformats-new", to which I've cross-posted and set follow-ups. -- Andy Mabbett From andy at pigsonthewing.org.uk Thu Jun 7 07:35:16 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Jun 7 07:36:51 2007 Subject: [uf-discuss] geo in Firefox 3 (as: Microformats gets strong showing in Firefox 3 UI) In-Reply-To: References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> Message-ID: In message , Mike Kaply writes >> One last thing, are there any thoughts on which microformats would be >> supported by the Firefox UI? Would it be all of them? Maybe it would >> only be those that are specs and not drafts? > >Yes. At this point it will probably be hCard, hCalendar, Address and >maybe geo. Why only "maybe" geo? I think there is a strong case for including geo, especially once KML and GPX export are available. Where is this being discussed, and how is it best to make one's views known, or to "vote"? -- Andy Mabbett From andy at pigsonthewing.org.uk Thu Jun 7 07:39:56 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Jun 7 07:41:35 2007 Subject: [uf-discuss] Microformats gets strong showing in Firefox 3 UI In-Reply-To: <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> References: <466319A8.6050409@digitalbazaar.com> <84ce626f0706041214y37e8f87el89cdc918be34a6e3@mail.gmail.com> <46647686.7080904@xtra.co.nz> <4665C695.6070205@kodfabrik.se> <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com> Message-ID: In message <29BF433F-31FE-4C15-844F-3FF59403E702@mozilla.com>, Alex Faaborg writes > >Discussion of microformat support in Firefox 3 in the Mozilla community >is going on here: http://groups.google.com/group/ >mozilla.dev.apps.firefox/browse_frm/thread/19660ddf0589e15e/ >d600f125dcc8b845#d600f125dcc8b845 Working link: aka -- Andy Mabbett From costello at mitre.org Thu Jun 7 07:42:40 2007 From: costello at mitre.org (Costello, Roger L.) Date: Thu Jun 7 07:42:49 2007 Subject: [uf-discuss] Problem with VoteLinks? Message-ID: Hi Folks, There may be a problem with VoteLinks. REVIEW OF VoteLinks Here's an example of using the VoteLinks Microformat to express support for a Web site that sells garlic capsules: Garlic Cholesterol Things to note: A. rev="vote-for" indicates that the VoteLinks Microformat is being used, and there is favorable support for the resource indicated by href B. title="I agree with ..." is used to provide a human-readable commentary (i.e., a rationale) on why the resource is favorably supported. COW PATH BEING PAVED BY VoteLinks There are countless examples (cow paths) on the Web of people expressing support for, or expressing disagreement with something, and providing the rationale for why they agree or disagree. There are two aspects to these cow paths: 1. Vote: An indication of agreement/disagreement (or, support/not support). 2. Rationale: A rationale for why you agree/disagree. For example, a BLOG comment provides a positive or negative response to a BLOG article and a rationale for the positive/negative response. VoteLinks is an attempt to standardize the notion of expressing support for or against a resource, plus a rationale for the vote. PROBLEM WITH VoteLinks As noted above, the rationale for a vote is in the title attribute. The value of a title attribute is only seen if someone happens to hover over the link. Effectively, the rationale for the vote is hidden. But the typical cow path for which VoteLinks is intended to address does not hide the rationale for a vote. Consider a BLOG comment: the rationale for the positive or negative comment is openly displayed. Today's VoteLinks is designed for machines first, humans second. This is a violation of the Microformat principle, which states: "design for humans first, machines second" [1]. The rationale for a vote should be visible to humans. SOLUTION Perhaps there is a need for a 2.0 version of VoteLinks? Desired characteristics: - backward compatible with VoteLinks 1.0 - the rationale for the vote is in the open (visible to humans) Thoughts? Roger Costello and Andy Gregorowicz [1] http://microformats.org/wiki/microformats#the_microformats_principles From ryan at technorati.com Thu Jun 7 10:22:44 2007 From: ryan at technorati.com (Ryan King) Date: Thu Jun 7 10:22:49 2007 Subject: [uf-discuss] Problem with VoteLinks? In-Reply-To: References: Message-ID: <9B0A3973-632F-409C-95CA-55415C12E190@technorati.com> On Jun 7, 2007, at 7:42 AM, Costello, Roger L. wrote: > Hi Folks, > > There may be a problem with VoteLinks. > > REVIEW OF VoteLinks > > Here's an example of using the VoteLinks Microformat to express > support > for a Web site that sells garlic capsules: > > title="I agree with taking garlic to lower cholesterol; > I took garlic capsules for 2 months and > it lowered my cholesterol by 30 points" > > href="http://www.all-about-lowering-cholesterol.com/garlic- > cholesterol. > html"> > Garlic Cholesterol > Have you seen such examples in the wild? Or is this something you've authored? I think this would more naturally be expressed in hReview.

I agree with taking garlic to lower cholesterol; I took garlic capsules for 2 months and it lowered my cholesterol by 30 points.

Garlic Cholesterol

If you want to put the rationale in human readable text, they this would be a way to do it. -ryan From brian.suda at gmail.com Thu Jun 7 10:30:41 2007 From: brian.suda at gmail.com (Brian Suda) Date: Thu Jun 7 10:31:08 2007 Subject: [uf-discuss] Problem with VoteLinks? In-Reply-To: <9B0A3973-632F-409C-95CA-55415C12E190@technorati.com> References: <9B0A3973-632F-409C-95CA-55415C12E190@technorati.com> Message-ID: <21e770780706071030r258721d2v277c438ac4409220@mail.gmail.com> On 6/7/07, Ryan King wrote: > I think this would more naturally be expressed in hReview. ... Garlic Cholesterol > If you want to put the rationale in human readable text, they this > would be a way to do it. --- the additional benefits would be that you could RATE the service, so you can give an additional fine-grained vote-for, 8/10 and still use the rev="vote-for" on the url. -brian -- brian suda http://suda.co.uk From costello at mitre.org Thu Jun 7 10:47:46 2007 From: costello at mitre.org (Costello, Roger L.) Date: Thu Jun 7 10:47:53 2007 Subject: [uf-discuss] Problem with VoteLinks? In-Reply-To: <21e770780706071030r258721d2v277c438ac4409220@mail.gmail.com> References: <9B0A3973-632F-409C-95CA-55415C12E190@technorati.com> <21e770780706071030r258721d2v277c438ac4409220@mail.gmail.com> Message-ID: The VoteLinks specification says that a VoteLink is used to (1) indicate agreement or disagreement with the resource indicated by href, and (2) the title attribute should be used to express a human-readable commentary (i.e., a rationale) for the vote. Brian and Ryan have shown that these two items of information are better expressed using hReview. Thus, it appears that VoteLinks is redundant at best, and in violation of the Microformat principles at worst, i.e., it hides rationale information - human information - in the title attribute. Thoughts? /Roger -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.