From m at klml.de Sat Dec 1 18:06:21 2007 From: m at klml.de (Klaus Mueller) Date: Sat Dec 1 18:06:24 2007 Subject: [uf-discuss] Wiki order? In-Reply-To: <39365AB7-861E-449F-8CC0-DA8A0A52DFA1@theryanking.com> References: <474B40ED.2090800@klml.de> <39365AB7-861E-449F-8CC0-DA8A0A52DFA1@theryanking.com> Message-ID: <4752131D.2000400@klml.de> Hi, ryan schrieb: >> * Is it OK to use more templates? >> ** one for different language versions of an Article, like the interwiki >> concept what do you think about this: http://microformats.org/wiki/Template:Interwiki the usage: http://microformats.org/wiki/process-de#Vorschlag_eines_Microformat >> ** "buttons" or boxes for the status of the site (standard, draft, >> discuss) > > Once again, volunteers welcome. :) and this: http://microformats.org/wiki/Template:Status you can see the usage on my userpage: http://microformats.org/wiki/User:VanGore the structure is from: http://microformats.org/wiki/process#Iterate a other idea: http://microformats.org/wiki/Template:formatset usage: http://microformats.org/wiki/bankaccount-examples the structure is from: http://microformats.org/wiki/process#Pages_to_create shuld we call this template "Related pages"? Comments are welcome, here or in the wiki. greet klml From p at premasagar.com Mon Dec 3 08:34:46 2007 From: p at premasagar.com (Premasagar Rose) Date: Mon Dec 3 08:34:52 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> References: <21e523c20711250243v7b3e5c5clc16203977441bf99@mail.gmail.com> <2e95f9b80711250334k650238e1se388df15f73fedb6@mail.gmail.com> <2D407C54-975A-4CB5-AF8B-2920E3B34452@ben-ward.co.uk> <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> Message-ID: <47543026.6010605@premasagar.com> Can anyone enlighten me...? The Operator Firefox extension seems to be doing something strange. When I added hCalendar to http://www.bbc.co.uk/worldservice/bangladeshboat/ the "Locations" column of Operator stopped displaying the location name and instead started displaying the event summary. Is this an issue with the Operator parser, or due to my HTML? Sample HTML (it also uses hAtom and xFolk):

  • Diary: Cyclone devastation

    The diary of the BBC's month-long journey along Bangladesh's rivers, examining climate change and other key issues.

    • last week
    • Rayenda, Bangladesh
    • Thanks, Prem. -- p@premasagar.com http://premasagar.com | http://dharmafly.com From tombaromba at gmail.com Mon Dec 3 09:51:07 2007 From: tombaromba at gmail.com (Tom Byers) Date: Mon Dec 3 09:51:09 2007 Subject: [uf-discuss] vevent question - matching summary Message-ID: Hi all, I'm trying to implement vevent on a calender. As in most people's lives I have events that repeat (weekly classes, etc...) but when I use the same summary, operator only chooses the first one - any ideas (if this has been asked before, please point me in the right direction) Thanks! Tom Byers From lists at ben-ward.co.uk Mon Dec 3 10:18:50 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Mon Dec 3 10:19:08 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <47543026.6010605@premasagar.com> References: <21e523c20711250243v7b3e5c5clc16203977441bf99@mail.gmail.com> <2e95f9b80711250334k650238e1se388df15f73fedb6@mail.gmail.com> <2D407C54-975A-4CB5-AF8B-2920E3B34452@ben-ward.co.uk> <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> Message-ID: <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> No immediate theories on your parsing problem I'm afraid, although I would flag this as an issue: On 3 Dec 2007, at 16:34, Premasagar Rose wrote: > > Rayenda, Bangladesh > There's no way that ?+22.31119;+89.86145? is an abbreviation of ?Rayenda, Bangladesh?. Please, don't neglect the defined semantics of HTML in order to hack parsers. Ben From scott at randomchaos.com Mon Dec 3 10:58:51 2007 From: scott at randomchaos.com (Scott Reynen) Date: Mon Dec 3 10:58:55 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> References: <21e523c20711250243v7b3e5c5clc16203977441bf99@mail.gmail.com> <2e95f9b80711250334k650238e1se388df15f73fedb6@mail.gmail.com> <2D407C54-975A-4CB5-AF8B-2920E3B34452@ben-ward.co.uk> <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> Message-ID: <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> On Dec 3, 2007, at 11:18 AM, Ben Ward wrote: >> > title="+22.31119;+89.86145"> >> Rayenda, Bangladesh >> > > There's no way that ?+22.31119;+89.86145? is an abbreviation of > ?Rayenda, Bangladesh?. Without commenting on the truthfulness of the statement, the above syntax says the opposite: that "Rayenda, Bangladesh" is an abbreviation of "+22.31119;+89.86145." The title attribute is the long form, not the abbreviation. I don't know if this is just careless language or actual confusion, but this has come up multiple times and I think it's important we're all clear on what the markup asserts if we're going to have a discussion about the truthfulness of that assertion. Peace, Scott From p at premasagar.com Mon Dec 3 11:08:19 2007 From: p at premasagar.com (Premasagar Rose) Date: Mon Dec 3 11:08:27 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> References: <21e523c20711250243v7b3e5c5clc16203977441bf99@mail.gmail.com> <2e95f9b80711250334k650238e1se388df15f73fedb6@mail.gmail.com> <2D407C54-975A-4CB5-AF8B-2920E3B34452@ben-ward.co.uk> <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> Message-ID: <47545423.3090604@premasagar.com> Thanks for your feedback, Ben. Isn't it the other way around? The contents of the element is an abbreviation for the full version given in the title attribute. That makes sense here: "Rayenda, Bangladesh" is a fuzzy approximation / abbreviation for a very specific geographical location "+22.31119;+89.86145". I took this as inspiration: http://microformats.org/wiki/geo-brainstorming Prem. Ben Ward wrote: > No immediate theories on your parsing problem I'm afraid, although I > would flag this as an issue: > > On 3 Dec 2007, at 16:34, Premasagar Rose wrote: >> > title="+22.31119;+89.86145"> >> Rayenda, Bangladesh >> > > There's no way that ?+22.31119;+89.86145? is an abbreviation of > ?Rayenda, Bangladesh?. Please, don't neglect the defined semantics of > HTML in order to hack parsers. > > Ben > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- p@premasagar.com http://premasagar.com | http://dharmafly.com From ryan at theryanking.com Mon Dec 3 11:54:21 2007 From: ryan at theryanking.com (ryan) Date: Mon Dec 3 11:54:51 2007 Subject: [uf-discuss] vevent question - matching summary In-Reply-To: References: Message-ID: <4AFC7FB5-05E9-4229-8A55-BD0636382C79@theryanking.com> On Dec 3, 2007, at 9:51 AM, Tom Byers wrote: > Hi all, I'm trying to implement vevent on a calender. As in most > people's lives I have events that repeat (weekly classes, etc...) but > when I use the same summary, operator only chooses the first one - any > ideas (if this has been asked before, please point me in the right > direction) Operator applies some heuristics to de-dupe microformat instances on a single page. It sounds like identical SUMMARYs is one of those. Can we get a url to this page? -ryan From tombaromba at gmail.com Mon Dec 3 12:57:39 2007 From: tombaromba at gmail.com (Tom Byers) Date: Mon Dec 3 12:57:42 2007 Subject: [uf-discuss] vevent question - matching summary In-Reply-To: <4AFC7FB5-05E9-4229-8A55-BD0636382C79@theryanking.com> References: <4AFC7FB5-05E9-4229-8A55-BD0636382C79@theryanking.com> Message-ID: Hi Ryan, thanks for the help (and the additions to my vocabulary :) ), I'm not on the right computer at the mo but I was roughing it out as this before:
    Things I do in the week
    Date Activity

    December 11th:

    7.30pm to 9.30pm

    Sculpture class: New model, class 1 of 5

    Camden, London

    December 18th:

    7.30pm to 9.30pm

    Sculpture class: New model, class 2 of 5

    Camden, London
    On Dec 3, 2007 7:54 PM, ryan wrote: > > On Dec 3, 2007, at 9:51 AM, Tom Byers wrote: > > > Hi all, I'm trying to implement vevent on a calender. As in most > > people's lives I have events that repeat (weekly classes, etc...) but > > when I use the same summary, operator only chooses the first one - any > > ideas (if this has been asked before, please point me in the right > > direction) > > Operator applies some heuristics to de-dupe microformat instances on > a single page. It sounds like identical SUMMARYs is one of those. > > Can we get a url to this page? > > -ryan > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From lists at ben-ward.co.uk Mon Dec 3 13:26:58 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Mon Dec 3 13:27:15 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> References: <21e523c20711250243v7b3e5c5clc16203977441bf99@mail.gmail.com> <2e95f9b80711250334k650238e1se388df15f73fedb6@mail.gmail.com> <2D407C54-975A-4CB5-AF8B-2920E3B34452@ben-ward.co.uk> <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> Message-ID: <8907BF9A-44EC-4718-A0CA-F27F33A6885F@ben-ward.co.uk> On 3 Dec 2007, at 18:58, Scott Reynen wrote: > On Dec 3, 2007, at 11:18 AM, Ben Ward wrote: > >>> >>> Rayenda, Bangladesh >>> >> >> There's no way that ?+22.31119;+89.86145? is an abbreviation of >> ?Rayenda, Bangladesh?. > > Without commenting on the truthfulness of the statement, the above > syntax says the opposite: that "Rayenda, Bangladesh" is an > abbreviation of "+22.31119;+89.86145." The title attribute is the > long form, not the abbreviation. I don't know if this is just > careless language or actual confusion, but this has come up > multiple times and I think it's important we're all clear on what > the markup asserts if we're going to have a discussion about the > truthfulness of that assertion. You are completely correct, not a misunderstanding on my part, I just wrote the wrong thing (I've been rather ill, my brain isn't joining all the dots in the right order at this point). I stand by point, and I think the examples on geo-brainstorming are dangerous. Premasagar, the ?brainstorming? pages are just that, and shouldn't be considered part of the specification itself. I'm sorry that our pages are misleading like that. The critical part of the HTML4 spec that causes ?Rayenda, Bangladesh? *not* to be an abbreviation of ?22.31119;+89.86145? is this: > ?The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it > would normally appear in running text. The title attribute of these elements may be used to provide > the full or expanded form of the expression.? > ?as it would normally appear in running text.? Whilst I appreciate the HTML4 spec can be a little vague sometimes, in this case it's pretty clear: ABBR is not for fuzzy approximations, it's for abbreviated expressions. I think we've got to be really delicate and careful about this. Microformats prides itself on building technologies on top of existing standards. The abbreviation pattern is a neat parsing trick, but you've gotta meet the requirements of the underlying technology. Regards, Ben For reference, the section from the HTML4 spec regarding ABBR and ACRONYM > ABBR: > Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.). > ACRONYM: > Indicates an acronym (e.g., WAC, radar, etc.). > > The ABBR and ACRONYM elements allow authors to clearly indicate > occurrences of abbreviations and acronyms. Western languages make > extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.", as > well as abbreviations like "M.", "Inc.", "et al.", "etc.". Both > Chinese and Japanese use analogous abbreviation mechanisms, wherein > a long name is referred to subsequently with a subset of the Han > characters from the original occurrence. Marking up these > constructs provides useful information to user agents and tools > such as spell checkers, speech synthesizers, translation systems > and search-engine indexers. > > The content of the ABBR and ACRONYM elements specifies the > abbreviated expression itself, as it would normally appear in > running text. The title attribute of these elements may be used to > provide the full or expanded form of the expression. > > Here are some sample uses of ABBR: > >

    > WWW > title="Société Nationale des Chemins de Fer"> > SNCF > > Doña > abbr. > Note that abbreviations and acronyms often have idiosyncratic > pronunciations. For example, while "IRS" and "BBC" are typically > pronounced letter by letter, "NATO" and "UNESCO" are pronounced > phonetically. Still other abbreviated forms (e.g., "URI" and "SQL") > are spelled out by some people and pronounced as words by other > people. When necessary, authors should use style sheets to specify > the pronunciation of an abbreviated form. ? http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 From glenn.jones at madgex.com Mon Dec 3 14:34:20 2007 From: glenn.jones at madgex.com (Glenn Jones) Date: Mon Dec 3 14:30:32 2007 Subject: [uf-discuss] ufXtract's portable social network parser Message-ID: <36A319113CF910438942741C4727ADFF015FA532@MOBY.Clarence.local> ufXtract's portable social network parser is a combination of the ufXtract microformats parser and a spider which follows rel="me" links. It has been designed to extract profiles and friends lists from social networks and other sites which have microformats support. The parser returns two main collections of data, all the rel="me" links and any hCard-XFN patterns. The parser API http://lab.backnetwork.com/ufXtract-psn/ A demo using JavaScript and JSON http://lab.backnetwork.com/ufXtract-psn/demo01.htm The Parser You can set the parser to single single or multiple domains. Currently, there are limits to the number of pages which will be parsed (20). Each collection item is given an additional source-url attribute to identify its origin There is support for both XML and JSON output, for both client and server-side development. The parser also uses a version of the representative hCard concept, which tries to identify the hCard representing the profile owner. The implementation is a little more complex than described on the microformats wiki as it extends over multiple pages and domains. This means you may find multiple representative hCards from one call to the API, but there should only ever be one per a URL. The Demo I believe there are a number of different ways that this functionality could be designed into web sites. So I have provided a simple interface design to demonstrate one possibility. It's a bit of a homage to the getsatisfaction.com registration page with a few extra twists. I would like to thank my co-worker James Wragg who created the JavaScript for the demo. Of the sites listed on the demo last.fm and ma.gnolia.com return the best results. The other sites have differing levels of portable social network support. It also works well against blogs such as adactio.com or tantek.com that are marked-up with rel="me" . It's worth trying out the two depth search levels. Pages not parsing You may find on some sites like twitter.com only certain pages are parsed. These sites often have good microformats support, but parts of their functionally are locked behind logon's. The parser does not support authenticated sessions as this would mean asking the user to pass me their log-in details which is a really bad idea. If I can lay my hands on a good Open-ID and/or OAuth C# libraries, I will try and implement some different types of authentication. Research This is all research work still under development, I placed it on the web for others to experiment with. I hope you enjoy playing with it. Glenn From pmw57 at xtra.co.nz Mon Dec 3 15:59:25 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Dec 3 15:59:28 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <8907BF9A-44EC-4718-A0CA-F27F33A6885F@ben-ward.co.uk> References: <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> <8907BF9A-44EC-4718-A0CA-F27F33A6885F@ben-ward.co.uk> Message-ID: <18050cf90712031559w7b420b4ercf9e36b669f334a8@mail.gmail.com> On Dec 4, 2007 10:26 AM, Ben Ward wrote: > The critical part of the HTML4 spec that causes 'Rayenda, Bangladesh' > *not* to be an abbreviation of '22.31119;+89.86145' is this: > > "The content of the ABBR and ACRONYM elements specifies the > abbreviated expression itself, as it > would normally appear in running text. The title attribute of > these elements may be used to provide > the full or expanded form of the expression." > > "as it would normally appear in running text." For the ABBR element to be use properly the title attribute would need to contain not a single point coordinate, but a representation of the Rayenda area itself. While this could be done by combining the techniques for image map poly coordinates with actual geo-coordinates, this needs to be more carefully and fully thought out. -- Paul Wilkins From jpanzer at acm.org Mon Dec 3 23:13:47 2007 From: jpanzer at acm.org (John Panzer) Date: Mon Dec 3 23:13:53 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <18050cf90712031559w7b420b4ercf9e36b669f334a8@mail.gmail.com> References: <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> <8907BF9A-44EC-4718-A0CA-F27F33A6885F@ben-ward.co.uk> <18050cf90712031559w7b420b4ercf9e36b669f334a8@mail.gmail.com> Message-ID: <4754FE2B.2020604@acm.org> Paul Wilkins wrote: > On Dec 4, 2007 10:26 AM, Ben Ward wrote: > >> The critical part of the HTML4 spec that causes 'Rayenda, Bangladesh' >> *not* to be an abbreviation of '22.31119;+89.86145' is this: >> >> "The content of the ABBR and ACRONYM elements specifies the >> abbreviated expression itself, as it >> would normally appear in running text. The title attribute of >> these elements may be used to provide >> the full or expanded form of the expression." >> >> "as it would normally appear in running text." >> > > For the ABBR element to be use properly the title attribute would need > to contain not a single point coordinate, but a representation of the > Rayenda area itself. While this could be done by combining the > techniques for image map poly coordinates with actual geo-coordinates, > this needs to be more carefully and fully thought out. > I've been asked how to handle this case (you have an area, or an inexact location, and want to encode it while providing a friendly human readable but possibly ambiguous short hand name for said place). Is there any existing practices to look at? Secondly, would this be a valid geo encoding 'abbreviation' ? the point under my finger right now John From lists at ben-ward.co.uk Tue Dec 4 08:24:22 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Tue Dec 4 08:24:38 2007 Subject: [uf-discuss] =?windows-1252?q?Avoiding_Premature_Optimisation_in?= =?windows-1252?q?_=91The_Process=92?= Message-ID: <9FA5BBE6-9205-4907-9266-884A1E4674C6@ben-ward.co.uk> As some of my recent messages will clearly suggest, I'm concerned that we are becoming too quick during development of new formats to leap on some of the optimisation patterns established for other formats (abbr-pattern, include-pattern). We're starting to see situations ? such as co-ordinates being the expansion of a place name ? where we seem to be thinking of the pattern before we're thinking about the meaning of the raw HTML it produces. I'd like to see the Process include something that perhaps discourages or even disallows the use of optimisation patterns (Include, ABBR, any others in the future) until after the first sets of mark-up are produced and semantically optimised. Then, where patterns do match the optimal mark-up and HTML semantics, they can be added. Where they do not, then we identify situations that require new patterns. My hope would be that by including such a step, we avoid shoehorning things into the ABBR pattern that are inappropriate, and force the entire development community to think about HTML first. Ben From hober0 at gmail.com Tue Dec 4 08:59:34 2007 From: hober0 at gmail.com (Edward O'Connor) Date: Tue Dec 4 09:00:33 2007 Subject: [uf-discuss] Re: Avoiding Premature Optimisation in =?utf-8?b?4oCYVGhlIFByb2Nl?= =?utf-8?b?c3PigJk=?= References: <9FA5BBE6-9205-4907-9266-884A1E4674C6@ben-ward.co.uk> Message-ID: Ben wrote: > I'd like to see the Process include something that perhaps discourages > or even disallows the use of optimisation patterns (Include, ABBR, any > others in the future) until after the first sets of mark-up are > produced and semantically optimised. Then, where patterns do match the > optimal mark-up and HTML semantics, they can be added. Where they do > not, then we identify situations that require new patterns. Sounds good to me. -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From ryan at theryanking.com Tue Dec 4 11:16:03 2007 From: ryan at theryanking.com (ryan) Date: Tue Dec 4 11:16:30 2007 Subject: =?WINDOWS-1252?Q?Re:_[uf-discuss]_Avoiding_Premature_Optimisatio?= =?WINDOWS-1252?Q?n_in_=91The_Process=92?= In-Reply-To: <9FA5BBE6-9205-4907-9266-884A1E4674C6@ben-ward.co.uk> References: <9FA5BBE6-9205-4907-9266-884A1E4674C6@ben-ward.co.uk> Message-ID: <4A465932-B9C4-4DC9-9BD6-B2B7C93543A3@theryanking.com> On Dec 4, 2007, at 8:24 AM, Ben Ward wrote: > As some of my recent messages will clearly suggest, I'm concerned > that we are becoming too quick during development of new formats to > leap on some of the optimisation patterns established for other > formats (abbr-pattern, include-pattern). > > We're starting to see situations ? such as co-ordinates being the > expansion of a place name ? where we seem to be thinking of the > pattern before we're thinking about the meaning of the raw HTML it > produces. > > I'd like to see the Process include something that perhaps > discourages or even disallows the use of optimisation patterns > (Include, ABBR, any others in the future) until after the first > sets of mark-up are produced and semantically optimised. Then, > where patterns do match the optimal mark-up and HTML semantics, > they can be added. Where they do not, then we identify situations > that require new patterns. > > My hope would be that by including such a step, we avoid > shoehorning things into the ABBR pattern that are inappropriate, > and force the entire development community to think about HTML first. I agree that many tend to jump to using the existing patterns without clearly thinking about about what that means in HTML. On the other hand, the patterns are things we've found common to several formats and could be considered microformats Good Practice (used appropriately), so I don't want to outright discourage the use of things like abbr-pattern, but just make it more clear how to use it well. -ryan From thom at ts0.com Wed Dec 5 01:48:18 2007 From: thom at ts0.com (Thom Shannon) Date: Wed Dec 5 01:48:24 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern Message-ID: <475673E2.70302@ts0.com> I've just updated an old greasemonkey script that adds links to friends sites as you type their name. It'll now add a hCard and XFN. http://www.ts0.com/2007/12/friend-links.asp Now I copied the HTML structure from Jeremy's site, he uses a span to specify the hCard. I was wondering though if cite would be more semantically valuable here? It depends on how it's used but for most cases I can think of it would work. Any ideas? From jeremy at adactio.com Wed Dec 5 05:45:29 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Wed Dec 5 05:45:37 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <475673E2.70302@ts0.com> References: <475673E2.70302@ts0.com> Message-ID: Thom wrote: > Now I copied the HTML structure from Jeremy's site, he uses a span to > specify the hCard. I was wondering though if cite would be more > semantically valuable here? It depends on how it's used but for most > cases I can think of it would work. Any ideas? Good point. I tend to use the cite element when I'm referencing *things* like films and books but I hadn't thought about using it for *people*. The spec says that the element should contain "a reference to other sources" and even gives an example of citing a person: As Harry S. Truman said... http://www.w3.org/TR/html401/struct/text.html#edef-CITE So I think you may be right, Thom. The cite element looks like a good fit for situations where I'm *referencing* other people (which is usually what happens in a blog post) and seems like a good fit for the root element of an hCard. It's certainly semantically richer than using a span element. I think this would make a good addition to the hCard authoring page: http://microformats.org/wiki/hcard-authoring along with suggestions about when to use (and not use) the address element, which currently is listed in the hCard FAQs: http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards If I have time, I'll do some Wiki updating later today. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From thom at ts0.com Wed Dec 5 07:20:56 2007 From: thom at ts0.com (Thom Shannon) Date: Wed Dec 5 07:21:01 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: References: <475673E2.70302@ts0.com> Message-ID: <4756C1D8.2000602@ts0.com> Jeremy Keith wrote: > The spec says that the element should contain "a reference to other > sources" and even gives an example of citing a person: I had a look at the specs too and it did seem to make sense. If you're referring to something someone said then that's clearly a citation. What if you're just saying they were present at an event? You can't really cite someone for that. I'll probably leave it out of the GM script for now. From stefan.auditor at erdfisch.de Wed Dec 5 07:21:55 2007 From: stefan.auditor at erdfisch.de (stefan.auditor@erdfisch.de) Date: Wed Dec 5 07:22:05 2007 Subject: [uf-discuss] Re: microformats-discuss Digest, Vol 31, Issue 2 Message-ID: <20071205152155.24053.qmail@km14019.keymachine.de> In der Zeit vom 05.12.2007 bis einschlie?lich 06.12.2007 befinde ich mich nicht im B?ro. Dringende Anfragen richten Sie bitte an info@erdfisch.de, weiterhin erreichen Sie unser B?ro unter +49 180 3471133 300 (0,09 EURO/Min aus dem Festnetz der Dt. Telekom). Selbstverst?ndlich werde ich mich nach meiner R?ckkehr sofort um Ihre Nachricht k?mmern. -- Mit freundlichen Gr??en, Stefan Auditor erdfisch :: internetl?sungen Stefan Auditor, Frank Holldorff und Fabian Lorenzen GbR Internet: http://erdfisch.de E-Mail : info@erdfisch.de Telefon : +49 180 3471133 300 (0,09 EURO/Min) Telefax : +49 180 3471133 301 (0,09 EURO/Min) Mannheimer Str. 281 69123 Heidelberg Drupal Developer - http://drupal.org Mitbetreiber Drupalcenter - http://drupalcenter.de From Michael.Smethurst at bbc.co.uk Wed Dec 5 07:53:33 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Dec 5 07:53:41 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes Message-ID: Hello! Just to say that hCalendar is used fairly extensively to describe broadcasts on bbc.co.uk/programmes here: http://www.bbc.co.uk/programmes/genres/music And here: http://www.bbc.co.uk/programmes/formats/animation And here: http://www.bbc.co.uk/programmes/b006qpgr/laston And etc Schedules for all bbc tv and radio to follow shortly and replace the existing network/what's on next year Having said that it's not been through accessibility testing yet so it might not be for long... 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 jim at eatyourgreens.org.uk Wed Dec 5 08:06:58 2007 From: jim at eatyourgreens.org.uk (James O'Donnell) Date: Wed Dec 5 08:07:04 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <4754FE2B.2020604@acm.org> References: <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> <8907BF9A-44EC-4718-A0CA-F27F33A6885F@ben-ward.co.uk> <18050cf90712031559w7b420b4ercf9e36b669f334a8@mail.gmail.com> <4754FE2B.2020604@acm.org> Message-ID: <0CA781E7-13E9-45CC-9443-F4F89774FE69@eatyourgreens.org.uk> On 4 Dec 2007, at 07:13, John Panzer wrote: > I've been asked how to handle this case (you have an area, or an > inexact location, and want to encode it while providing a friendly > human readable but possibly ambiguous short hand name for said > place). Is there any existing practices to look at? > Secondly, would this be a valid geo encoding 'abbreviation' ? > > the point under my finger right > now The thing about abbreviations is, the expanded text replaces the shortened form, rather than supplementing it. So I'd guess your example wouldn't work unless the text 'the point under my finger right now' could be replaced by '22.31119;+89.86145' and still make sense when read in its larger context. is probably a safer element to use for encoding lat/long positions. Jim Jim O'Donnell jim@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens From jim at eatyourgreens.org.uk Wed Dec 5 08:13:50 2007 From: jim at eatyourgreens.org.uk (James O'Donnell) Date: Wed Dec 5 08:13:56 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <4756C1D8.2000602@ts0.com> References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> Message-ID: On 5 Dec 2007, at 15:20, Thom Shannon wrote: > Jeremy Keith wrote: >> The spec says that the element should contain "a reference to >> other sources" and even gives an example of citing a person: > I had a look at the specs too and it did seem to make sense. If > you're referring to something someone said then that's clearly a > citation. What if you're just saying they were present at an event? > You can't really cite someone for that. I think that's a perfectly acceptable use of . I've used it for marking up the names of ships or books or bands. Handy for indicating that some text is the name of a person or thing. I wonder if this would solve a problem I've had in the past - marking up variations on a name, within a text, to indicate that they all refer to the same person (eg. Captain Cook or James Cook or just simply Cook). with a title attribute could probably do that, with a unique full name in the title attribute. Jim Jim O'Donnell jim@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens From thom at ts0.com Wed Dec 5 08:54:30 2007 From: thom at ts0.com (Thom Shannon) Date: Wed Dec 5 08:54:32 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> Message-ID: <4756D7C6.9090700@ts0.com> > I wonder if this would solve a problem I've had in the past - marking > up variations on a name, within a text, to indicate that they all > refer to the same person (eg. Captain Cook or James Cook or just > simply Cook). with a title attribute could probably do that, > with a unique full name in the title attribute. That sounds more like a case for abbr, they're all abbreviations of "Captain James Cook". You could also use a link to a common URI to indicate they're all referring to the same entity, possibly with a rel? From jpanzer at acm.org Wed Dec 5 09:28:33 2007 From: jpanzer at acm.org (John Panzer) Date: Wed Dec 5 09:25:52 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <0CA781E7-13E9-45CC-9443-F4F89774FE69@eatyourgreens.org.uk> References: <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> <8907BF9A-44EC-4718-A0CA-F27F33A6885F@ben-ward.co.uk> <18050cf90712031559w7b420b4ercf9e36b669f334a8@mail.gmail.com> <4754FE2B.2020604@acm.org> <0CA781E7-13E9-45CC-9443-F4F89774FE69@eatyourgreens.org.uk> Message-ID: <4756DFC1.1000800@acm.org> James O'Donnell wrote: > > On 4 Dec 2007, at 07:13, John Panzer wrote: > >> I've been asked how to handle this case (you have an area, or an >> inexact location, and want to encode it while providing a friendly >> human readable but possibly ambiguous short hand name for said >> place). Is there any existing practices to look at? >> Secondly, would this be a valid geo encoding 'abbreviation' ? >> >> the point under my finger right >> now > > The thing about abbreviations is, the expanded text replaces the > shortened form, rather than supplementing it. So I'd guess your > example wouldn't work unless the text 'the point under my finger right > now' could be replaced by '22.31119;+89.86145' and still make sense > when read in its larger context. > > is probably a safer element to use for encoding lat/long > positions. Yes, in context this is really additional annotation, so abbr would be wrong. Thanks. But then is title appropriate if using a span? the point under my finger right now. The adr microformat also works well when you have a named location, but in some cases we won't. The specific use case is that the location is automatically generated, e.g., via GPS or other means, and the author can opt to have it automatically added in to the content they create. E.g., a photo and caption from a GPS enabled cellphone. From ryan at theryanking.com Wed Dec 5 11:00:50 2007 From: ryan at theryanking.com (ryan) Date: Wed Dec 5 11:00:59 2007 Subject: [uf-discuss] hCalendar, geo & Operator extension In-Reply-To: <4756DFC1.1000800@acm.org> References: <474B4F67.30005@speakeasy.net> <273879E8-D7A6-4865-A00F-53C1AF86E862@randomchaos.com> <474C5387.1000104@speakeasy.net> <18050cf90711300255t106f2cd8qb32655881a4627fa@mail.gmail.com> <47543026.6010605@premasagar.com> <42EE08A1-C4A7-4FF1-86EA-ED04BFD5E374@ben-ward.co.uk> <09CDCF59-B641-42E6-A194-BC1D9326649B@randomchaos.com> <8907BF9A-44EC-4718-A0CA-F27F33A6885F@ben-ward.co.uk> <18050cf90712031559w7b420b4ercf9e36b669f334a8@mail.gmail.com> <4754FE2B.2020604@acm.org> <0CA781E7-13E9-45CC-9443-F4F89774FE69@eatyourgreens.org.uk> <4756DFC1.1000800@acm.org> Message-ID: <980426D5-7F47-474E-8A94-DB177FDB4D26@theryanking.com> On Dec 5, 2007, at 9:28 AM, John Panzer wrote: > James O'Donnell wrote: >> >> On 4 Dec 2007, at 07:13, John Panzer wrote: >> >>> I've been asked how to handle this case (you have an area, or an >>> inexact location, and want to encode it while providing a >>> friendly human readable but possibly ambiguous short hand name >>> for said place). Is there any existing practices to look at? >>> Secondly, would this be a valid geo encoding 'abbreviation' ? >>> >>> the point under my finger right >>> now >> >> The thing about abbreviations is, the expanded text replaces the >> shortened form, rather than supplementing it. So I'd guess your >> example wouldn't work unless the text 'the point under my finger >> right now' could be replaced by '22.31119;+89.86145' and still >> make sense when read in its larger context. >> >> is probably a safer element to use for encoding lat/long >> positions. > Yes, in context this is really additional annotation, so abbr would > be wrong. Thanks. > > But then is title appropriate if using a span? > > the point under my finger right > now. This won't work with any microformats. The title attribute is only defined to work on the abbr element. > The adr microformat also works well when you have a named location, > but in some cases we won't. The specific use case is that the > location is automatically generated, e.g., via GPS or other means, > and the author can opt to have it automatically added in to the > content they create. E.g., a photo and caption from a GPS enabled > cellphone. Honestly I'd recommend that unless you can put the lat/long in a human-visible spot, just leave it off. -ryan From pmw57 at xtra.co.nz Wed Dec 5 13:58:00 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Wed Dec 5 13:58:02 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <4756C1D8.2000602@ts0.com> References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> Message-ID: <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> On Dec 6, 2007 4:20 AM, Thom Shannon wrote: > Jeremy Keith wrote: > > The spec says that the element should contain "a reference to other > > sources" and even gives an example of citing a person: > I had a look at the specs too and it did seem to make sense. If you're > referring to something someone said then that's clearly a citation. What > if you're just saying they were present at an event? You can't really > cite someone for that. Not unless they said or did something. The CITE element really shouldn't stand alone, as there's an unstated source/target relationship implied in its usage. -- Paul Wilkins From jeremy at adactio.com Wed Dec 5 17:16:23 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Wed Dec 5 17:16:37 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> Message-ID: Paul Wilkins wrote: >> If you're >> referring to something someone said then that's clearly a >> citation. What >> if you're just saying they were present at an event? You can't really >> cite someone for that. >> > > Not unless they said or did something. The CITE element really > shouldn't stand alone, as there's an unstated source/target > relationship implied in its usage. > I don't believe that's true. The cite element can be used when the author is referring to something; not when that that something is doing the referencing. So, for example, if I refer to a book or a film, I'll enclose that inside a cite element. It can stand alone because there is no implied relationship other than "this is an entity": The Usual Suspects Designing with Web Standards I will use that markup even if I'm not quoting or citing anything from that entity. That seems to be perfectly in line with the spec. So the cite element is equally applicable when I'm referring to a person: Tantek ?elik As far as I can tell, the context around the thing/person being referenced is irrelevant. The fact that the entity is being referenced at all is justification enough for the cite element. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From pmw57 at xtra.co.nz Wed Dec 5 19:17:19 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Wed Dec 5 19:17:23 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> Message-ID: <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> On Dec 6, 2007 2:16 PM, Jeremy Keith wrote: > I don't believe that's true. The cite element can be used when the > author is referring to something; not when that that something is > doing the referencing. So, for example, if I refer to a book or a > film, I'll enclose that inside a cite element. It can stand alone > because there is no implied relationship other than "this is an entity": > > The Usual Suspects > > Designing with Web Standards > > I will use that markup even if I'm not quoting or citing anything > from that entity. That seems to be perfectly in line with the spec. It remains to be asked then, where is the citation? The contents of the CITE element contains the object being cited, so where is the subject? You cannot have a citation without a subject. How can you have any pudding if you don't eat your meat?! -- Paul Wilkins From stefan.auditor at erdfisch.de Wed Dec 5 19:18:14 2007 From: stefan.auditor at erdfisch.de (stefan.auditor@erdfisch.de) Date: Wed Dec 5 19:18:21 2007 Subject: [uf-discuss] Re: microformats-discuss Digest, Vol 31, Issue 3 Message-ID: <20071206031814.8427.qmail@km14019.keymachine.de> In der Zeit vom 05.12.2007 bis einschlie?lich 06.12.2007 befinde ich mich nicht im B?ro. Dringende Anfragen richten Sie bitte an info@erdfisch.de, weiterhin erreichen Sie unser B?ro unter +49 180 3471133 300 (0,09 EURO/Min aus dem Festnetz der Dt. Telekom). Selbstverst?ndlich werde ich mich nach meiner R?ckkehr sofort um Ihre Nachricht k?mmern. -- Mit freundlichen Gr??en, Stefan Auditor erdfisch :: internetl?sungen Stefan Auditor, Frank Holldorff und Fabian Lorenzen GbR Internet: http://erdfisch.de E-Mail : info@erdfisch.de Telefon : +49 180 3471133 300 (0,09 EURO/Min) Telefax : +49 180 3471133 301 (0,09 EURO/Min) Mannheimer Str. 281 69123 Heidelberg Drupal Developer - http://drupal.org Mitbetreiber Drupalcenter - http://drupalcenter.de From jeremy at adactio.com Thu Dec 6 02:46:10 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Thu Dec 6 02:46:25 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> Message-ID: <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> Paul Wilkins wrote: > It remains to be asked then, where is the citation? > The contents of the CITE element contains the object being cited, so > where is the subject? > You cannot have a citation without a subject. > > How can you have any pudding if you don't eat your meat?! But that's not what the spec says at all, as far as I can see. Your interpretation is that you can only use the CITE element if you are citing something *from* a resource (book/film/person, etc.). But I can't find any mention of that in the spec. As far as I can see, the CITE element can (and should) be used when you are *referencing* a resource (book/film/person, etc.) regardless of what the surrounding context is. So in HTML I could say: The film Gone With The Wind contains the line Frankly my dear, I don't give a damn. But I could equally say: Gone With The Wind is a film. Or even: Gone With The Wind You seem to be suggesting that only the first example is the correct use of the CITE element. That's not the case. All three are fine. You ask "where is the citation?" That's what the BLOCKQUOTE and Q elements are for. The CITE element is not supposed to be used for citations, it is used for references. That would be a lot clearer if the element were named REFERENCE instead of CITE. I think that, like the ADDRESS element, it is the confusing name choice for the element that it is leading to a lot of misunderstanding. The CITE element is not a CITATION element. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From mail at tobyinkster.co.uk Thu Dec 6 08:11:31 2007 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Dec 6 09:13:07 2007 Subject: [uf-discuss] Re: Jeremy's inline friend link pattern References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> Message-ID: Jeremy Keith wrote: > As far as I can see, the CITE element can (and should) be used when you > are *referencing* a resource (book/film/person, etc.) regardless of what > the surrounding context is. > > So in HTML I could say: > The film Gone With The Wind contains the line Frankly my > dear, I don't give a damn. > > But I could equally say: > Gone With The Wind is a film. > > Or even: > Gone With The Wind I think you're taking the meaning of "referencing" a bit too far -- taking it to mean "mentioning", whereas I think the intention of the HTML spec is that it means "including as a reference", which is a somewhat narrower meaning. If your interpretation is right, then it would be equally correct to write:

    Cheese is a food.

    -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 11 days, 22:58.] Sharing Music with Apple iTunes http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/ From jeremy at adactio.com Thu Dec 6 10:20:39 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Thu Dec 6 10:20:51 2007 Subject: [uf-discuss] Re: Jeremy's inline friend link pattern In-Reply-To: References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> Message-ID: Toby wrote: > If your interpretation is right, then it would be equally correct > to write: > >

    Cheese is a food.

    That's right. And in some situations, like a food blog, that would be good usage. It all depends on the individual case of course. But yes, just about any noun could potentially be marked up with the CITE element. That doesn't mean that every noun *should* be marked up with the CITE element: the author still needs to exercise judgement. But it is not wrong to mark up a book, film, thing or person with the CITE element... which is what the original question was all about. Given the choice between: Tantek ?elik and Tantek ?elik ...the second option has a little bit more semantic richness. Neither is incorrect though. In the use case which originally kicked off this discussion, mentioning someone in the course of a blog post is most definitely referencing them (even if I'm not quoting from them). Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From pmw57 at xtra.co.nz Thu Dec 6 10:26:54 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Thu Dec 6 10:26:57 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> Message-ID: <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> On Dec 6, 2007 11:46 PM, Jeremy Keith wrote: > As far as I can see, the > CITE element can (and should) be used when you are *referencing* a > resource (book/film/person, etc.) regardless of what the surrounding > context is. > > So in HTML I could say: > > The film Gone With The Wind contains the line Frankly > my dear, I don't give a damn. Yes, that's fine, you have the relationship of gone with the wind => quotation > But I could equally say: > > Gone With The Wind is a film. You could say it, but you'll be wrong. > Or even: > > Gone With The Wind it makes no sense to have a citation all by itself. As time goes on, people have been using the cite element for more and more inappropriate uses. The developers understand this and have been providing more accurate descriptions of how the CITE element is to be used. HTML 5 says the following http://www.whatwg.org/specs/web-apps/current-work/#the-cite The cite element represents a citation: the source, or reference, for a quote or statement made in the document. A citation is not a quote (for which the q element is appropriate). This is incorrect usage:

    This is wrong!, said Ian.

    This is the correct way to do it:

    This is correct!, said Ian.

    This is also wrong, because the title and the name are not references or citations:

    My favourite book is The Reality Dysfunction by Peter F. Hamilton.

    This is correct, because even though the source is not quoted, it is cited:

    According to the Wikipedia article on HTML, HTML is defined in formal specifications that were developed and published throughout the 1990s.

    And XHTML 2.0 has this to say http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.2. The cite element contains a citation or a reference to other sources. In the following example, the cite element is used to reference the book from which the quotation is taken: cite as book reference As Gandalf the White said in The Two Towers, "The hospitality of your hall is somewhat lessened of late, Theoden King." cite to reference another specification More information can be found in [XML]. -- Paul Wilkins From scott at randomchaos.com Thu Dec 6 12:52:31 2007 From: scott at randomchaos.com (Scott Reynen) Date: Thu Dec 6 12:52:46 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> Message-ID: <447BF418-594A-4AD6-B77E-D44411504F52@randomchaos.com> On Dec 6, 2007, at 11:26 AM, Paul Wilkins wrote: > HTML 5 says the following > http://www.whatwg.org/specs/web-apps/current-work/#the-cite HTML 5 isn't necessarily a definitive source on semantics in HTML 4 and XHTML, but in this case, I think it's the reasonable elaboration on what little HTML 4 says, which is "Contains a citation or a reference to other sources." A source is where something comes from, so we have to have that something in order for the referenced object to be a source. That something isn't necessarily a specific quote, but it has to be at least a vague description. For example, I think "Tantek talked about microformats" makes sense because [Tantek] is the source of [talk about microformats]. But "I had lunch with Tantek" doesn't make sense (without additional context) because here the referenced object [Tantek] is not the source of anything. Peace, Scott From Simone.Hindin at ccc.govt.nz Thu Dec 6 19:20:52 2007 From: Simone.Hindin at ccc.govt.nz (Hindin, Simone) Date: Thu Dec 6 19:21:00 2007 Subject: [uf-discuss] vevent question - matching summary In-Reply-To: References: <4AFC7FB5-05E9-4229-8A55-BD0636382C79@theryanking.com> Message-ID: <4E5744ACA0F432439EECAA3424C5251D0A0D5EDF@CCOEXCV01.ccity.biz> Hi Ryan, I had the same problem and it turned out to be a setting in Operator - in the Options - General tab check that you haven't got Remove duplicates ticked - I think it might install ticked as default. Simone Hindin Digital Library Services Christchurch City Libraries p: 03 941 7850 e: libwebteam@ccc.govt.nz w: http://library.christchurch.org.nz/ b: http://cclblog.wordpress.com/ -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Tom Byers Sent: Tuesday, 4 December 2007 9:58 am To: Microformats Discuss Subject: Re: [uf-discuss] vevent question - matching summary Hi Ryan, thanks for the help (and the additions to my vocabulary :) ), I'm not on the right computer at the mo but I was roughing it out as this before:
    Things I do in the week
    Date Activity

    December 11th:

    7.30pm to 9.30pm

    Sculpture class: New model, class 1 of 5

    Camden, London

    December 18th:

    7.30pm to 9.30pm

    Sculpture class: New model, class 2 of 5

    Camden, London
    On Dec 3, 2007 7:54 PM, ryan wrote: > > On Dec 3, 2007, at 9:51 AM, Tom Byers wrote: > > > Hi all, I'm trying to implement vevent on a calender. As in most > > people's lives I have events that repeat (weekly classes, etc...) but > > when I use the same summary, operator only chooses the first one - any > > ideas (if this has been asked before, please point me in the right > > direction) > > Operator applies some heuristics to de-dupe microformat instances on > a single page. It sounds like identical SUMMARYs is one of those. > > Can we get a url to this page? > > -ryan > _______________________________________________ > 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 ********************************************************************** This electronic email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. The views expressed in this message are those of the individual sender and may not necessarily reflect the views of the Christchurch City Council. If you are not the correct recipient of this email please advise the sender and delete. Christchurch City Council http://www.ccc.govt.nz ********************************************************************** From jeremy at adactio.com Fri Dec 7 05:22:30 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Fri Dec 7 05:22:52 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> Message-ID: Paul Wilkins wrote: > it makes no sense to have a citation all by itself. > > As time goes on, people have been using the cite element for more and > more inappropriate uses. I agree with you there. But the abuse I see is more along the lines of using the CITE element where a Q or BLOCKQUOTE would be more appropriate. > The developers understand this and have been > providing more accurate descriptions of how the CITE element is to be > used. > > HTML 5 says the following Um. That's HTML 5. I'm talking about today's specs. As Scott says: > HTML 5 isn't necessarily a definitive source on semantics in HTML 4 > and XHTML That said, I take your point that using the CITE element to mark up a person/place/thing/object without any context is really pushing it. I think you're right when you say: >> Gone With The Wind is a film. > > You could say it, but you'll be wrong. However, I don't think that every use of the CITE element *requires* an accompanying citation (using Q or BLOQCKQUOTE). I think that Scott is write when he says that context is the key criteria: > A source is where something comes from, so we have to have that > something in order for the referenced object to be a source. That > something isn't necessarily a specific quote, but it has to be at > least a vague description. So, for the case that sparked off this discussion?mentioning people in blog posts?I think the CITE element will often be appropriate: I was chatting with Tantek yesterday. That, in my opinion, is appropriate (though it's certainly on the edge). That would probably be marked up as a hyperlink in a blog post: I was chatting with Tantek yesterday. Then there's the use of ABBR that Thom was talking about for mentioning friends by their first names: I was chatting with Tantek yesterday. Which is easily turned into an hCard: I was chatting with Tantek yesterday. So, quick straw poll: does that look a reasonable use of the CITE element? Does anything think that SPAN would be a better/safer option in this case? I suppose it would probably depend on the rest of the paragraph or blog post but usually you wouldn't mention someone in a blog post without some reason that probably involves referencing them, right? Michael MD wrote: >> The CITE element is not a CITATION element. > no wonder I don't see it used very often -- that is too confusing > for people in the real world! Agreed. It's as confusing as the ADDRESS element. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From hober0 at gmail.com Fri Dec 7 10:18:50 2007 From: hober0 at gmail.com (Edward O'Connor) Date: Fri Dec 7 10:36:00 2007 Subject: [uf-discuss] Re: Jeremy's inline friend link pattern References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> <447BF418-594A-4AD6-B77E-D44411504F52@randomchaos.com> Message-ID: Jeremy wrote: > I was chatting with title="Tantek ?elik"> href="http://tantek.com/">Tantek yesterday. > > So, quick straw poll: does that look a reasonable use of the CITE > element? I think it depends on the surrounding text. If the next sentence is "He made a really interesting point about that got me thinking blah blah blah," then I think is entirely appropriate. But if you just say that you had lunch with him and that you ordered the curry, there's not even "a vague description" (in Scott's words) of what you're citing Tantek about. Scott wrote: > A source is where something comes from, so we have to have that > something in order for the referenced object to be a source. That > something isn't necessarily a specific quote, but it has to be at least > a vague description. For example, I think "Tantek talked > about microformats" makes sense because [Tantek] is the source of [talk > about microformats]. But "I had lunch with Tantek" > doesn't make sense (without additional context) because here the > referenced object [Tantek] is not the source of anything. -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From pmw57 at xtra.co.nz Fri Dec 7 11:32:04 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Dec 7 11:32:07 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> Message-ID: <18050cf90712071132o32868d60ld67edd58baa7000f@mail.gmail.com> On Dec 8, 2007 2:22 AM, Jeremy Keith wrote: > However, I don't think that every use of the CITE element *requires* > an accompanying citation (using Q or BLOQCKQUOTE). I think that Scott > is write when he says that context is the key criteria: The CITE element doesn't require that the citation be explicitly marked up, but there has to be a citation of some form for the CITE element to be involved. This is right:

    According to the Wikipedia article on HTML, HTML is defined in formal specifications that were developed and published throughout the 1990s.

    This is wrong:

    My favourite book is The Reality Dysfunction by Peter F. Hamilton.

    The above examples are explicit examples that the specifications give to help teach you right from wrong. You will need to convince the working group that created the specifications otherwise, before your desired use is to be considered right. -- Paul Wilkins From pmw57 at xtra.co.nz Fri Dec 7 11:37:08 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Dec 7 11:37:13 2007 Subject: [uf-discuss] Jeremy's inline friend link pattern In-Reply-To: References: <475673E2.70302@ts0.com> <4756C1D8.2000602@ts0.com> <18050cf90712051358x273582a3v831b59b034222f7b@mail.gmail.com> <18050cf90712051917u2d2d567bsdd08754936d9b7f1@mail.gmail.com> <60291B96-9491-405C-A339-AE7F81B932D5@adactio.com> <18050cf90712061026v22ecb9c7kafb34d3a2f09dfc6@mail.gmail.com> Message-ID: <18050cf90712071137j7d0333a6g568f61e4cc90709a@mail.gmail.com> On Dec 8, 2007 2:22 AM, Jeremy Keith wrote: > I was chatting with title="Tantek ?elik"> href="http://tantek.com/">Tantek yesterday. > > So, quick straw poll: does that look a reasonable use of the CITE > element? Does anything think that SPAN would be a better/safer option > in this case? I suppose it would probably depend on the rest of the > paragraph or blog post but usually you wouldn't mention someone in a > blog post without some reason that probably involves referencing > them, right? If it is followed by something that was clearly sourced from Tantek then it would be okay. Think about it like this. The CITE element represents the source or reference for a quote or statement. No quote, no statement, no cite. It's as simple as that. -- Paul Wilkins From lists at ben-ward.co.uk Sun Dec 9 08:08:08 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Sun Dec 9 08:08:15 2007 Subject: =?WINDOWS-1252?Q?Re:_[uf-discuss]_Re:_=91XHTML=92_references_to_?= =?WINDOWS-1252?Q?=91HTML=92?= In-Reply-To: <33DAA2D7-2BB0-425B-A679-CBBF10CF0AA9@ben-ward.co.uk> References: <52521346-6478-4BCB-8219-ACC21A1164DD@ben-ward.co.uk> <18050cf90711261149m25c3f1f4p1e672d79d08dc3ad@mail.gmail.com> <2D2D7E14-5AFB-401E-9E15-BF14B8503591@ben-ward.co.uk> <4EE30802-E40C-4D25-8869-9D1592A2B220@ben-ward.co.uk> <18050cf90711262337i7b5a54a5sd9cd7ea66a3fe17a@mail.gmail.com> <33DAA2D7-2BB0-425B-A679-CBBF10CF0AA9@ben-ward.co.uk> Message-ID: <082141CC-DFE9-4E1B-8A86-5A6275AE954C@ben-ward.co.uk> Got around to making some of these changes today. Actually not as many as I'd expected to. The pages with slightly tweaked references to ?HTML or XHTML? are: [[hcalendar]] M http://microformats.org/wiki? title=hcalendar&diff=0&oldid=23673 * BenWard * (+5) Making consistant references to ?XHTML? and ?HTML? as per uf-discuss thread last week. [[hcard]] M http://microformats.org/wiki? title=hcard&diff=0&oldid=23675 * BenWard * (-3) Making consistant references to ?XHTML? and ?HTML? as per uf-discuss thread last week. [[rel-license]] M http://microformats.org/wiki?title=rel- license&diff=0&oldid=23676 * BenWard * (+6) Making consistent references to ?XHTML? and ?HTML? as per uf-discuss thread 2007-11-26 [[geo]] M http://microformats.org/wiki?title=geo&diff=0&oldid=23677 * BenWard * (+5) Making consistent references to ?XHTML? and ?HTML? as per uf-discuss thread 2007-11-26 [[xfolk]] M http://microformats.org/wiki? title=xfolk&diff=0&oldid=23678 * BenWard * (-1) Making consistent references to ?XHTML? and ?HTML? as per uf-discuss thread 2007-11-26 [[adr]] M http://microformats.org/wiki?title=adr&diff=0&oldid=23679 * BenWard * (+3) Making consistent references to ?XHTML? and ?HTML? as per uf-discuss thread 2007-11-26 [[hreview]] M http://microformats.org/wiki? title=hreview&diff=0&oldid=23680 * BenWard * (-10) Making consistent references to ?XHTML? and ?HTML? as per uf-discuss thread 2007-11-26 [[hresume]] M http://microformats.org/wiki? title=hresume&diff=0&oldid=23681 * BenWard * (+4) Making consistent references to ?XHTML? and ?HTML? as per uf-discuss thread 2007-11-26 As per the discussion last week, in the first instance these pages now refer to both ?HTML? and ?XHTML? explicitly, and later references are just ?HTML?. The exception to this at the moment is the XOXO spec, which has been written in a very XHTML-centric way from the outset, and may need to be reviewed in relation to how it is actually being published on the web (to see whether we need to accommodate a reality of publishers putting XOXO in HTML documents, not just XHTML). I've also not yet update the ?XHTML Design Principals? template which recurs in most of the above pages. Again, that's a very XHTML centric passage which doesn't accommodate HTML so cleanly and can't be tweaked with find and replace. Any suggestions on changes to those passages are appreciated. Regards, Ben On 27 Nov 2007, at 10:01, Ben Ward wrote: > Right, I'll put this on my to-do list. I don't know how much work > it's going to be yet, but let's say I'll plan to start updating > pages on Friday. That's the rest of the week for anyone else to > object to the change. > > The change I propose is: > ? Update the first mention of ?HTML? or ?XHTML? (or variant) in > a page to ?HTML and XHTML? > ? Update other references to XHTML, (X)HTML or X/HTML to ?HTML? > > Ben From martin at weborganics.co.uk Sun Dec 9 16:33:11 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Dec 9 16:31:32 2007 Subject: [uf-discuss] ANN: hAudio-RSS Message-ID: <1197246791.14282.16.camel@localhost.localdomain> Hello all I am pleased to announce hAudio-RSS which uses the hAudio microformat and XSL to produce a RSS2 Podcast that you can play in iTunes, Amarok, songbird, Win Amp, google reader? etc... source: http://weborganics.co.uk/haudio-rss/ transformation: http://tools.weborganics.co.uk/haudio/index.php?id=http://weborganics.co.uk/haudio-rss/ Feed Validator: http://feedvalidator.org/check.cgi?url=http://tools.weborganics.co.uk/haudio/index.php?id=http://weborganics.co.uk/haudio-rss/ I have left notes in the source file to give hints on how it is done. I will shortly be releasing all the source files and a transformation service that you can just download and drop in the back end of any site using PHP 5+ that will give publishers the ability to perform their own server side transformations and not have to use services like h2A and x2v much like all the other services at http://tools.weborganics.co.uk/ Comments are welcome Best Wishes Martin McEvoy WebOrganics From andy at pigsonthewing.org.uk Wed Dec 12 10:29:41 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Dec 12 10:31:09 2007 Subject: [uf-discuss] [admin] Notice of community ban In-Reply-To: <5C39C54B-03F3-4115-96BC-7FA5C02396B9@allinthehead.com> References: <5C39C54B-03F3-4115-96BC-7FA5C02396B9@allinthehead.com> Message-ID: In message <5C39C54B-03F3-4115-96BC-7FA5C02396B9@allinthehead.com>, Drew McLellan writes >This is an email regarding Andy Mabbett's recent and persistent >negative conduct within the microformats community. Namely: > >* Unpleasant and overly-aggressive communication with members of the >community on both [mf-new] Cite? > and in private email I wasn't aware that my private e-mail was any of your (collective) business; but since you consider that it is, what are you going to do about the person, from this community, who has twice sent me offensive e-mails, suggesting that I seek psychiatric help? >* Engaging in wiki edit wars It takes two (at least) to do so. If I did that (and I note again that no evidence is provided, and no supposed broken rules cited), where are the sanctions against the other party/ies? >* Excessive argumentativeness for the sake of debate If you're going to take actions based on my supposed reasons for doing something (again something uncited and unproven), you're going to need to find someone whose telepathic skills are more reliable than whoever it is you're using at present. Otherwise, such vague accusations might be seen as suggesting that you're inventing arbitrary thought-crimes for reasons which are neither neutral or just. >These are traits he has been warned about before That's a lie. >and for which has been previously banned. As is that. > They are in clear contradiction with the "be nice" guideline: >http://microformats.org/wiki/mailing-lists#Be_nice No: there is no "clear contradiction", since both that guideline and what I'm accused of a vague and intangible. And in what way is the implication that I'm a "jerk" in compliance with that guideline? >This behaviour continues to be harmful to the community, and therefore, >the admins have concluded there is no other option than to issue Andy >with a further 30 day ban from community participation. Whereby, the partially-anonymous clique which "governs" this initiative proves once again that it is unfit to do so. >With regret, Andy Mabbett, is banned from community participation for a >period of 30 days from today. I regard the expression of regret as totally insincere. -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Dec 12 10:29:46 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Dec 12 10:31:13 2007 Subject: [uf-discuss] [admin] Notice of community ban In-Reply-To: References: <02c401c811fc$b056f9e0$160da8c0@CThq.corp.srps.com> Message-ID: In message , Tantek ?elik writes >On 10/18/07 8:03 PM, "Steve Robillard" wrote: > >> I don't believe anyone else has been banned, but rather that Andy has been >> banned multiple times, and it appears to have had little effect. > >It did actually help for a while last time, as Andy's emails and behavior >were certainly civil I have - unlike some here - never been uncivil. >for a while (he was last banned for a week back in >July). Unfortunately though, for whatever reason, his behavior lapsed, >which then dragged (drug?) the tone down in the lists, to the point where >many people were made to feel unmotivated to participate. Please explain your "drug" reference. >It's a good question. A lot of us try to be optimists about human nature >and thus keep hoping for the best. This despite the fact that in this case, >this individual has for example been banned from at least one other >wiki-centric community, e.g. Wikipedia, for a year (for a second time). The relevance of that ad hominem comment to this incident is..? (In any case, the person responsible for orchestrating the first ban has since publicly apologised to me for his behaviour (after having been banned himself, for using abusive sock-puppets). The second was described by a neutral observer as "a brutal and vindictive form of coercion".) >I will personally commit to (as I think the other admins will, though I am >not speaking for them) improving the documentation of who the admins are, >and the minimal processes that the admins follow ...tumbleweed passes. [Snip excessive quoting, made in contravention of the community's own guidelines.] -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Dec 12 10:48:53 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Dec 12 10:50:35 2007 Subject: [uf-discuss] Solo pursuits and extending Geo Message-ID: A while ago, Tantek Celik relegated "Species" and the "Geo Extension" (and other initiatives), to a "solo pursuits" section of the "exploratory discussions" page: I find this distinction arbitrary and unnecessarily divisive. ==Species== I have restored the "Species" initiative, because there is clearly wider support, not least its implementation in Operator, and on Wikipedia. ==Geo== The support for extending Geo (to include elevation/ altitude; boundaries, routes and trails, and other bodies such as the Moon and Mars) is perhaps less obvious, but there have been comments from several interested parties: I would therefore invite anyone interested in further work to develop Geo in one or more of the above three ways, to express their interest here, and. or on the relevant wiki pages. -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Dec 12 11:02:10 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Dec 12 11:03:21 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: References: Message-ID: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> In message , Michael Smethurst writes >Just to say that hCalendar is used fairly extensively to describe >broadcasts on bbc.co.uk/programmes here: > >http://www.bbc.co.uk/programmes/genres/music >http://www.bbc.co.uk/programmes/formats/animation >http://www.bbc.co.uk/programmes/b006qpgr/laston >Having said that it's not been through accessibility testing yet so it >might not be for long... It will be interesting to know the outcome of that testing, in the light of mark-up like: 16:03 and the issues raised here: Who's doing it? -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Dec 12 11:25:31 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Dec 12 11:27:02 2007 Subject: [uf-discuss] adr in Operator In-Reply-To: References: Message-ID: In message , Mike Kaply writes >Removing support for an adr by itself in the UI. >Should I remove it completely since 99.9999% of adrs are in hCards? Now that you've done so (in v0.9 beta), there's an issue, because invalid ADRs don't necessarily show up as invalid hCards, and so Operator functions less well as a validator. -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Dec 12 11:27:16 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Dec 12 11:29:13 2007 Subject: [uf-discuss] Announcement: WebCamp workshop on Social Network Portability In-Reply-To: <474C10E5.6080907@deri.org> References: <474C10E5.6080907@deri.org> Message-ID: In message <474C10E5.6080907@deri.org>, John Breslin writes >I am happy to announce the "Social Network Portability" workshop >(co-located with BlogTalk) to be held in Cork, Ireland on the 2nd March >2008. You can view the wiki page for this event at >http://webcamp.org/SocialNetworkPortability Perhaps you could add some microformats to that page? -- Andy Mabbett From qidydl at gmail.com Wed Dec 12 11:31:16 2007 From: qidydl at gmail.com (David O) Date: Wed Dec 12 11:31:20 2007 Subject: [uf-discuss] [admin] Notice of community ban In-Reply-To: References: <02c401c811fc$b056f9e0$160da8c0@CThq.corp.srps.com> Message-ID: On Dec 12, 2007 1:29 PM, Andy Mabbett wrote: > >for a while (he was last banned for a week back in > >July). Unfortunately though, for whatever reason, his behavior lapsed, > >which then dragged (drug?) the tone down in the lists, to the point where > >many people were made to feel unmotivated to participate. > > Please explain your "drug" reference. I think he was searching for the proper past tense of "drag" and wasn't sure whether "dragged" or "drug" sounded better. - David From andy at pigsonthewing.org.uk Wed Dec 12 15:22:52 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Dec 12 15:24:13 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> Message-ID: In message <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com>, Jeff McNeill writes >There hasn't been much lately regarding the 'alternates' discussion [...] >Any thoughts? What's the use-case? -- Andy Mabbett From martin at weborganics.co.uk Wed Dec 12 15:49:05 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Dec 12 15:47:18 2007 Subject: [uf-discuss] [admin] Notice of community ban In-Reply-To: References: <02c401c811fc$b056f9e0$160da8c0@CThq.corp.srps.com> Message-ID: <1197503345.9917.0.camel@localhost.localdomain> On Wed, 2007-12-12 at 14:31 -0500, David O wrote: > On Dec 12, 2007 1:29 PM, Andy Mabbett wrote: > > >for a while (he was last banned for a week back in > > >July). Unfortunately though, for whatever reason, his behavior lapsed, > > >which then dragged (drug?) the tone down in the lists, to the point where > > >many people were made to feel unmotivated to participate. > > > > Please explain your "drug" reference. > > I think he was searching for the proper past tense of "drag" and > wasn't sure whether "dragged" or "drug" sounded better. > LOL Welcome back Andy ;) > - David > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From jeff at jeffmcneill.com Thu Dec 13 01:27:31 2007 From: jeff at jeffmcneill.com (Jeff McNeill) Date: Thu Dec 13 01:27:37 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> Message-ID: <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> Aloha Andy, et al, Use cases for alternates could be as follows: 1. Amazon.com page on a book with alternate versions, e.g., http://www.amazon.com/gp/product/0789723107/ref=cm_cr_pr_orig_subj 2. TED.com talks, which include links to mp4, zipped mp4 and itunes, e.g., http://www.ted.com/index.php/talks/view/id/51 3. New York Times, which include links to single-page and print versions of articles, e.g., http://www.nytimes.com/2007/12/13/business/13fed.html In particular, I am seeking a solution that can deal with different filetypes (audio vs. video) as well as content length. Let me include part of the original post: There hasn't been much lately regarding the 'alternates' discussion[1]. It seems that in the HTML spec[2], 'alternate' is meant as something the user can choose between, i.e., style sheets[3], and/or something the browser can try and render in a given rank order, i.e., objects[4]. The suggested use of
      for preference and
        for no preference is clever[1]. (this example modified from the wiki entry[1])
        1. MP3
        2. WAV
        3. MOV
        -- Sincerely, Jeff McNeill http://jeffmcneill.com/ On 12/12/07, Andy Mabbett wrote: > In message <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com>, > Jeff McNeill writes > > >There hasn't been much lately regarding the 'alternates' discussion > [...] > >Any thoughts? > > What's the use-case? > > -- > Andy Mabbett > _______________________________________________ From Michael.Smethurst at bbc.co.uk Thu Dec 13 01:27:00 2007 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Dec 13 01:55:30 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> Message-ID: Cc-ing (hopefully) interested bbc parties Hello Andy Long time no hear On 12/12/07 19:02, "Andy Mabbett" wrote: > In message , Michael > Smethurst writes > >> Just to say that hCalendar is used fairly extensively to describe >> broadcasts on bbc.co.uk/programmes > >> Having said that it's not been through accessibility testing yet so it >> might not be for long... > > It will be interesting to know the outcome of that testing, in the light > of mark-up like: > > > 16:03 > > > and the issues raised here: > > I concur wholeheartedly with your concerns. The markup is definitely iffy from both semantic and accessibility angles. Do you have a better suggestion for how to mark up a set of broadcasts without repeatedly repeating the full date(s)? As ever we're happy to receive assistance I'm also looking forward to hearing the accessibility testing results. To the best of my knowledge it's the first time ufs have been used in anger on bbc.co.uk and the bbc semantic markup standards [1] and accessibility standards [2] have nothing to say on the subject Personally i've been pushing for the bbc to adopt rdf-a for adding semantics to html but without operator / promised firefox support for basic functionality (add to address book / add to calendar) a decision was made to stick with ufs for now So I'd be perfectly happy if the accessibility testing said no, no, no and we could get explicit guidance from the bbc standards on the abbr design pattern / backing for rdf-a > > Who's doing it? The markup or the testing? The markup was from Phil Gyford [3] who being both very talented and very clever also expressed doubts. The testing will be done by Gareth Ford Williams [4] We'll let you know how it pans out [1] http://www.bbc.co.uk/guidelines/newmedia/technical/semantic_markup.shtml [2] http://www.bbc.co.uk/guidelines/newmedia/accessibility/ [3] http://www.gyford.com/ [4] gratuitous plug for backstage accessibility podcast: http://backstage.bbc.co.uk/news/archives/2007/12/podcast_accessi.html 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 rob at sanchothefat.com Thu Dec 13 03:02:46 2007 From: rob at sanchothefat.com (Robert O'Rourke) Date: Thu Dec 13 03:03:03 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> Message-ID: <47611156.9030107@sanchothefat.com> Andy Mabbett wrote: > In message , Michael > Smethurst writes > > >> Just to say that hCalendar is used fairly extensively to describe >> broadcasts on bbc.co.uk/programmes here: >> >> http://www.bbc.co.uk/programmes/genres/music >> > > >> http://www.bbc.co.uk/programmes/formats/animation >> > > >> http://www.bbc.co.uk/programmes/b006qpgr/laston >> > > >> Having said that it's not been through accessibility testing yet so it >> might not be for long... >> > > It will be interesting to know the outcome of that testing, in the light > of mark-up like: > > > 16:03 > > > and the issues raised here: > > I know it defeats the object semantically speaking but what are the other arguments against putting the machine-readable date/time in the class attribute and do they outweigh the gain in accessibility? For example, what's wrong with this: 16:03 Since no solution is ideal with the current HTML flavours people use is there any work being done with regard to the new HTML specs like HTML5? A element or data="" attribute for example? -Rob From bhawkeslewis at googlemail.com Thu Dec 13 07:19:30 2007 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Thu Dec 13 07:25:39 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: <47611156.9030107@sanchothefat.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> Message-ID: <47614D82.6000600@googlemail.com> Robert O'Rourke wrote: > I know it defeats the object semantically speaking but what are the > other arguments against putting the machine-readable date/time in the > class attribute and do they outweigh the gain in accessibility? > > For example, what's wrong with this: > > > 16:03 > Leaving aside the immediate question of whether using class to hide data is a good idea: 1. 16:03 isn't an abbreviation for 12 September 2007. That's /additional/ information. So that should be a SPAN not an ABBR. 2. Information in TITLE is hard for humans to access (for example, with just the keyboard, or on an iPhone). So it's best to keep important information, like 12th December 2007, implicit or explicit in the main content. 3. If 12th December 2007 is made implicit or explicit, then the TITLE is superfluous and distracting: http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/ http://www.rnib.org.uk/wacblog/better-connected/better-connected-better-results-top-tips-for-titles/ > Since no solution is ideal with the current HTML flavours people use is > there any work being done with regard to the new HTML specs like HTML5? > A element or data="" attribute for example? Given that the set of data types is potentially infinite, I'd like to see an extensible method for hiding machine-readable data in the next version of HTML. The current HTML5 draft, doesn't have an extensible method, but it does include dedicated TIME and METER elements: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-time http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-meter Caveat: a flaw doomed to irritate historians, scientists, space opera authors, and non-Christians everywhere is that the proposed TIME element cannot represent times before 0 AD or after 9999 AD: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-common1.html#dates The current XHTML2 draft doesn't have an equivalent for TIME and METER, but it does have a general way of hiding machine-readable data, using the content attribute: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content -- Benjamin Hawkes-Lewis From andy at pigsonthewing.org.uk Thu Dec 13 08:51:52 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Dec 13 08:51:54 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> Message-ID: <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> On Thu, December 13, 2007 09:27, Jeff McNeill wrote: > Use cases for alternates could be as follows: [...] Thank you. That explains what "alternates" are; but not how the proposed microformat would be /used/. In other words, what would a user agent *do* with them? -- Andy Mabbett ** via webmail ** From jeff at jeffmcneill.com Thu Dec 13 09:11:14 2007 From: jeff at jeffmcneill.com (Jeff McNeill) Date: Thu Dec 13 09:11:38 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> Message-ID: <519fa62f0712130911w221d3ec6v9b38dbaf1d519478@mail.gmail.com> Hello Microformaters, * A user-agent could at the least identify one or more alternate formats for the current item or a linked item. * It could also identify the order of preference of alternates. * This could be used by microformat-aware search to provide search result links to alternates. * This could also be used to support mirror lists (instead of alternate formats, simply alternate locations), this could then be used by a user agent to download/retrieve by picking from the top of the preferred list or among a list of non-preferred (unordered) locations. * It may be possible for a user-agent to be aware of a format preference in the case of alternate formats or application support, such as preference for certain kinds of media readers, e.g., iTunes itpc:// links vs. mp4 downloads. Let me know if this answers the question. Not quite sure the format/content being looked for in terms of user-agent use. Cheers, -- Sincerely, Jeff McNeill http://jeffmcneill.com/ On 12/13/07, Andy Mabbett wrote: > On Thu, December 13, 2007 09:27, Jeff McNeill wrote: > > > Use cases for alternates could be as follows: > > [...] > > Thank you. That explains what "alternates" are; but not how the proposed > microformat would be /used/. In other words, what would a user agent *do* > with them? > > -- > Andy Mabbett > ** via webmail ** > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From rob at sanchothefat.com Thu Dec 13 09:40:47 2007 From: rob at sanchothefat.com (Robert O'Rourke) Date: Thu Dec 13 09:44:24 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: <47614D82.6000600@googlemail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> Message-ID: <47616E9F.9070600@sanchothefat.com> Benjamin Hawkes-Lewis wrote: > Robert O'Rourke wrote: > >> I know it defeats the object semantically speaking but what are the >> other arguments against putting the machine-readable date/time in the >> class attribute and do they outweigh the gain in accessibility? >> >> For example, what's wrong with this: >> >> >> 16:03 >> > > Leaving aside the immediate question of whether using class to hide > data is a good idea: I understand that microformats are about keeping the data visible but 2007-12-12T16:03:00Z is no good to humans. The data is still visible to machines and as far as I know it's there for the machine's benefit. > > 1. 16:03 isn't an abbreviation for 12 September 2007. That's > /additional/ information. So that should be a SPAN not an ABBR. Sure I understand, it was just an example based on what was in TITLE, so you're saying 16:03 isn't an abbreviation for 2007-12-12T16:03:00Z either?. Ignoring the '12 December 2007' bit would it still be an ABBR do you think? Seems a bit superfluous to treat it as an abbreviation at all if that's the case. Taking the example of a blog post there is a context for date and time so if 16:03 appeared there a human could figure out it was on that day. A machine could work it out from the information in CLASS. It seems like an impossible situation to get right... > > 2. Information in TITLE is hard for humans to access (for example, > with just the keyboard, or on an iPhone). So it's best to keep > important information, like 12th December 2007, implicit or explicit > in the main content. > > 3. If 12th December 2007 is made implicit or explicit, then the TITLE > is superfluous and distracting: > I agree with these points, so basically ABBR is the wrong element in this case because the date/time in full is given or implied. Could it be argued then that the machine-readable date-time belongs in CLASS on a SPAN? >> Since no solution is ideal with the current HTML flavours people use >> is there any work being done with regard to the new HTML specs like >> HTML5? A element or data="" attribute for example? > > Given that the set of data types is potentially infinite, I'd like to > see an extensible method for hiding machine-readable data in the next > version of HTML. > > The current HTML5 draft, doesn't have an extensible method, but it > does include dedicated TIME and METER elements: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-time > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-meter > > > Caveat: a flaw doomed to irritate historians, scientists, space opera > authors, and non-Christians everywhere is that the proposed TIME > element cannot represent times before 0 AD or after 9999 AD: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/section-common1.html#dates > > > The current XHTML2 draft doesn't have an equivalent for TIME and > METER, but it does have a general way of hiding machine-readable data, > using the content attribute: > > http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content The XHTML2 method gets my vote then, unless of course that flaw is worked out. What a palaver... > > -- > Benjamin Hawkes-Lewis > Thankyou for the links and response Benjamin, -Rob From rob at sanchothefat.com Thu Dec 13 09:44:41 2007 From: rob at sanchothefat.com (Robert O'Rourke) Date: Thu Dec 13 09:45:22 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> Message-ID: <47616F89.7060104@sanchothefat.com> Andy Mabbett wrote: > On Thu, December 13, 2007 09:27, Jeff McNeill wrote: > > >> Use cases for alternates could be as follows: >> > > [...] > > Thank you. That explains what "alternates" are; but not how the proposed > microformat would be /used/. In other words, what would a user agent *do* > with them? > Perhaps in the case of a podcast or video blog you could tell your feed-reader what format you prefer and it would grab the right file. That's one possibility but I don't know of anyone who does podcasts/video blogs in multiple formats. From davidjanes at blogmatrix.com Thu Dec 13 10:01:21 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Dec 13 10:01:24 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <47616F89.7060104@sanchothefat.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> <47616F89.7060104@sanchothefat.com> Message-ID: <21e523c20712131001h1e5c5189j9987fd84cabc9db7@mail.gmail.com> On Dec 13, 2007 12:44 PM, Robert O'Rourke wrote: > > Perhaps in the case of a podcast or video blog you could tell your > feed-reader what format you prefer and it would grab the right file. > That's one possibility but I don't know of anyone who does > podcasts/video blogs in multiple formats. > This is exactly why it was created, though the project it was associated with at the time faltered. I think this is more like hItem -- the research is done (I believe) -- and just waiting the day it will be needed elsewhere. I don't particularly think it's worth pursuing on it's own. Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From angus at pobox.com Thu Dec 13 11:32:39 2007 From: angus at pobox.com (Angus McIntyre) Date: Thu Dec 13 11:32:46 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: <47616E9F.9070600@sanchothefat.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47616E9F.9070600@sanchothefat.com> Message-ID: <3456.66.17.182.210.1197574359.squirrel@webmail.nomadcode.com> On Thu, December 13, 2007 12:40 pm, Robert O'Rourke wrote: > ... Could it be argued then that the machine-readable date-time > belongs in CLASS on a SPAN? It looks to me as if ISO-8601 dates would not be valid classnames, due to the presence of colons and '+' signs. However, I may be wrong about that. Even if that isn't the case, I have an aesthetic resistance to using "class" for something that very clearly isn't a class. That seems to me even uglier than using the "title" attribute of "abbr". I'd also wonder about user-agent efficiency: a page with 100 dates would send the agent into its in-memory representation of the stylesheet 100 times to look for a class definition that it will never find. That feels wrong, although I'd need to show that it actually exacted a noticeable performance penalty on some platform for it to be taken seriously as an objection. Using the 'id' of the span is probably out too: if you have simultaneous events, you get non-unique ids in your page. >> Given that the set of data types is potentially infinite, I'd like to >> see an extensible method for hiding machine-readable data in the next >> version of HTML. A 'data' attribute or equivalent might be nice to have. Unfortunately, we can't turn the problem on its head and, instead of looking for exploitable attributes in the current spec, try to find something that would be both machine-parseable and human-friendly to put in our "title" attributes. While you might be able to come up with something in one language that is easy to parse and sounds sane when read out by a screen reader, you'll come unstuck the first time your parser has to read a date in a language it doesn't know. "title" on "abbr" (or "span") looks like the least bad of a set of bad choices. Angus From angus at pobox.com Thu Dec 13 11:40:32 2007 From: angus at pobox.com (Angus McIntyre) Date: Thu Dec 13 11:40:35 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <47616F89.7060104@sanchothefat.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> <47616F89.7060104@sanchothefat.com> Message-ID: <3490.66.17.182.210.1197574832.squirrel@webmail.nomadcode.com> On Thu, December 13, 2007 12:44 pm, Robert O'Rourke wrote: > Perhaps in the case of a podcast or video blog you could tell your > feed-reader what format you prefer and it would grab the right file. > That's one possibility but I don't know of anyone who does > podcasts/video blogs in multiple formats. We do, 'we' being my $DAYJOB at http://blip.tv/. I've actually been following this thread with interest because our pages currently contain a list of the alternate formats available for any given post. Some of our show creators make their episodes available in five or six different formats. Take a look, for example, at: http://blip.tv/file/509978/ In the bottom-right of that page you'll see a list of the different formats available for download. Unless I'm misreading what 'alternates' is supposed to be, that's a real-world example where it could be applied and - because we're microformats enthusiasts - certainly would be. Angus From jeff at jeffmcneill.com Thu Dec 13 13:17:33 2007 From: jeff at jeffmcneill.com (Jeff McNeill) Date: Thu Dec 13 13:17:40 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <3490.66.17.182.210.1197574832.squirrel@webmail.nomadcode.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> <47616F89.7060104@sanchothefat.com> <3490.66.17.182.210.1197574832.squirrel@webmail.nomadcode.com> Message-ID: <519fa62f0712131317x2edb9325w4b676935db4eb220@mail.gmail.com> Aloha, Interesting that alternates was brainstormed in terms of hItem as mentioned previously in the thread, but also could and perhaps should initially apply to citation. If I understand the citation discussion at http://microformats.org/wiki/citation-irc-notes-2006-04-09#Summary an alternate would be a reference and could therefore be a part of the citation discussion. I appreciate the comment that description could be a superset of reference, but need not be determined by the reference (citation) mf. -- Sincerely, Jeff McNeill http://jeffmcneill.com/ On 12/13/07, Angus McIntyre wrote: > On Thu, December 13, 2007 12:44 pm, Robert O'Rourke wrote: > > Perhaps in the case of a podcast or video blog you could tell your > > feed-reader what format you prefer and it would grab the right file. > > That's one possibility but I don't know of anyone who does > > podcasts/video blogs in multiple formats. > > We do, 'we' being my $DAYJOB at http://blip.tv/. > > I've actually been following this thread with interest because our pages > currently contain a list of the alternate formats available for any given > post. Some of our show creators make their episodes available in five or > six different formats. Take a look, for example, at: > > http://blip.tv/file/509978/ > > In the bottom-right of that page you'll see a list of the different > formats available for download. Unless I'm misreading what 'alternates' is > supposed to be, that's a real-world example where it could be applied and > - because we're microformats enthusiasts - certainly would be. > > Angus > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From joshuagay at gmail.com Thu Dec 13 16:57:14 2007 From: joshuagay at gmail.com (Joshua Gay) Date: Thu Dec 13 16:57:20 2007 Subject: [uf-discuss] CSS archive Message-ID: First time here. Hope this is on-topic! Sorry if it is not :-) ##Short version I was thinking that it would be nice to have a page on the Wiki that collects CSS templates for creating and displaying microformats. ##Long version I'm putting together some HTML-forms that people can fill out and produce an hReview. In my case, it's for reviewing educational content. I want people to be able to add a one-line of JavaScript to their site so that they can either have a static-looking form on their site, or a dynamic "div-window pop-up" (call it what you will). I want the form to know that it is ultimately 1) producing a review in the form of an hReview microformat, and 2) it will be aggregated onto other sites. To let people know about Microformats and hReview, I thought it would be neat to put the microformats logo in the corner of the form with a link to microformats.com -- or perhaps linking specifically to the about page for hReview. I thought it would be cool if there was some standard CSS templates for people to use. What do people think of sharing their CSS templates for microformat forms and displays? Does this run contrary to the beautiful, simple, "the semantic web is already here" message that microformats carry? -- that is, bringing in ugly style issues :-) Joshua Gay -- Free Software Foundation [http://fsf.org] Textbook Revolution [http://textbookrevolution.org] One Laptop per Child [http://laptop.org] Free Textbook Project [http://freetextbookproject.org] Transparent Federal Budget [http://transparentfederalbudget.com] From mail at ciaranmcnulty.com Fri Dec 14 01:01:54 2007 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Dec 14 01:02:08 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: <47614D82.6000600@googlemail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> Message-ID: On Dec 13, 2007 3:19 PM, Benjamin Hawkes-Lewis wrote: > Robert O'Rourke wrote: > 1. 16:03 isn't an abbreviation for 12 September 2007. That's > /additional/ information. So that should be a SPAN not an ABBR. I'd disagree with this. 16:03 in the context of your original page *will* refer to 16:03 on a specific day (I'm finding it hard to think of a non-contrived example where it wouldn't) - it's just abbreviated to 16:03. A human would gather that information from context but it's more explicit in the machine-readable version. -Ciaran McNulty From thom at ts0.com Fri Dec 14 02:14:02 2007 From: thom at ts0.com (Thom Shannon) Date: Fri Dec 14 02:14:08 2007 Subject: [uf-discuss] XFN syntax question Message-ID: <4762576A.5010502@ts0.com> I've just installed a new blogging platform, the blogroll supports XFN out of the box which is nice. I just noticed in the source it's writing it like this rel="contact;friend ;met;co-worker" There's no mention of using ; as a seperator in the XFN specs. I just wanted to check I wasn't missing anything. From fberriman at gmail.com Fri Dec 14 02:26:39 2007 From: fberriman at gmail.com (Frances Berriman) Date: Fri Dec 14 02:26:41 2007 Subject: [uf-discuss] XFN syntax question In-Reply-To: <4762576A.5010502@ts0.com> References: <4762576A.5010502@ts0.com> Message-ID: On 14/12/2007, Thom Shannon wrote: > I've just installed a new blogging platform, the blogroll supports XFN > out of the box which is nice. I just noticed in the source it's writing > it like this rel="contact;friend ;met;co-worker" > > There's no mention of using ; as a seperator in the XFN specs. I just > wanted to check I wasn't missing anything. You're right. It oughta be space seperated. Which blogging platform is doing it that way? -- Frances Berriman http://fberriman.com From mail at ciaranmcnulty.com Fri Dec 14 02:34:42 2007 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Dec 14 02:34:47 2007 Subject: [uf-discuss] XFN syntax question In-Reply-To: <4762576A.5010502@ts0.com> References: <4762576A.5010502@ts0.com> Message-ID: On Dec 14, 2007 10:14 AM, Thom Shannon wrote: > I've just installed a new blogging platform, the blogroll supports XFN > out of the box which is nice. I just noticed in the source it's writing > it like this rel="contact;friend ;met;co-worker" > > There's no mention of using ; as a seperator in the XFN specs. I just > wanted to check I wasn't missing anything. XFN just mentions using multiple rel values for complex relationships, and rel values are space-separated so I don't think that is valid XFN. -Ciaran McNulty From fberriman at gmail.com Fri Dec 14 02:43:13 2007 From: fberriman at gmail.com (Frances Berriman) Date: Fri Dec 14 02:43:15 2007 Subject: [uf-discuss] CSS archive In-Reply-To: References: Message-ID: On 14/12/2007, Joshua Gay wrote: > First time here. Hope this is on-topic! Sorry if it is not :-) > > ##Short version > > I was thinking that it would be nice to have a page on the Wiki that > collects CSS templates for creating and displaying microformats. Hi. Well, just to throw an alternative view on this - I might be concerned that supplying CSS templates for microformats might lead people to believe that microformats *must* be written in a very specific way/order. I think you could do this, but with the clear explanation that the mark-up that goes with the CSS (since you'd have to make certain assumptions*) is simply a suggested way of marking up that piece of information. Pitching it more in a way of "these are some ready to go snippets and styles to get you started". Does that make sense? (* ... to make anything particularly pretty for a more complex example like hReview - I guess stuff like making XFN links look a certain way would be easier) -- Frances Berriman http://fberriman.com From fberriman at gmail.com Fri Dec 14 02:44:00 2007 From: fberriman at gmail.com (Frances Berriman) Date: Fri Dec 14 02:44:02 2007 Subject: [uf-discuss] XFN syntax question In-Reply-To: References: <4762576A.5010502@ts0.com> Message-ID: On 14/12/2007, Ciaran McNulty wrote: > On Dec 14, 2007 10:14 AM, Thom Shannon wrote: > > I've just installed a new blogging platform, the blogroll supports XFN > > out of the box which is nice. I just noticed in the source it's writing > > it like this rel="contact;friend ;met;co-worker" > > > > There's no mention of using ; as a seperator in the XFN specs. I just > > wanted to check I wasn't missing anything. > > XFN just mentions using multiple rel values for complex relationships, > and rel values are space-separated so I don't think that is valid XFN. The HTML spec also explicitly states that rel values should be space separated. -- Frances Berriman http://fberriman.com From rob at sanchothefat.com Fri Dec 14 03:46:44 2007 From: rob at sanchothefat.com (Robert O'Rourke) Date: Fri Dec 14 03:47:35 2007 Subject: [uf-discuss] Citation and alternates-brainstorming In-Reply-To: <3490.66.17.182.210.1197574832.squirrel@webmail.nomadcode.com> References: <519fa62f0710261110naec130dmc869426a6062c706@mail.gmail.com> <519fa62f0712130127ref376ai107c9630b6b678fa@mail.gmail.com> <2636.80.249.57.38.1197564712.squirrel@www.gradwell.com> <47616F89.7060104@sanchothefat.com> <3490.66.17.182.210.1197574832.squirrel@webmail.nomadcode.com> Message-ID: <47626D24.9080400@sanchothefat.com> Angus McIntyre wrote: > On Thu, December 13, 2007 12:44 pm, Robert O'Rourke wrote: > >> Perhaps in the case of a podcast or video blog you could tell your >> feed-reader what format you prefer and it would grab the right file. >> That's one possibility but I don't know of anyone who does >> podcasts/video blogs in multiple formats. >> > > We do, 'we' being my $DAYJOB at http://blip.tv/. > > I've actually been following this thread with interest because our pages > currently contain a list of the alternate formats available for any given > post. Some of our show creators make their episodes available in five or > six different formats. Take a look, for example, at: > > http://blip.tv/file/509978/ > > In the bottom-right of that page you'll see a list of the different > formats available for download. Unless I'm misreading what 'alternates' is > supposed to be, that's a real-world example where it could be applied and > - because we're microformats enthusiasts - certainly would be. > > Angus > Nice, do you think you could convince your boss (assuming you're not) to conduct a survey of your users to see what feed-readers they typically use? My money would be on iTunes but I don't know whether a preferred format would be necessary there. What file types can an iPod handle? And does iTunes already give people the option to set a preference? I wonder if this is a case where should be used in the feed, rather than a microformat on the page. If there was no feed and sticking with the example of iTunes we'd have to convince them to let people point it at a web page to parse out the files and the preferred format from the alternates uF... Alternates would also be a good extension for hAtom also. -Rob From tom at tommorris.org Fri Dec 14 08:03:52 2007 From: tom at tommorris.org (Tom Morris) Date: Fri Dec 14 08:03:55 2007 Subject: [uf-discuss] CSS archive In-Reply-To: References: Message-ID: On Dec 14, 2007 10:43 AM, Frances Berriman wrote: > On 14/12/2007, Joshua Gay wrote: > > First time here. Hope this is on-topic! Sorry if it is not :-) > > > > ##Short version > > > > I was thinking that it would be nice to have a page on the Wiki that > > collects CSS templates for creating and displaying microformats. > > Hi. > > Well, just to throw an alternative view on this - I might be concerned > that supplying CSS templates for microformats might lead people to > believe that microformats *must* be written in a very specific > way/order. > > I think you could do this, but with the clear explanation that the > mark-up that goes with the CSS (since you'd have to make certain > assumptions*) is simply a suggested way of marking up that piece of > information. Pitching it more in a way of "these are some ready to go > snippets and styles to get you started". > I think it may make more sense to put up a list of 'interesting' examples in the wild for each microformat - where, for instance, they are being used in interesting, new, innovative or stylish ways. Perhaps a 'microformats gallery' showing uses that are pushing the boundaries of recombining microformats in interesting ways or styling or scripting them in interesting ways. The idea of the original poster is good, but, as you say, it needs to be broader than simply the CSS and styling. The idea of a gallery would be to show authors that through using microformats along with good markup practice, CSS and JavaScript you can do interesting or unexpected things. This is something that John Allsopp's done in the Microformats book. As to how we implement such a gallery, I'm not sure. Examples in the wild pages benefit from being just a big list, where as a gallery may not be the best thing to host on a wiki. Perhaps someone who thinks they have good judgment and taste on these sort of things might want to start one. Maybe we could start with something fun like a "most beautiful hCard" competition. Winner gets a mince pie and some linklove. :) -- Tom Morris http://tommorris.org/ From rob at sanchothefat.com Fri Dec 14 05:15:57 2007 From: rob at sanchothefat.com (Robert O'Rourke) Date: Fri Dec 14 08:20:51 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> Message-ID: <4762820D.8090605@sanchothefat.com> Ciaran McNulty wrote: > On Dec 13, 2007 3:19 PM, Benjamin Hawkes-Lewis > wrote: > >> Robert O'Rourke wrote: >> 1. 16:03 isn't an abbreviation for 12 September 2007. That's >> /additional/ information. So that should be a SPAN not an ABBR. >> > > That was Benjamin's comment not mine. I suggested a human readable TITLE including the full date aswell as 16:03 and putting the machine-readable date format into the CLASS attribute but that was also a bad idea (too much accessibility etc...). That said I think it's better than putting the machine readable date/time format in the TITLE. Surely the parsers should be better able to figure that out from the human readable date and time and leave 2007-12-12T16:03:00Z out altogether? I know of at least one Perl module that does this [1] > I'd disagree with this. 16:03 in the context of your original page > *will* refer to 16:03 on a specific day (I'm finding it hard to think > of a non-contrived example where it wouldn't) - it's just abbreviated > to 16:03. A human would gather that information from context but it's > more explicit in the machine-readable version. > > That was exactly my point when I wrote my example down. If putting machine-readable information in TITLE isn't good then perhaps it was a reasonable alternative re. accessibility, but of course there are many arguments either way. To quote Angus: > "title" on "abbr" (or "span") looks like the least bad of a set of bad > choices. [1] http://search.cpan.org/~gbarr/TimeDate-1.16/lib/Date/Parse.pm From bhawkeslewis at googlemail.com Fri Dec 14 06:06:37 2007 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Fri Dec 14 08:51:38 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> Message-ID: <47628DED.9010506@googlemail.com> Ciaran McNulty wrote: > On Dec 13, 2007 3:19 PM, Benjamin Hawkes-Lewis > wrote: >> Robert O'Rourke wrote: >> 1. 16:03 isn't an abbreviation for 12 September 2007. That's >> /additional/ information. So that should be a SPAN not an ABBR. > > I'd disagree with this. 16:03 in the context of your original page > *will* refer to 16:03 on a specific day (I'm finding it hard to think > of a non-contrived example where it wouldn't) - it's just abbreviated > to 16:03. A human would gather that information from context but it's > more explicit in the machine-readable version. The expansions of normal abbreviations are intended for confused humans, not (just) baffled machines. You can throw normal abbreviations into www.acronymfinder.com and generally one of the results will be applicable in context. If you throw 16:03 into www.acronymfinder.com, you will not get back 12 September 2007. That is, normal abbreviations (Mr., Dr., ibid., etc.) are no more dependent on context than ordinary words. What you're really saying is that ABBR should be used to make /contexts/ explicit in the TITLE attribute, for the benefit of machines. I think that's a radical deviation from expanding an abbreviation for the benefit of humans and machines. Given the HTML 4.01 specification: http://www.w3.org/TR/html401/struct/text.html#h-9.2.1 http://www.w3.org/TR/html401/struct/global.html#adef-title I think all of the following would be misuses of ABBR and TITLE: | Combien d'?ufs ai-je vendre? J'ai vendu | 45 aujourd'hui. | Combien d'?ufs ai-je vendre? J'ai vendu 45 aujourd'hui. | Combien d'?ufs ai-je vendre? J'ai vendu 45 aujourd'hui. | Combien d'?ufs ai-je vendre? J'ai vendu | 45 aujourd'hui. | Combien d'?ufs ai-je vendre? J'ai vendu 45 | aujourd'hui. "16:03" could be re-expressed as "3 minutes past 4pm". It's not obvious that "16:03" is an /abbreviation/ of "3 minutes past 4pm". For one thing, the 12-hour clock is not an expansion of the 24-hour clock: they are equivalents. For another thing, I'd say it's more of a common symbolic representation. "4" wouldn't normally be called an abbreviation of "four": it's just a symbol. (Some symbols are also arguably abbreviations, at least in origin, like cm, but this wouldn't generally be said of 4.) -- Benjamin Hawkes-Lewis From andy at pigsonthewing.org.uk Fri Dec 14 10:45:57 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Dec 14 10:47:39 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> Message-ID: <6QIkdmPl9sYHFwAd@pigsonthewing.org.uk> In message , Ciaran McNulty writes >On Dec 13, 2007 3:19 PM, Benjamin Hawkes-Lewis > wrote: >> 1. 16:03 isn't an abbreviation for 12 September 2007. That's >> /additional/ information. So that should be a SPAN not an ABBR. > >I'd disagree with this. 16:03 in the context of your original page >*will* refer to 16:03 on a specific day (I'm finding it hard to think >of a non-contrived example where it wouldn't) - it's just abbreviated >to 16:03. A human would gather that information from context but it's >more explicit in the machine-readable version. That's a reasonable argument. It's not reasonable, though, to argue (which you're not, at least not here, but which others seem to be) that 16:03 is an abbreviation of what a human (geeks aside) would gather from the context as being "20070912T16:03:00+01:00" (or whatever). -- Andy Mabbett From lists at ben-ward.co.uk Fri Dec 14 11:21:54 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Fri Dec 14 11:22:04 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <47628DED.9010506@googlemail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> Message-ID: <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> On 14 Dec 2007, at 14:06, Benjamin Hawkes-Lewis wrote: > I think all of the following would be misuses of ABBR and TITLE: > > | Combien d'?ufs ai-je vendre? J'ai vendu > | 45 aujourd'hui. > > | Combien d'?ufs ai-je vendre? J'ai vendu 45 aujourd'hui. > > | Combien d'?ufs ai-je vendre? J'ai vendu 45 aujourd'hui. > > | Combien d'?ufs ai-je vendre? J'ai vendu > | 45 aujourd'hui. > > | Combien d'?ufs ai-je vendre? J'ai vendu | title="sales:a464Z37;q45dt2007122007">45 > | aujourd'hui. > > "16:03" could be re-expressed as "3 minutes past 4pm". It's not > obvious that "16:03" is an /abbreviation/ of "3 minutes past 4pm". > For one thing, the 12-hour clock is not an expansion of the 24-hour > clock: they are equivalents. For another thing, I'd say it's more > of a common symbolic representation. "4" wouldn't normally be > called an abbreviation of "four": it's just a symbol. (Some symbols > are also arguably abbreviations, at least in origin, like cm, but > this wouldn't generally be said of 4.) Agreed. I'll repost something I put into the GEO thread last week. It's quoting directly from the HTML4 specification. This doesn't actually need to have any concern with accessibility, or assistive technology tools. Frankly, the difficulty in getting solid tests from such tools makes that line of argument less attractive in itself. But what has to be a fundamental baseline in our implementation of optimisation patterns in microformats is the HTML specification we are building on top of. We *do not* have the authority to disobey the spec. We may interpret it _more strictly_ perhaps, but we may not _relax_ any of the definitions it provides. Otherwise we have no leg to stand on regarding the effect our code has on _any_ consuming tool. I said this: > > ?The content of the ABBR and ACRONYM elements specifies the > abbreviated expression itself, as it > > would normally appear in running text. The title attribute of > these elements may be used to provide > > the full or expanded form of the expression.? > For emphasis again: > > ?as it would normally appear in running text.? I know there are lots of concerns about the effect of the ABBR pattern on assistive technology tools. I know there are reports of problems and negative impact on user experience. Getting evidence is proving hard because the sheer number of variables in a real assistive technology user's configuration is much larger than for visual desktop browsers. It actually doesn't matter, because the ABBR pattern is being mis-used at a more fundamental level. First, some happy news. Here's the ABBR pattern being used validly and correctly in hCard: > UK There is an argument that the ISO timestamp format is an expansion of a human formatted date (?Thursday, September 23rd?). I personally disagree, but it was accepted at the time. But since then, the use of the pattern has expanded without the same concern for the HTML spec. ?One hour ago? is NOT ever an abbreviation of a timestamp. ?last week? IS NOT an abbreviation of a timestamp. ?London? IS NOT an abbreviation of a set of co-ordinates and ?3:23? IS NOT an abbreviation of the string ?PT3M23S? (hAudio). In all of those cases they are ?alternative representations?, or ?expansions? or perhaps ?precisions?. They ARE NOT abbreviations and they are in clear conflict with the HTML spec which states the TITLE attribute of ABBR must be ?the abbreviated expression itself, as it would normally appear in running text?. Sorry, but the ball got dropped on this, and people have been treating the ABBR-pattern as a handy pattern first and HTML second. That is the wrong way around. So we have a problem. We now have multiple use cases where it is necessary for publishers to include precise machine data alongside human legible descriptions. They are rarely real abbreviations. I am going to ask that we better define the problem. That we follow up the demand for a better pattern (regardless of whether your personal motivation is following the spec or assistive technology). I'd like to ask that people stop jumping straight in with ideas for alternative mark-up, ways of kludging the existing practice into different elements or attributes. Follow the process. We need to fully define the problem: We need a list of which microformat properties _require_ the facility for precise representations. They don't all need it, maybe we just need something that certain properties may opt into, rather than something that covers all microformats properties. That's what we need to determine. From there, we can move on how to integrate the data back into mark-up. Thank you, Ben From martin at weborganics.co.uk Fri Dec 14 12:19:56 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Dec 14 12:18:07 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> Message-ID: <1197663596.24955.9.camel@localhost.localdomain> On Fri, 2007-12-14 at 19:21 +0000, Ben Ward wrote: > ?3:23? IS NOT an > abbreviation of the string ?PT3M23S? (hAudio). A couple of us involved in the brainstorming and after, Myself and Andy I think recommended that the duration class should just be expressed as 3:23 Its enough for hAudio I think and doesn't violate the abbr pattern as the current spec tentatively does. Thanks Martin From pmw57 at xtra.co.nz Fri Dec 14 13:13:17 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Dec 14 13:37:24 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <1197663596.24955.9.camel@localhost.localdomain> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> Message-ID: <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> On Dec 15, 2007 9:19 AM, Martin McEvoy wrote: > On Fri, 2007-12-14 at 19:21 +0000, Ben Ward wrote: > > '3:23' IS NOT an > > abbreviation of the string 'PT3M23S' (hAudio). I think you're right. It should be P3M23S instead. > A couple of us involved in the brainstorming and after, Myself and Andy > I think recommended that the duration class should just be expressed as > > 3:23 > > Its enough for hAudio I think and doesn't violate the abbr pattern as > the current spec tentatively does. Will you be contesting the date pattern as well? If the date pattern is acceptable then the time pattern is directly acceptable as well through the very same standards. From tantek at cs.stanford.edu Fri Dec 14 15:07:47 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Dec 14 15:05:33 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> Message-ID: On 12/14/07 1:13 PM, "Paul Wilkins" wrote: > Will you be contesting the date pattern as well? If the date pattern > is acceptable then the time pattern is directly acceptable as well > through the very same standards. Not necessarily. In fact, it has been reasonably hypothesized that YYYY-MM-DD is the most cross-cultural, cross-ability, cross-language accessible / readable / understandable date format (in comparison to two digit years, named months, or randomly ordered year month day as opposed to numerically significant ordering) and thus is actually desirable in a global (e.g. WORLD-wide-web) context. Times have not been subject to the same analysis yet. Tantek From martin at weborganics.co.uk Fri Dec 14 15:18:30 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Dec 14 15:16:39 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> Message-ID: <1197674310.3096.15.camel@localhost.localdomain> On Sat, 2007-12-15 at 10:13 +1300, Paul Wilkins wrote: > On Dec 15, 2007 9:19 AM, Martin McEvoy wrote: > > On Fri, 2007-12-14 at 19:21 +0000, Ben Ward wrote: > > > '3:23' IS NOT an > > > abbreviation of the string 'PT3M23S' (hAudio). > > I think you're right. It should be P3M23S instead. I dont think thats its possible to drop the *T* you could perhaps do PT3:23 ? which seems more accurate > > > A couple of us involved in the brainstorming and after, Myself and Andy > > I think recommended that the duration class should just be expressed as > > > > 3:23 > > > > Its enough for hAudio I think and doesn't violate the abbr pattern as > > the current spec tentatively does. > > Will you be contesting the date pattern as well? If the date pattern > is acceptable then the time pattern is directly acceptable as well > through the very same standards. No I do not have enough wisdom to say what is right or wrong. I do NOT however believe that machine data should be displayed in a people area such as @title, I think machine data can be stored elsewhere in a document such as in the in a list of 's or 's Thanks Martin > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From pmw57 at xtra.co.nz Fri Dec 14 15:33:58 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Dec 14 15:34:03 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <1197674310.3096.15.camel@localhost.localdomain> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> <1197674310.3096.15.camel@localhost.localdomain> Message-ID: <18050cf90712141533s5467735cw98fdc0cc7d502700@mail.gmail.com> On Dec 15, 2007 12:18 PM, Martin McEvoy wrote: > On Sat, 2007-12-15 at 10:13 +1300, Paul Wilkins wrote: > > I think you're right. It should be P3M23S instead. > > I dont think thats its possible to drop the *T* You're right, the T has to be there to resolve any ambiguity between month and minute. PT3M23S is ISO 8601 notation for 3 minutes and 23 seconds. > you could perhaps do PT3:23 ? which seems more accurate Then it won't be able to be parsed as an actual time. > No I do not have enough wisdom to say what is right or wrong. > I do NOT however believe that machine data should be displayed in a > people area such as @title, I think machine data can be stored elsewhere > in a document such as in the in a list of 's or 's The data format is machine data, as are geo-coordinates as well. The machine data has to remain with the human data so that discrepancies between the two aren't allowed to occur. When thinking about other time formats, consider how 3 seconds would be marked up, or even days and weeks. -- Paul Wilkins From martin at weborganics.co.uk Fri Dec 14 15:55:54 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Dec 14 15:54:03 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <1197674310.3096.15.camel@localhost.localdomain> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> <1197674310.3096.15.camel@localhost.localdomain> Message-ID: <1197676554.3609.9.camel@localhost.localdomain> On Fri, 2007-12-14 at 23:18 +0000, Martin McEvoy wrote: > I do NOT however believe that machine data should be displayed in a > people area such as @title, I think machine data can be stored > elsewhere > in a document such as in the in a list of 's or 's No but seriously, with my web designer hat on if you are concerned about accessibility issues or abuse of the abbr pattern this is something worth thinking about. 3m 23s title distraction. I don't think there is any abuse of the abbr design pattern in the above example and it keeps machine data out of peoples faces. Thanks Martin From martin at weborganics.co.uk Fri Dec 14 16:21:41 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Dec 14 16:19:50 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <18050cf90712141533s5467735cw98fdc0cc7d502700@mail.gmail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> <1197674310.3096.15.camel@localhost.localdomain> <18050cf90712141533s5467735cw98fdc0cc7d502700@mail.gmail.com> Message-ID: <1197678101.3609.24.camel@localhost.localdomain> On Sat, 2007-12-15 at 12:33 +1300, Paul Wilkins wrote: > On Dec 15, 2007 12:18 PM, Martin McEvoy wrote: > > On Sat, 2007-12-15 at 10:13 +1300, Paul Wilkins wrote: > > > I think you're right. It should be P3M23S instead. > > > > I dont think thats its possible to drop the *T* > > You're right, the T has to be there to resolve any ambiguity between > month and minute. > > PT3M23S is ISO 8601 notation for 3 minutes and 23 seconds. > > > you could perhaps do PT3:23 ? which seems more accurate > > Then it won't be able to be parsed as an actual time. hmm are you sure? 3:23 is expressed as whole plus a decimal fraction * http://en.wikipedia.org/wiki/ISO_8601 > > > > > No I do not have enough wisdom to say what is right or wrong. > > I do NOT however believe that machine data should be displayed in a > > people area such as @title, I think machine data can be stored elsewhere > > in a document such as in the in a list of 's or 's > > The data format is machine data, as are geo-coordinates as well. > The machine data has to remain with the human data so that > discrepancies between the two aren't allowed to occur. > > When thinking about other time formats, consider how 3 seconds would > be marked up, or even days and weeks. "PT1M" 1 min "PT00:03M" 3 seconds decimal fraction "PT3S" 3 seconds "P0001-03-22T12:33:00" 1 year 3 months 22 days 12 hours 33 minutes and zero seconds. Thanks Martin > From pmw57 at xtra.co.nz Fri Dec 14 16:36:54 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Dec 14 17:05:08 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <1197678101.3609.24.camel@localhost.localdomain> References: <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> <1197674310.3096.15.camel@localhost.localdomain> <18050cf90712141533s5467735cw98fdc0cc7d502700@mail.gmail.com> <1197678101.3609.24.camel@localhost.localdomain> Message-ID: <18050cf90712141636u7e646e20v6b3198603869f5e5@mail.gmail.com> On Dec 15, 2007 1:21 PM, Martin McEvoy wrote: > On Sat, 2007-12-15 at 12:33 +1300, Paul Wilkins wrote: > > On Dec 15, 2007 12:18 PM, Martin McEvoy wrote: > > > you could perhaps do PT3:23 ? which seems more accurate > > Then it won't be able to be parsed as an actual time. > > hmm are you sure? 3:23 is expressed as whole plus a decimal fraction That's if you use a comma or a fullstop. With the full colon it's interpreted as hours and minutes. [QUOTE] It is also acceptable to omit elements to reduce precision. [hh]:[mm], [hh][mm] and [hh] are all used. Decimal fractions may also be used with any of the three time elements. These are indicated by using the decimal point (either a comma (which is preferred ISO 31) or dot). A fraction may only refer to the most precise component of a time representation. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5" or "1430,5". [/QUOTE] -- Paul Wilkins From pmw57 at xtra.co.nz Fri Dec 14 17:27:30 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Fri Dec 14 17:33:47 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <18050cf90712141636u7e646e20v6b3198603869f5e5@mail.gmail.com> References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> <1197674310.3096.15.camel@localhost.localdomain> <18050cf90712141533s5467735cw98fdc0cc7d502700@mail.gmail.com> <1197678101.3609.24.camel@localhost.localdomain> <18050cf90712141636u7e646e20v6b3198603869f5e5@mail.gmail.com> Message-ID: <18050cf90712141727w19f5a9b8k7f2c6030ff70e01a@mail.gmail.com> On Dec 15, 2007 1:36 PM, Paul Wilkins wrote: > On Dec 15, 2007 1:21 PM, Martin McEvoy wrote: > > hmm are you sure? 3:23 is expressed as whole plus a decimal fraction > > That's if you use a comma or a fullstop. With the full colon it's > interpreted as hours and minutes. > [QUOTE] > It is also acceptable to omit elements to reduce precision. [hh]:[mm], > [hh][mm] and [hh] are all used. > > Decimal fractions may also be used with any of the three time > elements. These are indicated by using the decimal point (either a > comma (which is preferred ISO 31) or dot). A fraction may only refer > to the most precise component of a time representation. To denote "14 > hours, 30 and one half minutes", do not include a seconds figure. > Represent it as "14:30,5" or "1430,5". > [/QUOTE] The least that could be got away with is 00:03:23, at which point it would be a toss up between that or PT3M23S Both of the above formats are valid and should be accepted by parsers as a part of the ISO 8601 time/date format. Issues when people markup using the first example are that they are tempted to leave out the hours part and put in 03:23 or even just 3:23, and are left puzzling about why it's interpreted as 3 hours 23 minutes. Issues with the second format is that the abbr tag is in danger of blowing up from excessive stretching of its semantic meaning. -- Paul Wilkins From Scott at randomchaos.com Fri Dec 14 17:40:15 2007 From: Scott at randomchaos.com (Scott Reynen) Date: Fri Dec 14 17:40:26 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> Message-ID: <9961CE9D-E1D6-43F3-A0E0-6AA82BC3A339@randomchaos.com> On Dec 14, 2007, at 12:21 PM, Ben Ward wrote: > I am going to ask that we better define the problem. That we follow > up the demand for a better pattern (regardless of whether your > personal motivation is following the spec or assistive technology). > I'd like to ask that people stop jumping straight in with ideas for > alternative mark-up, ways of kludging the existing practice into > different elements or attributes. Follow the process. We need to > fully define the problem: We need a list of which microformat > properties _require_ the facility for precise representations. They > don't all need it I think we should follow Ben's suggestion here. We've already drifted into discussing solutions that are completely irrelevant to the actual problems we're seeking to solve (last I checked, there were no month- long songs in the hAudio examples). It seems to me "3:23" is already machine-readable, so I think we made a mistake in looking for an alternate machine-readable way to represent that. Rather than trying to fit it into the full complexity of ISO 8601, much of which is far outside the scope of this specific problem, I suggest we simply define the trivial process for reading a duration in that commonly published format. We may not be able to remove the need for the pattern altogether, but identifying which properties actually require alternate machine-readable representations will at least help focus potential solutions. Peace, Scott From tantek at cs.stanford.edu Fri Dec 14 16:23:36 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Dec 14 18:31:32 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <1197676554.3609.9.camel@localhost.localdomain> Message-ID: On 12/14/07 3:55 PM, "Martin McEvoy" wrote: > On Fri, 2007-12-14 at 23:18 +0000, Martin McEvoy wrote: >> I do NOT however believe that machine data should be displayed in a >> people area such as @title, I think machine data can be stored >> elsewhere >> in a document such as in the in a list of 's or 's This is an anti-pattern. Disconnecting data (or meta-data, whatever you prefer to call it) from its context inevitably leads to corruption, and loss of fidelity. Meta keywords rotted for example. One person writes the template with the head and link and meta, and another puts the content in the page, etc. etc. > No but seriously, with my web designer hat on if you are concerned about > accessibility issues or abuse of the abbr pattern this is something > worth thinking about. > > title="three minutes twenty three seconds"> > 3m 23s > > > title distraction. > > I don't think there is any abuse of the abbr design pattern in the above > example and it keeps machine data out of peoples faces. Thanks Martin, this is an excellent example. Tantek From mail at ciaranmcnulty.com Sat Dec 15 02:03:59 2007 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Sat Dec 15 02:04:03 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: <6QIkdmPl9sYHFwAd@pigsonthewing.org.uk> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <6QIkdmPl9sYHFwAd@pigsonthewing.org.uk> Message-ID: On Dec 14, 2007 6:45 PM, Andy Mabbett wrote: > That's a reasonable argument. It's not reasonable, though, to argue > (which you're not, at least not here, but which others seem to be) that > 16:03 is an abbreviation of what a human (geeks aside) would gather from > the context as being "20070912T16:03:00+01:00" (or whatever). Well, I think a human would know from context that it was an abbreviation for 16:03 on 9th Dec 2007, and would know what time zone we were talking about, which is all the info in that ISO date. I do agree that ISO dates are often completely unreadable and we should continue to explore alternatives, I've not seen on that makes more sense than abbr@title yet as I am somewhat against the idea of hiding it in title attributes on arbitrary elements. -Ciaran McNulty From mail at ciaranmcnulty.com Sat Dec 15 02:08:50 2007 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Sat Dec 15 02:08:56 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <9961CE9D-E1D6-43F3-A0E0-6AA82BC3A339@randomchaos.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <9961CE9D-E1D6-43F3-A0E0-6AA82BC3A339@randomchaos.com> Message-ID: On Dec 15, 2007 1:40 AM, Scott Reynen wrote: > It seems to me "3:23" is already > machine-readable Does 3:23 mean 3 mins 23 seconds, or 3 hours 23 mins, or 23 minutes past three o'clock? ;-) -Ciaran McNulty From andy at pigsonthewing.org.uk Sat Dec 15 02:35:19 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 15 02:37:18 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <18050cf90712141727w19f5a9b8k7f2c6030ff70e01a@mail.gmail.com> References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> <1197674310.3096.15.camel@localhost.localdomain> <18050cf90712141533s5467735cw98fdc0cc7d502700@mail.gmail.com> <1197678101.3609.24.camel@localhost.localdomain> <18050cf90712141636u7e646e20v6b3198603869f5e5@mail.gmail.com> <18050cf90712141727w19f5a9b8k7f2c6030ff70e01a@mail.gmail.com> Message-ID: In message <18050cf90712141727w19f5a9b8k7f2c6030ff70e01a@mail.gmail.com>, Paul Wilkins writes >The least that could be got away with is 00:03:23, at which point it >would be a toss up between that or PT3M23S > >Both of the above formats are valid and should be accepted by parsers >as a part of the ISO 8601 time/date format. Only if the microformat in question is specified as using ISO 8601. That may be the best thing to do, but we shouldn't forget that it's not the only option. -- Andy Mabbett From martin at weborganics.co.uk Sat Dec 15 02:43:46 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Dec 15 02:41:57 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <18050cf90712141636u7e646e20v6b3198603869f5e5@mail.gmail.com> References: <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <1197663596.24955.9.camel@localhost.localdomain> <18050cf90712141313o75871ad8x97565c7af0c29753@mail.gmail.com> <1197674310.3096.15.camel@localhost.localdomain> <18050cf90712141533s5467735cw98fdc0cc7d502700@mail.gmail.com> <1197678101.3609.24.camel@localhost.localdomain> <18050cf90712141636u7e646e20v6b3198603869f5e5@mail.gmail.com> Message-ID: <1197715426.7261.0.camel@localhost.localdomain> On Sat, 2007-12-15 at 13:36 +1300, Paul Wilkins wrote: > On Dec 15, 2007 1:21 PM, Martin McEvoy wrote: > > On Sat, 2007-12-15 at 12:33 +1300, Paul Wilkins wrote: > > > On Dec 15, 2007 12:18 PM, Martin McEvoy wrote: > > > > you could perhaps do PT3:23 ? which seems more accurate > > > Then it won't be able to be parsed as an actual time. > > > > hmm are you sure? 3:23 is expressed as whole plus a decimal fraction > > That's if you use a comma or a fullstop. With the full colon it's > interpreted as hours and minutes. > [QUOTE] You are correct thank you :) > It is also acceptable to omit elements to reduce precision. [hh]:[mm], > [hh][mm] and [hh] are all used. > > Decimal fractions may also be used with any of the three time > elements. These are indicated by using the decimal point (either a > comma (which is preferred ISO 31) or dot). A fraction may only refer > to the most precise component of a time representation. To denote "14 > hours, 30 and one half minutes", do not include a seconds figure. > Represent it as "14:30,5" or "1430,5". > [/QUOTE] > From andy at pigsonthewing.org.uk Sat Dec 15 02:45:52 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 15 02:47:15 2007 Subject: [uf-discuss] Develop reusable solutions )was: Precise Expansion Patterns) In-Reply-To: <9961CE9D-E1D6-43F3-A0E0-6AA82BC3A339@randomchaos.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <9961CE9D-E1D6-43F3-A0E0-6AA82BC3A339@randomchaos.com> Message-ID: In message <9961CE9D-E1D6-43F3-A0E0-6AA82BC3A339@randomchaos.com>, Scott Reynen writes >On Dec 14, 2007, at 12:21 PM, Ben Ward wrote: > >> I am going to ask that we better define the problem. That we follow >>up the demand for a better pattern (regardless of whether your >>personal motivation is following the spec or assistive technology). >>I'd like to ask that people stop jumping straight in with ideas for >>alternative mark-up, ways of kludging the existing practice into >>different elements or attributes. Follow the process. We need to fully >>define the problem: We need a list of which microformat properties >>_require_ the facility for precise representations. They don't all need it > > >I think we should follow Ben's suggestion here. We've already drifted >into discussing solutions that are completely irrelevant to the actual >problems we're seeking to solve (last I checked, there were no month- >long songs in the hAudio examples). It's sensible to address the issue of how to express duration - be that in seconds or months, or even years - in a way which can be reused in any microformat, rather than developing a solution which works (in minutes) for one microformat, but may not work (in months, or whatever) in another. This is a principle which, I feel, should apply to any discussion of how to represent any other data items also. That way, when we come to create another microformat using duration, or whatever, we simply reuse the existing solution, rather than having the same debate again; or creating a different solution, which will confuse publishers and make automating publication and parsing more complex. I'd go so far as to say that this should be one of the "microformat principles". In any case, there are pieces of music that last 1 minute 30 seconds (which may be published as 1:30) and others which last one hour and thirty minutes (which may also be published as 1:30). -- Andy Mabbett From andy at pigsonthewing.org.uk Sat Dec 15 02:48:23 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 15 02:49:53 2007 Subject: [uf-discuss] Hcalendar in bbc.co.uk/programmes In-Reply-To: References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <6QIkdmPl9sYHFwAd@pigsonthewing.org.uk> Message-ID: In message , Ciaran McNulty writes >On Dec 14, 2007 6:45 PM, Andy Mabbett >wrote: >> That's a reasonable argument. It's not reasonable, though, to argue >> (which you're not, at least not here, but which others seem to be) that >> 16:03 is an abbreviation of what a human (geeks aside) would gather from >> the context as being "20070912T16:03:00+01:00" (or whatever). > > >Well, I think a human would know from context that it was an >abbreviation for 16:03 on 9th Dec 2007, and would know what time zone >we were talking about, That's the point which I was describing as "a reasonable argument". >which is all the info in that ISO date. It may be in the ISO date, but the ISO date is not how an ordinary person would conceptualise that information. -- Andy Mabbett From martin at weborganics.co.uk Sat Dec 15 02:53:19 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Dec 15 02:51:32 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: References: Message-ID: <1197715999.7261.9.camel@localhost.localdomain> On Fri, 2007-12-14 at 16:23 -0800, Tantek =?ISO-8859-1?B?xw==?=elik wrote: > On 12/14/07 3:55 PM, "Martin McEvoy" wrote: > > > On Fri, 2007-12-14 at 23:18 +0000, Martin McEvoy wrote: > >> I do NOT however believe that machine data should be displayed in a > >> people area such as @title, I think machine data can be stored > >> elsewhere > >> in a document such as in the in a list of 's or 's > > This is an anti-pattern. I know you are correct, sorry that was just trying to make people think a little outside the box :) get the flow of conversation going. > > Disconnecting data (or meta-data, whatever you prefer to call it) from its > context inevitably leads to corruption, and loss of fidelity. Meta keywords > rotted for example. One person writes the template with the head and link > and meta, and another puts the content in the page, etc. etc. > > > > No but seriously, with my web designer hat on if you are concerned about > > accessibility issues or abuse of the abbr pattern this is something > > worth thinking about. > > > > > title="three minutes twenty three seconds"> > > 3m 23s > > > > > > title distraction. > > > > I don't think there is any abuse of the abbr design pattern in the above > > example and it keeps machine data out of peoples faces. > > Thanks Martin, this is an excellent example. you're welcome :) Martin > > Tantek > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From pmw57 at xtra.co.nz Sat Dec 15 04:32:59 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sat Dec 15 04:33:03 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> Message-ID: <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> On Dec 15, 2007 8:21 AM, Ben Ward wrote: > Agreed. I'll repost something I put into the GEO thread last week. > It's quoting directly from the HTML4 specification. This doesn't > actually need to have any concern with accessibility, or assistive > technology tools. Frankly, the difficulty in getting solid tests from > such tools makes that line of argument less attractive in itself. But > what has to be a fundamental baseline in our implementation of > optimisation patterns in microformats is the HTML specification we > are building on top of. We *do not* have the authority to disobey the > spec. We may interpret it _more strictly_ perhaps, but we may not > _relax_ any of the definitions it provides. Otherwise we have no leg > to stand on regarding the effect our code has on _any_ consuming tool. I agree, on the proviso that we take into account redefinitions from HTML5 and XHTML 2.0, for in several cases they have provided a greater understanding of the intention than the earlier HTML4 spec thought to provide. > 'One hour ago' is NOT ever an abbreviation of a timestamp. 'last > week' IS NOT an abbreviation of a timestamp. 'London' IS NOT an > abbreviation of a set of co-ordinates and '3:23' IS NOT an > abbreviation of the string 'PT3M23S' (hAudio). In all of those cases > they are 'alternative representations', or 'expansions' or perhaps > 'precisions'. They ARE NOT abbreviations and they are in clear > conflict with the HTML spec which states the TITLE attribute of ABBR > must be 'the abbreviated expression itself, as it would normally > appear in running text'. Sorry, but the ball got dropped on this, and > people have been treating the ABBR-pattern as a handy pattern first > and HTML second. That is the wrong way around. I have to agree here. > So we have a problem. We now have multiple use cases where it is > necessary for publishers to include precise machine data alongside > human legible descriptions. They are rarely real abbreviations. > > I am going to ask that we better define the problem. That we follow > up the demand for a better pattern (regardless of whether your > personal motivation is following the spec or assistive technology). > I'd like to ask that people stop jumping straight in with ideas for > alternative mark-up, ways of kludging the existing practice into > different elements or attributes. Follow the process. We need to > fully define the problem: We need a list of which microformat > properties _require_ the facility for precise representations. They > don't all need it, maybe we just need something that certain > properties may opt into, rather than something that covers all > microformats properties. That's what we need to determine. From > there, we can move on how to integrate the data back into mark-up. The hAudio time should be denoted in seconds. If 3:23 is given it's to be seen as three minutes and twenty two seconds. If hours are needed it should be 1:3:23 (0 prefix optional) to denote 1 hour three minutes and twenty two seconds. This way the hAudio standard can work without needing to modify the text, the abbr pattern isn't required and everybody can go home and sleep restfully for the night. > Thank you, I concur. -- Paul Wilkins From bhawkeslewis at googlemail.com Sat Dec 15 05:11:22 2007 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sat Dec 15 05:11:28 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> Message-ID: <4763D27A.4030504@googlemail.com> Paul Wilkins wrote: > On Dec 15, 2007 8:21 AM, Ben Ward wrote: >> Agreed. I'll repost something I put into the GEO thread last week. >> It's quoting directly from the HTML4 specification. This doesn't >> actually need to have any concern with accessibility, or assistive >> technology tools. Frankly, the difficulty in getting solid tests from >> such tools makes that line of argument less attractive in itself. But >> what has to be a fundamental baseline in our implementation of >> optimisation patterns in microformats is the HTML specification we >> are building on top of. We *do not* have the authority to disobey the >> spec. We may interpret it _more strictly_ perhaps, but we may not >> _relax_ any of the definitions it provides. Otherwise we have no leg >> to stand on regarding the effect our code has on _any_ consuming tool. > > I agree, on the proviso that we take into account redefinitions from > HTML5 and XHTML 2.0, for in several cases they have provided a greater > understanding of the intention than the earlier HTML4 spec thought to > provide. Why would we need to take what HTML5 and XHTML 2.0 (currently) say into account? In cases where HTML5 and XHTML 2.0 purport to interpret the HTML 4.01 specification, it should be possible to verify such claims independently. Those drafts have no generalizable authority over the meaning of HTML 4.01. Indeed, the current WHATWG proposal is to define a specification for conforming user agents to deal with pre-HTML5 documents the same way as explicitly HTML5 documents, such that it would be impossible to create a user agent conforming to both HTML 4.01 and HTML5. As parts of HTML 5 and XHTML 2.0 become stable enough for experimental use, I think it would be useful to think about: 1. How to express microformat patterns using "redefinitions" (and new features) in those drafts. 2. What additional clarifications or features would benefit the microformats community. I don't think it benefits anyone to start authoring HTML 4.01 (a fixed standard) as though it were HTML5 or XHTML 2.0 (moving targets heavily influenced by cowpaths created by the microformats community). -- Benjamin Hawkes-Lewis From scott at randomchaos.com Sat Dec 15 06:53:14 2007 From: scott at randomchaos.com (Scott Reynen) Date: Sat Dec 15 06:53:26 2007 Subject: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes) In-Reply-To: References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <9961CE9D-E1D6-43F3-A0E0-6AA82BC3A339@randomchaos.com> Message-ID: <6DF547A1-170B-4083-B341-DAFBAA568E43@randomchaos.com> On Dec 15, 2007, at 3:08 AM, Ciaran McNulty wrote: >> It seems to me "3:23" is already >> machine-readable > > Does 3:23 mean 3 mins 23 seconds, or 3 hours 23 mins, or 23 minutes > past three o'clock? ;-) My point is it's not productive to ask such questions outside the context of the actual problem, which in this case is class="haudio" and class="duration". There may still be some ambiguity there, but there's not as much as you're suggesting (a duration is clearly not a time) and focusing on such *actual* ambiguity is more useful than worrying about hypothetical ambiguity. Let's establish, for example, if we have an actual use case for month-long durations so we don't waste our time solving a problem we don't actually have. That is, let's follow the process. Peace, Scott From msporny at digitalbazaar.com Sat Dec 15 11:00:27 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Dec 15 11:00:33 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> Message-ID: <4764244B.4000309@digitalbazaar.com> Paul Wilkins wrote: > The hAudio time should be denoted in seconds. If 3:23 is given it's to > be seen as three minutes and twenty two seconds. If hours are needed > it should be 1:3:23 (0 prefix optional) to denote 1 hour three minutes > and twenty two seconds. > > This way the hAudio standard can work without needing to modify the > text, the abbr pattern isn't required and everybody can go home and > sleep restfully for the night. You may sleep restfully with that approach, but I can't imagine that many others on here would... :) You are effectively making the argument that we should forget about using ISO standards, which is one of the microformats principles - re-use, and replace it with our own. I can guarantee you that if we take that approach, we'll be having this same argument with the next ISO standard that gets used by the uF community. I'm not stating that the solution we have for hAudio at the moment is ideal, but re-inventing the wheel isn't necessarily the best approach either. What was the problem with the SPAN approach, again? 3:23 - You can set most, if not all, screen readers to not verbalize @title in SPAN. - We're not abusing ABBR. -- manu From pmw57 at xtra.co.nz Sat Dec 15 13:27:12 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sat Dec 15 13:27:20 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <4764244B.4000309@digitalbazaar.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> Message-ID: <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> On Dec 16, 2007 8:00 AM, Manu Sporny wrote: > What was the problem with the SPAN approach, again? > > 3:23 > > - You can set most, if not all, screen readers to not verbalize @title > in SPAN. > - We're not abusing ABBR. I've been looking carefully through the HTML 4.01 specs and realised that there is no actual mechanism provided for what we are wanting to achieve. This is why there has been so much debate about this and it's why compromises will have to be made if we're to achieve our end result. One of the things I came across is that the INS element accepts a datetime attribute, but it has to be fully specified as a moment in time. That might be useful for other applications like the calendar. The A element is the other one that I came across. We appear to have been completely ignoring this one, even though it looks to be a very suitable candidate. The specs say that it doesn't have to link to anything, and can contain the class and title of what we require. "Authors may also create an A element that specifies no anchors, i.e., that doesn't specify href, name, or id." 3:23 And if you don't want the title to appear when you hover over the text, you can leave the A element empty. 3:23 In both situations the A element is not included in the tabbed flow of the document, because there is no anchor involved. With this technique we are able to embed machine-only information around or near-to the human readable text. -- Paul Wilkins From martin at weborganics.co.uk Sat Dec 15 14:52:12 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Dec 15 14:50:24 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> References: <3EdnIngyADYHFwQ9@pigsonthewing.org.uk> <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> Message-ID: <1197759132.11446.15.camel@localhost.localdomain> Hello Paul On Sun, 2007-12-16 at 10:27 +1300, Paul Wilkins wrote: > On Dec 16, 2007 8:00 AM, Manu Sporny wrote: > > What was the problem with the SPAN approach, again? > > > > 3:23 > > > > - You can set most, if not all, screen readers to not verbalize @title > > in SPAN. > > - We're not abusing ABBR. > > I've been looking carefully through the HTML 4.01 specs and realised > that there is no actual mechanism provided for what we are wanting to > achieve. This is why there has been so much debate about this and it's > why compromises will have to be made if we're to achieve our end > result. > > One of the things I came across is that the INS element accepts a > datetime attribute, but it has to be fully specified as a moment in > time. That might be useful for other applications like the calendar. No ins is good and is valid markup... > > The A element is the other one that I came across. We appear to have > been completely ignoring this one, even though it looks to be a very > suitable candidate. > The specs say that it doesn't have to link to anything, and can > contain the class and title of what we require. > "Authors may also create an A element that specifies no anchors, > i.e., that doesn't specify href, name, or id." > > 3:23 a is good too... > > And if you don't want the title to appear when you hover over the > text, you can leave the A element empty. > > 3:23 the problem is as you say the above two will still put machine data in the users view! from an accessibility point of view Manu mentioned earlier, you can just turn off the titles? the title area of a link or span or anywhere on a web page is important to people who do use screen readers, they usually give information about content or about the links they are about to visit, so turning of titles really is out of the question. The empty although valid, seems nasty to me and a little anti!, microformats are supposed to represent the data they contain...are they? Thanks Martin > > In both situations the A element is not included in the tabbed flow of > the document, because there is no anchor involved. > > With this technique we are able to embed machine-only information > around or near-to the human readable text. > From pmw57 at xtra.co.nz Sat Dec 15 15:28:16 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sat Dec 15 15:28:24 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <1197759132.11446.15.camel@localhost.localdomain> References: <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> Message-ID: <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> On Dec 16, 2007 11:52 AM, Martin McEvoy wrote: > The empty although valid, seems nasty to me and a little anti!, > microformats are supposed to represent the data they contain...are they? As I was saying, this is why there has been so much debate about this and it's why compromises will have to be made if we're to achieve our end result. The elements haven't been designed for what we are trying to use them for. As such, there will be situations where the only other solutions have differing levels of tradeoffs. For example, you can use the following which gives no title display in both Firefox and IE, but it's largely a hack. 3:23 A simple statement of fact is, if you don't want titles to be displayed then don't wrap them around content. Humans first and machines second. The empty anchor before the content appears to fulfil that nicely, more-so than other attempts. -- Paul Wilkins From martin at weborganics.co.uk Sat Dec 15 16:39:20 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Dec 15 16:37:33 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> References: <47611156.9030107@sanchothefat.com> <47614D82.6000600@googlemail.com> <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> Message-ID: <1197765560.11611.14.camel@localhost.localdomain> On Sun, 2007-12-16 at 12:28 +1300, Paul Wilkins wrote: > On Dec 16, 2007 11:52 AM, Martin McEvoy wrote: > > The empty although valid, seems nasty to me and a little anti!, > > microformats are supposed to represent the data they contain...are they? > > > As I was saying, this is why there has been so much debate about this > and it's why compromises will have to be made if we're to achieve our > end result. > > The elements haven't been designed for what we are trying to use them > for. As such, there will be situations where the only other solutions > have differing levels of tradeoffs. > > For example, you can use the following which gives no title display in > both Firefox and IE, but it's largely a hack. > 3:23 > > A simple statement of fact is, if you don't want titles to be > displayed then don't wrap them around content. > Humans first and machines second. The empty anchor before the content > appears to fulfil that nicely, more-so than other attempts. OK Paul, lets try and put that in the real world, My client has a music store with around 500 pages of content and around 10 to 20 items of hAudio on each page, My client want's their pages to validate and be accessible.. no problem i say, semantic markup... and SEO, semantic markup... we can sprinkle some hAudio magic in there I say .. great my client says because they trust me im good at my job, I do the job, my boss looks at my work and says "what are all these empty anchors about"... pause right there... any SEO worth his salt will know anchor text links that go nowhere, will A, reduce the quality of out going links from your site so reducing PR (Page Rank) and B, more than likley get you banned from google because it will think you are trying to spam it.... you know what my boss will say....you are sacked. so no thank you Paul although your idea is workable, its still a hack, and in the real world never likely to be used. Thanks Martin > From tantek at cs.stanford.edu Sat Dec 15 19:40:57 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sat Dec 15 19:38:34 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <1197765560.11611.14.camel@localhost.localdomain> Message-ID: On 12/15/07 4:39 PM, "Martin McEvoy" wrote: > OK Paul, lets try and put that in the real world, My client has a music > store with around 500 pages of content and around 10 to 20 items of > hAudio on each page, My client want's their pages to validate and be > accessible.. no problem i say, semantic markup... and SEO, semantic > markup... we can sprinkle some hAudio magic in there I say .. great my > client says because they trust me im good at my job, I do the job, my > boss looks at my work and says "what are all these empty anchors > about"... pause right there... any SEO worth his salt will know anchor > text links that go nowhere, will A, reduce the quality of out going > links from your site so reducing PR (Page Rank) and B, more than likley > get you banned from google because it will think you are trying to spam > it.... you know what my boss will say....you are sacked. > > so no thank you Paul although your idea is workable, its still a hack, > and in the real world never likely to be used. Martin, thanks for this reality-check. You've provided some good reasons for why empty hyperlinks are an anti-pattern, and given that that's two this week, and that we have a few existing anti-patterns documented on the wiki, I've drafted this wiki page accordingly. http://microformats.org/wiki/anti-patterns In particular I've documented part of what you noted above in this section: http://microformats.org/wiki/anti-patterns#empty_hyperlinks I encourage you to expand upon it with any additional details / references. Thanks, Tantek From chris.messina at gmail.com Sat Dec 15 20:25:25 2007 From: chris.messina at gmail.com (Chris Messina) Date: Sat Dec 15 20:25:29 2007 Subject: [uf-discuss] Digg profile rel-me should have rel-nofollows removes Message-ID: <1bc4603e0712152025j4a2c5c34mb4a894a49aab1b85@mail.gmail.com> Hi Daniel, I wanted to let you know that in implementing identity consolidation using rel-me on people's public profiles, you killed the usefulness of your work by adding rel-nofollow. As you can see from the wiki, rel-me links MUST not be accompanied by rel-nofollow attributes. http://microformats.org/wiki/xfn-clarifications#me_nofollow_interaction Would be great to see if you could clean this up for the next revision. Cheers, Chris -- Chris Messina Citizen-Participant & Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412.225.1051 IM: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private From pmw57 at xtra.co.nz Sat Dec 15 20:28:10 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sat Dec 15 20:28:13 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <1197765560.11611.14.camel@localhost.localdomain> References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> <1197765560.11611.14.camel@localhost.localdomain> Message-ID: <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> On Dec 16, 2007 1:39 PM, Martin McEvoy wrote: > my > boss looks at my work and says "what are all these empty anchors > about"... pause right there... any SEO worth his salt will know anchor > text links that go nowhere, will A, reduce the quality of out going > links from your site so reducing PR (Page Rank) and B, more than likley > get you banned from google because it will think you are trying to spam > it.... you know what my boss will say....you are sacked. First an apology to Martin, my reply went direct to him when it should have come to the group. The A elements are not empty-anchors, and they are not text links that go nowhere. There is no text being linked, and there is no href, no name and no id to anchor them to anything. If they don't anchor to anything they can't be anchors, and are perfectly valid from the HTML spec and google perspective. Regardless of that though, they don't have to be anchors. For the sake of simplifying things they can just as easily be SPAN elements. 2:23 With this it is not possible to prevent the title from being used by screen readers and other people who hover their mouse over the time value. The title is purely to provide machine readable information that is not humanly presented. If the title is to not to be presented as human readable information, then the title must be wrapped around no text. 2:23 It may even be possible to use a special class to designate that the title has special meaning. 2:23 Remember, the HTML 4 specs are not designed for what we're trying to do here. We are looking for how to provide computer understandable information without interfering with the use of human readable text. Another possible solution is to provide greater detail for the time itself. 2:23 This I understand is an acceptable title for screen readers, it expands suitably on 2:23 (which could be 2 hours 23 minutes or 2 minutes 23 seconds) and it's computer understandable in an ISO 8601 manner. I will gratefully hear from anyone else who has an include pattern where computer understandable information does not interfere with human readable information. -- Paul Wilkins From csarven at gmail.com Sat Dec 15 21:30:23 2007 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Dec 15 21:30:26 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns Message-ID: This is to address "SEO" and anchors () in documents. Fortunately, good SEO is more complex then boiling down well-ranking in SERPs into how the anchors are set in a document. Regarding: http://microformats.org/wiki/anti-patterns#empty_hyperlinks point A) if there is no href attribute and value set then the current document is not pointing to any resource, therefore there is no impact on PR as there is no weight to distribute between documents. point B) Google or any other search engine will not simply ban a Web site from the left-field if there are no obvious indicators ("bad intentions") to be delisted from SERPs. Needless to say, getting banned is not a quick automated action and "spamming" goes much further then that. Moreover this is like suggesting using URL fragments (internal link anchors) in href is bad for SEO. In addition to all this, I do not think that microformats should be concerned with the SEO practices as there are many guidelines out there and which method works well for one site today on a particular engine may not necessarily work tomorrow. Therefore, I strongly think that we move away from these sort of practices. I've written about good SEO practices (read: good Web development practices) if anyone would like to give it a read: http://www.csarven.ca/internal-seo-guidelines By mentioning all this I am not suggesting the usage of empty anchors (no href attribute/value). -Sarven From andy at pigsonthewing.org.uk Sun Dec 16 02:50:23 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Dec 16 02:52:03 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: References: <1197765560.11611.14.camel@localhost.localdomain> Message-ID: In message , Tantek ?elik writes >I've drafted this wiki page >http://microformats.org/wiki/anti-patterns That page, and the glossary would benefit from a definition of "anti-pattern". -- Andy Mabbett From andy at pigsonthewing.org.uk Sun Dec 16 03:08:12 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Dec 16 03:20:00 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> <1197765560.11611.14.camel@localhost.localdomain> <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> Message-ID: In message <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com>, Paul Wilkins writes > For the sake of simplifying things they can just as easily be SPAN >elements. >If the title is to not to be presented as human readable information, >then the title must be wrapped around no text. > >2:23 IIRC, HTML-Tidy strips empty spans. (Does it do the same for empty anchors?) -- Andy Mabbett From jim at eatyourgreens.org.uk Sun Dec 16 03:04:23 2007 From: jim at eatyourgreens.org.uk (James O'Donnell) Date: Sun Dec 16 03:47:39 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> <1197765560.11611.14.camel@localhost.localdomain> <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> Message-ID: On 16 Dec 2007, at 04:28, Paul Wilkins wrote: > 2:23 > > With this it is not possible to prevent the title from being used by > screen readers and other people who hover their mouse over the time > value. The title is purely to provide machine readable information > that is not humanly presented. Hi, JAWS (and, I think, WindowEyes also) reads titles on links, abbreviations and form controls. should be safe if you want to hide the contents of the title attribute from a screenreader. Span seems a more pragmatic choice to me, since title on supplements the enclosed text, whereas title on replaces the enclosed text. As someone else mentioned, for a lot of these cases we want to annotate a piece of text with computer-parsable information. Jim Jim O'Donnell jim@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens From andy at pigsonthewing.org.uk Sun Dec 16 04:26:56 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Dec 16 04:28:14 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> <1197765560.11611.14.camel@localhost.localdomain> <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> Message-ID: In message , James O'Donnell writes > >On 16 Dec 2007, at 04:28, Paul Wilkins wrote: > >> 2:23 >> >> With this it is not possible to prevent the title from being used by >> screen readers and other people who hover their mouse over the time >> value. The title is purely to provide machine readable information >> that is not humanly presented. > >Hi, > >JAWS (and, I think, WindowEyes also) reads titles on links, >abbreviations and form controls. should be safe if you want to >hide the contents of the title attribute from a screenreader. > >Span seems a more pragmatic choice to me, since title on >supplements the enclosed text, whereas title on replaces the >enclosed text. As someone else mentioned, for a lot of these cases we >want to annotate a piece of text with computer-parsable information. While I understand the desire to avoid namespacing per se, in this case, using: 2:23 or 4.03pm would render the title both more semantically accurate and human-readable. It would also enable the users of assistive technologies to hit the "next" button as soon as they hear "value colon" read out, bypassing the machine-readable fragment. Parsers "MUST" ignore titles not starting with "value;", thereby ensuring compatibility with titles used on spans, for other purposes. In the above "value:" is just as suggestion; the label could be "machine-value:", "data-equivalent:", or some other such word or phrase. This suggestion may case problems for non-English speakers, though. Perhaps "data:" would be more internationally recognised? -- Andy Mabbett * Say "NO!" to compulsory UK ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From martin at weborganics.co.uk Sun Dec 16 04:55:13 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Dec 16 04:53:29 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: References: Message-ID: <1197809713.11736.31.camel@localhost.localdomain> On Sun, 2007-12-16 at 00:30 -0500, Sarven Capadisli wrote: > This is to address "SEO" and anchors () in documents. > > Fortunately, good SEO is more complex then boiling down well-ranking > in SERPs into how the anchors are set in a document. > > Regarding: http://microformats.org/wiki/anti-patterns#empty_hyperlinks > > point A) if there is no href attribute and value set then the current > document is not pointing to any resource, therefore there is no impact > on PR as there is no weight to distribute between documents. the suggestion was we do this: 2:23 or 2:23 now unfortunatly on both occasions the "a" is NOT empty @title has a value and thus robots crawling your site will be expecting a href attribute for which there is NONE. > > point B) Google or any other search engine will not simply ban a Web > site from the left-field if there are no obvious indicators ("bad > intentions") to be delisted from SERPs. Needless to say, getting > banned is not a quick automated action and "spamming" goes much > further then that. No you are probably right average joe probably wont get banned it would depend on if an unscrupulus SEO decided to exploit this pattern (stuffing the @title with keywords springs to mind), that would be a worse case scenario, but even so the consequences of doing such things are way to risky and have little or no benefit to the web itself. As Tantek says we should avoid promoting such Anti patterns. > > Moreover this is like suggesting using URL fragments (internal link > anchors) in href is bad for SEO. No Im not links that go somewhere: 2:23 Is acceptable because there is an href value and it goes somewhere, no confusing the bots > > In addition to all this, I do not think that microformats should be > concerned with the SEO practices as there are many guidelines out > there and which method works well for one site today on a particular > engine may not necessarily work tomorrow. Therefore, I strongly think > that we move away from these sort of practices. Microformats are "on page" SEO they are good for the web, and good for users, lets not spoil things for our respected community by presenting half baked solutions that are at best a hack. Thanks Martin > > I've written about good SEO practices (read: good Web development > practices) if anyone would like to give it a read: > http://www.csarven.ca/internal-seo-guidelines > > By mentioning all this I am not suggesting the usage of empty anchors > (no href attribute/value). > > -Sarven > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From andy at pigsonthewing.org.uk Sun Dec 16 05:48:58 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Dec 16 06:00:14 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <1197809713.11736.31.camel@localhost.localdomain> References: <1197809713.11736.31.camel@localhost.localdomain> Message-ID: In message <1197809713.11736.31.camel@localhost.localdomain>, Martin McEvoy writes >> Moreover this is like suggesting using URL fragments (internal link >> anchors) in href is bad for SEO. > >No Im not links that go somewhere: > >2:23 > >Is acceptable because there is an href value and it goes somewhere, no >confusing the bots ...just the users. Do we really want to present people with hyperlinks that link to the place they're already at? -- Andy Mabbett From martin at weborganics.co.uk Sun Dec 16 07:42:52 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Dec 16 07:41:06 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: References: <1197809713.11736.31.camel@localhost.localdomain> Message-ID: <1197819772.12461.5.camel@localhost.localdomain> On Sun, 2007-12-16 at 13:48 +0000, Andy Mabbett wrote: > In message <1197809713.11736.31.camel@localhost.localdomain>, Martin > McEvoy writes > > >> Moreover this is like suggesting using URL fragments (internal link > >> anchors) in href is bad for SEO. > > > >No Im not links that go somewhere: > > > >2:23 > > > >Is acceptable because there is an href value and it goes somewhere, no > >confusing the bots > > ...just the users. > > Do we really want to present people with hyperlinks that link to the > place they're already at? no not really just presenting an example, and people already do create hyperlinks to the content they are already at, named anchors are a useful feature in long pages of content. I also am not supporting any such usage (just for the record) ;) Thanks Martin > From martin at weborganics.co.uk Sun Dec 16 08:02:55 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Dec 16 08:01:21 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <1197819772.12461.5.camel@localhost.localdomain> References: <1197809713.11736.31.camel@localhost.localdomain> <1197819772.12461.5.camel@localhost.localdomain> Message-ID: <1197820975.12461.22.camel@localhost.localdomain> On Sun, 2007-12-16 at 15:42 +0000, Martin McEvoy wrote: > On Sun, 2007-12-16 at 13:48 +0000, Andy Mabbett wrote: > > In message <1197809713.11736.31.camel@localhost.localdomain>, Martin > > McEvoy writes > > > > >> Moreover this is like suggesting using URL fragments (internal link > > >> anchors) in href is bad for SEO. > > > > > >No Im not links that go somewhere: > > > > > >2:23 > > > > > >Is acceptable because there is an href value and it goes somewhere, no > > >confusing the bots > > > > ...just the users. > > > > Do we really want to present people with hyperlinks that link to the > > place they're already at? > > no not really just presenting an example, and people already do create > hyperlinks to the content they are already at, named anchors are a > useful feature in long pages of content. > > I also am not supporting any such usage (just for the record) ;) The crux of what I am trying to explain is that at the moment empty anchor text links mean nothing as far as SEO is concerned, bots will either ignore or simply erase them from there index. If we as a respected community say that empty anchor text DO mean something, then bots and other applications that crawl the web will have to take this into account in order to correctly represent their indexes. Black Hat SEO's will undoubtedly exploit this to their own means rel="nofollow" is a classic example of where a microformat has been exploited by SEO's to do something its not meant for and thus may be regarded as an Anti design pattern. I do not wish (although the intentions are good) to be responsible for opening the floodgates on any such behavior, and as a community we have a responsibility to steer well clear of hacks, and half hearted solutions that may end up causing more damage than good. Thanks martin > > Thanks > > Martin > > From thom at ts0.com Sun Dec 16 09:17:05 2007 From: thom at ts0.com (Thom Shannon) Date: Sun Dec 16 09:27:08 2007 Subject: [uf-discuss] XFN syntax question In-Reply-To: References: <4762576A.5010502@ts0.com> Message-ID: <47655D91.1080700@ts0.com> > You're right. It oughta be space seperated. Which blogging platform > is doing it that way It's blogengine.net From jeremy at adactio.com Sun Dec 16 09:30:38 2007 From: jeremy at adactio.com (Jeremy Keith) Date: Sun Dec 16 09:31:02 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> <1197765560.11611.14.camel@localhost.localdomain> <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> Message-ID: <424D5E0A-2D7D-441E-87D9-2B3BDF71973A@adactio.com> Jim wrote: > Span seems a more pragmatic choice to me, since title on > supplements the enclosed text, whereas title on replaces the > enclosed text. As someone else mentioned, for a lot of these cases > we want to annotate a piece of text with computer-parsable > information. I agree that there are problems (both semantic and?from the angle of assistive technology?possibly practical) associated with using ABBR. But I really don't understand this obsession with SPAN. Why would SPAN be any more or less preferable to any other element? I think the crux of this matter is that the ABBR design pattern is one of the few times when using a microformat mandates what element an author should use. In hCard, for example, all of the following are fine: Jeremy Keith Jeremy Keith
        Jeremy Keith
        Jeremy Keith ...and so on. You get the picture. The author gets to decide which element to use based on the context. A good author will choose the best (most semantically meaningful) element for the task at hand. Sometimes that might be SPAN but not always. For datetimes, this semantic decision is only in the hands of the author if they choose to display the datetimes as text contained by opening and closing tags. All of these are, from the perspective of the hCalendar spec, fine: 2007-12-16T16:20:00 2007-12-16T16:20:00
        2007-12-16T16:20:00
        The problem is that, if the author wants to use a design pattern that doesn't display this data between tags, the only option is to use the ABBR design pattern: ...and that's when you run into all the problems we've been discussing. There are potentially problems with screenreaders (test results are still needed firm up these issues) but, more fundamentally, there's the semantic issue, as Ben said: > This doesn't actually need to have any concern with accessibility, > or assistive technology tools. Frankly, the difficulty in getting > solid tests from such tools makes that line of argument less > attractive in itself. But what has to be a fundamental baseline in > our implementation of optimisation patterns in microformats is the > HTML specification we are building on top of. If a design pattern is going to *mandate* that authors must use a particular element, then the semantic meaning of that element needs to be pretty solid. That doesn't seem to be the case with the ABBR design pattern, as evidenced by the discussion here and, more importantly, as is outlined in the HTML spec. In my opinion, this matter might be best resolved by giving the choice back to the author. Allow the author to decide what element is semantically best suited for the datetime pattern, just as the author is allowed to decide what element is semantically best suited for any other microformat class name. But... If we just swap out ABBR for SPAN, we're not solving anything. The SPAN element *might* be the right element to use for a datetime, or another element might be better... it all depends on the context? something that only the author will be aware of. So when we're talking about alternatives to the ABBR design pattern, can we please stop just talking about SPAN? Surely what we're really talking about is allowing the design pattern to be expanded to any element (not just ABBR), at the author's discretion. There's already confusion out there: some people have looked at the wiki and mistakenly jumped to the conclusion that authors must use SPANs and DIVs to create microformats because those are the elements used in the examples. Let's not turn those fears into reality by seriously suggesting that authors must use the SPAN element if they want to employ the datetime design pattern. Can we agree that what we are discussing is opening up the datetime pattern to elements other than ABBR, not simply swapping ABBR for SPAN? I'd be willing to consider a SPAN design pattern if it had any semantic merit but considering that SPAN is effectively lacking in any semantic value, I don't see how a SPAN design pattern would be any better than a DIV design pattern, a P design pattern, a Q design pattern or a CITE design pattern. In short, I don't think we should be telling authors what elements to use. That's what got us into hot water with ABBR; I don't want to see the same mistake repeated again. The fact that microformats allow authors to choose the most semantically meaningful elements (according to context) is one of the great strengths of microformats, in my opinion. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From bhawkeslewis at googlemail.com Sun Dec 16 10:01:34 2007 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Dec 16 10:01:42 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <1197820975.12461.22.camel@localhost.localdomain> References: <1197809713.11736.31.camel@localhost.localdomain> <1197819772.12461.5.camel@localhost.localdomain> <1197820975.12461.22.camel@localhost.localdomain> Message-ID: <476567FE.6000905@googlemail.com> Martin McEvoy wrote: > The crux of what I am trying to explain is that at the moment empty > anchor text links mean nothing as far as SEO is concerned, bots will > either ignore or simply erase them from there index. > > If we as a respected community say that empty anchor text DO mean > something, then bots and other applications that crawl the web will have > to take this into account in order to correctly represent their indexes. > > Black Hat SEO's will undoubtedly exploit this to their own means > rel="nofollow" is a classic example of where a microformat has been > exploited by SEO's to do something its not meant for and thus may be > regarded as an Anti design pattern. > > I do not wish (although the intentions are good) to be responsible for > opening the floodgates on any such behavior, and as a community we have > a responsibility to steer well clear of hacks, and half hearted > solutions that may end up causing more damage than good. Let me go through Martin's argument, as I understand it, to explain why I don't find it persuasive. My comments are in parentheses. 1. Search engines currently "ignore" TITLE on non-linking A. (Does anyone has any clear evidence to confirm this? Does that evidence hold for all major engines, or only for Google? I can't find anything solid.) 2. If microformats made use of TITLE on non-linking A for machine-readable data, search engines would want to use it. (This seems plausible.) 3. Black hat SEOs would then keyword-stuff TITLE on non-linking A. (Given the above premises, this seems plausible). 4. Search engines would not be able to distinguish keyword-stuffed TITLE attributes on non-linking A from microformat data. (rel="nofollow" is a standalone pattern and it would be difficult to tell correct from incorrect use without human inspection. But these data-hiding patterns are intended for use within super-patterns like hAudio that tell parsers what to expect. Distinguishing data-hiding patterns of this sort from keyword stuffing sounds like a trivial programming task, so I think search engines surely would be able to distinguish between them.) 5. This problem only occurs with non-linking A. (But by its very nature, markup that hides content from most users, most of the time ? and that includes /all/ patterns that hide data in TITLE attributes ? is susceptible to keyword stuffing. Indeed, I would bet that each and every one of these patterns is already being abused by black-hat SEOs, effectually or not.) NB: This email isn't intended as a general endorsement of TITLE on non-linking A. I'm deeply sceptical about misusing the TITLE attribute for human-unfriendly data, especially on anything other than an empty SPAN. I'm just saying I don't buy Martin's SEO-based argument against non-linking A in particular. -- Benjamin Hawkes-Lewis From martin at weborganics.co.uk Sun Dec 16 10:52:25 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Dec 16 10:50:39 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <476567FE.6000905@googlemail.com> References: <1197809713.11736.31.camel@localhost.localdomain> <1197819772.12461.5.camel@localhost.localdomain> <1197820975.12461.22.camel@localhost.localdomain> <476567FE.6000905@googlemail.com> Message-ID: <1197831145.13080.6.camel@localhost.localdomain> On Sun, 2007-12-16 at 18:01 +0000, Benjamin Hawkes-Lewis wrote: > 1. Search engines currently "ignore" TITLE on non-linking A. (Does > anyone has any clear evidence to confirm this? Does that evidence > hold > for all major engines, or only for Google? I can't find anything > solid.) this may help: go here http://www.webconfs.com/search-engine-spider-simulator.php copy and paste this url http://weborganics.co.uk/files/test.html the test consists of four anchor texts two with href attributes two without It isnt the definitive answer but I would say pretty accurate ;) Martin From pmw57 at xtra.co.nz Sun Dec 16 11:12:06 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Sun Dec 16 11:12:10 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <476567FE.6000905@googlemail.com> References: <1197809713.11736.31.camel@localhost.localdomain> <1197819772.12461.5.camel@localhost.localdomain> <1197820975.12461.22.camel@localhost.localdomain> <476567FE.6000905@googlemail.com> Message-ID: <18050cf90712161112o4f482f07nb289432b0678a4c8@mail.gmail.com> On Dec 17, 2007 7:01 AM, Benjamin Hawkes-Lewis wrote: > NB: This email isn't intended as a general endorsement of TITLE on > non-linking A. I'm deeply sceptical about misusing the TITLE attribute > for human-unfriendly data, especially on anything other than an empty > SPAN. I'm just saying I don't buy Martin's SEO-based argument against > non-linking A in particular. Thanks for going through this. Because the HTML spec doesn't allow for what we're trying to achieve, one possibility was to use non-linking anchors, but there are several issues with that. I still prefer the abbr include pattern though. The PT2M23S is to indicate a duration of time, but using such a format meets resistance in that it's not easy for people to correctly markup in such a manner. Another option is to use hh:mm:ss instead. This is indicating an actual moment in time. Is it viable to consider that if we play a track from midnight, that we can specify that moment in time when it ends? 2:23 -- Paul Wilkins From msporny at digitalbazaar.com Sun Dec 16 11:14:37 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Dec 16 11:14:41 2007 Subject: [uf-discuss] Re: Precise Expansion Patterns In-Reply-To: <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> References: <47628DED.9010506@googlemail.com> <825E610A-3275-45DC-9CE4-9F7E92E7DCBB@ben-ward.co.uk> <18050cf90712150432v5382c9e6t106954590e7a1756@mail.gmail.com> <4764244B.4000309@digitalbazaar.com> <18050cf90712151327k7d0230b5t23d25d1662cf8c12@mail.gmail.com> <1197759132.11446.15.camel@localhost.localdomain> <18050cf90712151528h1e8c4e2fp5fe3bc7b5c89690e@mail.gmail.com> <1197765560.11611.14.camel@localhost.localdomain> <18050cf90712152028m45a82f95i5ee1d672c5194330@mail.gmail.com> Message-ID: <4765791D.3070303@digitalbazaar.com> Paul Wilkins wrote: > Another possible solution is to provide greater detail for the time itself. > > 2:23 > > This I understand is an acceptable title for screen readers, it > expands suitably on 2:23 (which could be 2 hours 23 minutes or 2 > minutes 23 seconds) and it's computer understandable in an ISO 8601 > manner. If you are suggesting that we use the hh:mm:ss time format for expressing duration, we cannot. That would be an abuse of the ISO 8601 standard. The standard is very specific about specifying TIME and about specifying DURATION. Duration MUST be in one of the following formats, where 0-values can be omitted: PnnYnnMnnDTnnHnnMnnS PnnYnnWnnDTnnHnnMnnS PT