Re: [whatwg] Various autocomplete= topics
[General point, so not quoting anyone in particular] [Resending to list, apologies to Ian] Why would you define any address components other than those in vCard, a standard with massive implementation and interoperable with most address book applications and services? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] a rel=attachment
On 16 July 2011 02:20, Peter Kasting pkast...@google.com wrote: On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote: * existing rel=enclosure spec - download the link when clicked/activated. I object to rel=enclosure purely on naming grounds. It is completely unintuitive. I don't find the fact that a spec exists for it a compelling reason to use it. (Specs exist for lots of things, many of them bad.) The above bullet-point is also at odds with: http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html in which it was claimed in August 2008 that rel=enclosure is also for streaming media: ... that hyperlink is intended to be downloaded (and/or streamed) and cached (and/or buffered) That said, it appears that the definition of rel=enclosure at: http://microformats.org/wiki/rel-enclosure was never updated to account for that, and this hAudio still has the issue: http://microformats.org/wiki/haudio-issues#D4:_2008-01-10__rel-enclosure_does_not_allow_for_links_to_streaming_files which the August 2008 statement was suposedly intended to rectify. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
On 14 June 2011 08:32, Ian Hickson i...@hixie.ch wrote: On Thu, 10 Mar 2011, Jukka K. Korpela wrote: Under these circumstances, what should we say to people to need to use paragraphs that contain lists, for example? That paragraphs don't contain lists; when a sentence has * this * structure, ...it is in fact two paragraphs and a bullet list. I think that's an opinion, not a fact. Indeed, but block of text is pretty much what a paragraph is -- it isn't a logical construct. Cite? The Oxford English Dictionary would seem to disagree with you: A distinct passage or section of a text, usually composed of several sentences, dealing with a particular point, a short episode in a narrative, a single piece of direct speech, etc. It's quite possible, if rare, for a sentence to span paragraphs even without lists being involved... Take, for instance, the first... ...no, the second... ...no, the third, of these blocks of text. That sentence spans three paragraphs. My view is that that's one paragraph, with line breaks. Consider: I like apples, pears, grapes, but not bananas. Nor do I like peaches. and: I like * apples * pears * grapes but not bananas. Nor do I like peaches. The difference between those two is presentational, not semantic. Each is a single paragraph. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Interpretation issue: can section be used for extended paragraphs?
On 10 March 2011 08:20, Jukka K. Korpela jkorp...@cs.tut.fi wrote: what should we say to people to need to use paragraphs that contain lists, for example? This has concerned me for some time. Consider a more complex scenario: pI always like to eat these cheeses:/p ul liCheddar liStilton liRed Lester /ul pbut I enjoy them most with one of these biscuits:/p ul liwheat crackers lirye crackers lidigestives /ul pand some chutney./p What I would like to be able to do is: pI always like to eat these cheeses: ul liCheddar liStilton liRed Lester /ul but I enjoy them most with one of these biscuits: ul liwheat crackers lirye crackers lidigestives /ul and some chutney./p Now I'm hungry :-( -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] comment element in HTML5 Spec?
Perhaps what is needed is some kind of in-reply-to attribute: article id=beerI like beer/article article id=firstreply in-reply-to=beerMe too!/article or even: article id=beerI like beer article id=firstreply in-reply-to=beerMe too!/article /article On 14 December 2010 17:41, Richard Summers richard.summ...@bbc.co.uk wrote: Thanks for the feedback guys, really appreciate it. Using article elements within other article elements feels a bit like we'd just be replacing div for article, it seems to remove some of the logical distinction between different types of content. As the use-case would potentially be huge (previously stated impact to Blogs/Message Boards/News outlets), is there any more mileage in perhaps using a feedback (or similar) element, as suggested by Bruce Hyslop? A feedback,or similar, (response?) element would distinguish content as a response to an article, and therefore denote that it serves a different purpose to the main content in the article element. Thoughts? Rich On 13/12/2010 19:23, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Dec 13, 2010 at 10:49 AM, Richard Summers richard.summ...@bbc.co.uk wrote: Hi gang, I wonder if anyone can help me... I attended great talk today by Bruce Lawson from Opera about HTML5. I was wondering, is there any plan to implement a comment element within the HTML5 spec? I¹m suggesting this as a complimentary element to the article element. I believe it could be useful as it could be used to differentiate between audience generated content and article-author generated content. This could enable search engines to differentiate between the 2 types of content, and weigh them differently in different searches. Semantically and structurally, something like this seems to make sense. This would mean huge implications for all the blogs out there, and the increasing number of commenting systems on News outlets. Cool, let me know if this has already been covered, or if it¹s not a good idea, why? :) The idea is potentially interesting. Right now, the correct way to mark up comments is to just put each in an article of their own (as each is a piece of independent content). What benefits could be brought along by instead using comment? I can think of a few potential benefits: 1. Differentiating between the main article and user-generated content in response (you bring this up). Would this be useful for search engines? I'm not sure. Would it be useful to weight comment content differently from article content? Perhaps weight links in comments less than links in the rest of the page? 2. Providing a bit more information to screen-readers that may navigate by headings or sections, to make it easier to skip to or over the comments on a post. 3. Make the authoring pattern a bit more obvious - rather than having to learn that it's okay and recommended to nest articles like that, authors could just naturally gravitate towards using article and comment together. One thing to note - comment has already been used by IE6 and earlier as an alternative to the !-- -- syntax for HTML comments. They apparently stopped supporting this in IE7, though (I can confirm that it no longer does anything special in IE8), so we probably don't have to worry about it. No other browser does anything special for it, it seems, so the compat impact is apparently small enough to be ignored. ~TJ 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. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 15:10, Daniel Glazman wrote: Le 09/08/10 03:11, Kit Grose a écrit : should the year field also permit the entry of BC/AD? Or a jewish year? Or a muslim year? Or counting since the first tooth of Carolus Magnus or the last onomatopoeia pronounced by Hannibal during his crossing of the Alps? Do you see anyone suggesting such things? If not, please can we avid such hyperbole. Tantek needs a year. He never said he needs to specify in which system the year is counted. He never said he cannot use a radiobutton for BC/AD or any other calendaring system aside of the year input. We (not just one person) always need to be able to know the calendar system in use; it's just that the default is Gregorian. Discussions of preference for one kind of UI over another are premature. Why make things complex when it's possible to make them simple? Why make things /overly/ simple, if it prevents valid use cases from being realised? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 16:03, Marshall Eubanks wrote: I do not think that there is an easy solution for this and other dating issues. This field is extraordinarily complex, with lots of corner cases, some very erudite in nature. Indeed; but there are sufficient pre-Gregorian dates in use on the web to warrant at least /one/ method of publishing them. [...] What I would recommend is, in addition to the datetime input types, an optional type=Calendar (e.g., type=Gregorian), which could be ignored or used, as the circumstances required. That is the current suggestion; reusing the parameter name CALTYPE from vCard. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? Years can be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 02:19, Ben Schwarz wrote: While creating an input that works for every use case you can think of sounds like a good idea, I'd like to question weather a user would ever *enter a date* that would require the inclusion of BC/AD. I'm certain that there is a requirement to markup such text, but as for * entry* I'm strongly of the opinion that you're over cooking this. It took only seconds to find: http://www.guernsey.net/~sgibbs/roman.html which requires (for some dates) entry of 1, 2, and 3-figure and BC years. Likewise: http://www.smart.net/~mmontes/ec-cal.html Please enter a year after A.D. 325 Consider also a site allowing a search of an archive of archaeological finds by year of origin. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 02:59, Ben Schwarz wrote: Because you can find an example isn't exactly what I would call a use case. I didn't find an example, I found many - more than one of which I quoted, by way of illustration. What would you call a use case? Nor were those pages examples of best practice in any way, shape or form. These requirements are new to me. Where are they documented? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
[Apologies - I inadvertently sent this to Kit, not the list, so it's now out-of-sequence] On Mon, August 9, 2010 00:44, Kit Grose wrote: How is a year input any different from a four-digit input type=number field? P.S. and here are some published five-and six- figure years: http://en.wikipedia.org/wiki/11th_millennium_and_beyond e.g. 15790 April 20: Annular solar eclipse and a transit of Mercury. 571741: A simultaneous transit of Venus and the Earth from Mars Note that while both are on Wikipedia, they're each cited from other sources. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, August 9, 2010 03:20, Ben Schwarz wrote: On Mon, August 9, 2010 02:59, Ben Schwarz wrote: Because you can find an example isn't exactly what I would call a use case. I didn't find an example, I found many - more than one of which I quoted, by way of illustration. What would you call a use case? Nor were those pages examples of best practice in any way, shape or form. These requirements are new to me. Where are they documented? They aren't documented at all (afaik). Its a common design methodology to design for only what you actually require at a given time. I'm afraid my confusion is only deepening; you didn't say anything about what [we] actually require (why would you; the examples I gave demonstrated that the facility to input 1-, 2- and 3-digit and BC dates is currently required); you said that the examples I gave were not best practice in any way, shape or form. [...] I'd like to think that a browser vendor would find it very difficult to schedule the time to implement such a full featured method of handling every date representation known to man, rather than other awesome feature x. I don't recall anyone asking for handling every date representation known to man. On the other hand, I have demonstrated a requirement to be able to input every date known to man. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] time
In message 20090314083450.ga30...@stripey.com, Smylers smyl...@stripey.com writes This thread appears to be proving that dates are very complicated and that to get them right for the general case involves lots of subtleties, All true. which would be a reason for punting -- only doing the simplest possible thing for now, acknowledging that that doesn't meet all desirable scenarios, and leaving everything else for HTML 6. I'm not clear on what basis you reach that conclusion from the undisputed facts above. Even attempts to produce a small list of changes that we have consensus on yields others disputing them, showing that we don't have consensus. ...yet. Right now we have a draft that: 2) allows without attaching sufficient meaning to it I don't think that's the case; the algorithm for parsing a year requires a number greater than zero: What a pity that human history - as published in the wild - doesn't fit that convenient shortcut. So my suggestion for a spec change is to replace zero with 1582. That further reduces the set of dates that time can represent, but avoids the complexity of pre-Gregorian dates, and avoids inadvertently giving a meaning to them that hampers the efforts of a future version of HTML to do all of this right. What advantage does deferring this problem give us, other than side-stepping something which needs to be addressed? -- Andy Mabbett Says NO! to compulsory UK ID Cards: http://www.no2id.net/ and: Free Our Data: http://www.freeourdata.org.uk (both also on Facebook)
Re: [whatwg] time
David Singer wrote: So far, we've had vague use cases related to historians and time lines In what way do you consider those use cases vague, and what would it take for you to consider them less so? there's been no clear description of the problems that need solving That's clearly an opinion, but I'd say it's a fundamentally wrong one. we really shouldn't be attempting to solve every little problem. Yet that seems to be what some people are pushing for by asking for alternative calendar systems, better historical date support, durations and time intervals, without much regard for the complexity such features would introduce for both authors and implementers. Wanting to resolve those clearly-delineated issues is not attempting to solve every little problem; nor do I see anyone not having regard for the complexity such features would introduce. Perhaps you could cite evidence? [Snip issues already addressed by Bruce Lawson]] -- Andy Mabbett ** via webmail **
Re: [whatwg] time
In message 49b90c20.9040...@lachy.id.au, Lachlan Hunt lachlan.h...@lachy.id.au writes * Investigation of how imprecise dates affect the ability to import such events into a calendar. e.g. The Sydney Royal Easter show scheduled for 2009-04, and takes place over a period of a few weeks in the month. Is it enough to simply say: time datetime=2009-049–22 April 2009/time Or would it be better to give the precise date range, as time datetime=2009-04-099/time–time datetime=2009-04- April, 2009/time Or would supporting a range directly in the datetime field support this better: time datetime=2009-04-09/2009-04-229–22 April 2009/time Investigating how hCalendar currently addresses use cases like that would be useful in order to address some of the limitations that approach may have. The most common way of representing that date-range in hCalendar at present would be: span class=vevent abbr class=dtstart title=2009-04-099/abbr - abbr class=dtend title=2009-04-23 22 April 2009/abbr /span Note: A class=summary is also required. The end date must be 'exclusive' - a known problem, for which solutions have been proposed. Another case for an imprecise date might be: ptime2009/time is The International Year of Astronomy./p For this, we would need to understand what real benefit consuming applications would gain from that. It's not really a date that someone would want to import directly into their calendar. But understanding what other potential applications, such as those mentioned above, might want to do with it would be useful. Yet again; the use-cases of sorting, searching or displaying visually (e.g. on a timeline). What advantage is there for authors and consumers by *not* extending the range of dates that can be described with time ? That's the wrong question to ask because it places the burdon of proof on the wrong side. OK: What /dis/advantage is there for authors and consumers by extending the range of dates that can be described with time ? But by not addressing every possible little use case under the sun, we keep the language simplified and easier for authors to learn and use, If you re-read my original proposal, I suggested defaulting to Gregorian time, while allowing those authors who wish to, to specify Julian or other dates. and we can focus on really optimising for the top ~80-90% of the use cases, without spending a disproportionate amount of time trying to optimise for the remaining ~10% of edge cases too. Who wants to fail ~10-20% of the time? -- Andy Mabbett
Re: [whatwg] time
In message caaf25cf-1fbe-494c-8361-e6811b6c5...@googlemail.com, Geoffrey Sneddon foolist...@googlemail.com writes Ultimately, why is the Gregorian calendar good enough for the ISO but not us? I'm sure plenty of arguments were made to the ISO before ISO8601 was published, yet that still supports only the Gregorian calendar, having been revised twice since it's original publication in 1988. Is there really any need to go beyond what ISO 8601 supports? What were the use-case(s) for ISO8601? If merely the exchange of calendar information, it's unlikely that it took account of the pre-Gregorian/ BCE/ imprecise situations under consideration here. -- Andy Mabbett
Re: [whatwg] time
In message p06240841c5deeed58...@[17.202.35.52], David Singer sin...@apple.com writes At 17:53 +0100 12/03/09, Julian Reschke wrote: Geoffrey Sneddon wrote: ... Ultimately, why is the Gregorian calendar good enough for the ISO but not us? I'm sure plenty of arguments were made to the ISO before ISO8601 was published, yet that still supports only the Gregorian calendar, having been revised twice since it's original publication in 1988. Is there really any need to go beyond what ISO 8601 supports? ... Indeed. We aren't the subject matter experts on calendars and date formats, so why do we pretend we are? I agree. As I said before, if we want a tag to express that a date is in a different calendar system, we are not going either to invent those tags or define the notation and conversion of those calendar systems here. We can and should rely on groups like ISO. If we're still discussing my proposal; I have not suggested inventing tags nor defining notations, merely allowing space for others (such as ISO) to do so. What I wrote was: The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like: time schema=[schema-name] datetime=[value][date in plain text]/time where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply: [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required. -- Andy Mabbett Says NO! to compulsory UK ID Cards: http://www.no2id.net/ and: Free Our Data: http://www.freeourdata.org.uk (both also on Facebook)
Re: [whatwg] time
In message cc3986d1-6ddc-4007-8bba-42a5d4e39...@eatyourgreens.org.uk, Jim O'Donnell j...@eatyourgreens.org.uk writes This is already a solved problem in the Text Encoding Intiative (TEI). The value of a date/time is encoded in the Gregorian calendar, using ISO8601. The calendar attribute is used to indicate the calendar of the original, written date enclosed in the tags. eg. from the TEI docs for dates and times date calendar=Julian value=1732-02-22Feb. 11, 1731./date I suggested that the calendar attribute be adopted in HTML5, as it would be useful to those of us who mark up historical texts in HTML. That's one possible solution - better than none - but I do wonder why we'd force authors to manually convert dates, when we all have machines which can do that. We can't change the author's original written dates That's certainly true. -- Andy Mabbett
Re: [whatwg] time
In message 20090309215532.ga3...@stripey.com, Smylers smyl...@stripey.com writes Tom Duhamel writes: My opinion is that all the following dates are precise: 2009 2009-03 2009-03-09 The later is more precise, but the three are all precise in my opinion. Being precise means having a small granularity. Obviously that's subjective, but in many cases granularity of a year would be deemed quite large. I take it you're not a geologist? ;-) If I wish to compare my earnings, or the average daily rainfall, or somesuch, for 2007 and 2008, then the four-figure value is as precise as it is possible to be; anything with higher granularity would introduce bogus precision. There are numerous reason to use dates which are not very precise, but are still precise nevertheless. I'm going to release the new version of my current project in time datetime=2009-04April/time but I cannot tell as of now the exact day of the release. Indeed, that's a reason to use an imprecise date in that paragraph of text. But it isn't apparently why that date needs to be marked up as such; what consumers of the above HTML would do something useful with it? I again refer readers to the use-cases I posted recently - including searching, sorting and visual display. -- Andy Mabbett
[whatwg] Profiles in-the-wild (was: Microformats, WebApps 1.0 and UI widgets in browsers)
In message hb0sf5+2xbwff...@pigsonthewing.org.uk, in February 2007, I wrote: In message 8434a459-7c78-42f8-bef6-98e6f0a5d...@w3.org, Karl Dubost k...@w3.org writes I think there is a possible win-win here. The Mozilla UI widget could be activated only when the right URI (profile attribute) is really here. What proportion of pages currently marked up with microformats use the correct profile, and do so correctly? I've created http://microformats.org/wiki/profile-examples-in-wild to collect examples. In case anyone's searching the archives for that, it ended up at: http://microformats.org/wiki/profile-uri-examples-in-wild but hasn't been maintained. -- Andy Mabbett
[whatwg] Coordinates and measurements in HTML5
In message zxed4ttdzyojf...@pigsonthewing.org.uk, I wrote: Another abuse of ABBR in microformats for coordinates: abbr class=geo title=52.548;-1.932Great Barr/abbr Bruce and I agree that this could be resolved, and HTML5 usefully extended, by a “location element: location latitude=52.548 longitude=-1.932Great Barr/location Using the “schema attribute shown above, for non-Gregorian dates, we can extend that for Martian, Lunar (and eventually other bodies): location schema=moon latitude=52.548 longitude=23.47297Sea of Tranquility/location and for nonWGS84 coordinates, in a manner similar to that I described in my proposals to extend the related Geo microformat: http://microformats.org/wiki/geo-extension-nonWGS84 and in message llwnu2ch9dpjf...@pigsonthewing.org.uk, I wrote: a more widely-scoped measurement element, capable of taking, for example, values of duration, length, mass, temperature, etc.; and a value; and perhaps a schema (defaulting to SI), would perhaps be more useful. Use cases are microformats, plus translation, automated conversion, sorting, etc. which might look like: measure type=length5cm/measure or: measure length=2.5cm1 inch/measure Those suggestions seem to have been lost, in the discussion of time Any thoughts? Bruce subsequently preferred place for the former, while on reflection, I think geo might be more appropriate, given that it's derived from the geo property in vCard. -- Andy Mabbett
Re: [whatwg] Historic dates in HTML5
In message 10c0368b-e984-42a7-933f-b7cb6f1f2...@iki.fi, Henri Sivonen hsivo...@iki.fi writes On Mar 5, 2009, at 01:29, Jim O'Donnell wrote: Is there any suitable markup in HTML5 for dates in digitised documents from museums, libraries and archives? What would consuming software do with those dates? I have already described some of the many use-cases for such dates, in: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018639.html et seq. The time element is meant as a replacement for the microformat abbr design pattern in hCalendar Is it? What about the other abuses of ABBR in microformats, such as for coordinates and duration: abbr class=duration title=PT5M48S5:48/abbr ? (if the microformat community embraces time; if not, time in pretty much pointless in HTML5). What about the use-cases which I have described, most of which are not dependent on microformats? The expected use cases of hCalendar are mainly transferring *future* event entries from a Web page into an application like iCal. Are they? Could you provide a citation for that? The hCalendar spec doesn't include a definitive set of use-cases (indeed, hardly any at all - but then it doesn't even include a full set of hCalendar parameters), but it does explicitly refer to writeups of past events. Many of the hCalendar microformats which I've seen published are for historic events, such as those on Wikipedia, for example: Launch of Sputnik 1: http://en.wikipedia.org/wiki/Sputnik_1 Marriage Act, 1753: http://en.wikipedia.org/wiki/Marriage_Act_1753 Are you suggesting that they are in some way in breach of the hCalendar spec? If so, how?? You also seem to overlook that dates are not used not only in hCalendar, but also in other microformats, such as hAtom (for dating feeds) , and hCard (for people's birth dates), for example: Sir Tim Berners-Lee: http://en.wikipedia.org/wiki/Tim_Berners-Lee Anthony of Saxony: http://en.wikipedia.org/wiki/Anthony_of_Saxony The only limit on the use of dates in microformats is that they currently rely on ISO8601, which is restricted to Gregorian dates (chiefly after 1750, but see: http://en.wikipedia.org/wiki/Gregorian_calendar for the complex change-over dates in different countries). This was identified as an issue with the hCalendar specification in September 2006: http://microformats.org/wiki/hcalendar-issues#2006 and is still awaiting a solution, hence my proposal for allowing non-Gregorian dates in time (at the first URL given above). -- Andy Mabbett
Re: [whatwg] Dates and coordinates in HTML5
In message 49a5d6e8.5070...@lachy.id.au, Lachlan Hunt lachlan.h...@lachy.id.au writes [Resending this to the list now that the problem that prevented it from accepting any mail has been fixed.] [Likewise] Andy Mabbett wrote: Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (find me all the pages about events in 1923 — recent developments in Yahoo's YQL searching API (which now supports searching for microformats): http://developer.yahoo.net/blog/archives/2009/01/yql_with_microformats .html have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a SIMILE http://simile.mit.edu/timeline/ or similar time-line. Neither of those appear to be using BCE dates, non-Gregorian calendars or imprecise dates. It's not clear how they are use cases for the features that you are asking for. I haven't tried using Yahoo to search for BCE or imprecise dates (I don't have the coding sills to construct such a search), but I don't see why that wouldn't work, since both are supported and published in hCard/hCalendar and ISO8601, and Yahoo say they support hCard/hCalendar, which use ISO8601. Incidentally, the time element and BCE dates are both supported by the microformat parser Swignition: http://buzzword.org.uk/swignition/ If Yahoo aren't supporting searches for such non-Gregorian dates, that's probably because there is currently no method of marking them up. Do we really have to illustrate use cases in action, before we can develop the technology which allows them to be demonstrated exists? On the other hand, this SIMILE timeline has dates which are BCE, imprecise and non-Gregorian: http://simile.mit.edu/timeline/examples/dinosaurs/dinosaurs2.html I note that you make no comment about the other use-cases I gave. -- Andy Mabbett
Re: [whatwg] Dates and coordinates in HTML5
In message 7c2a12e20902241613v7ba27c60q433fd84a74279...@mail.gmail.com, Aryeh Gregor simetrical+...@gmail.com writes the emphasis on clear and immediate use-cases. I didn't notice you mentioning any of those in your posts. What are some examples of actual, concrete applications with user-visible functionality that would be aided by extending time as you propose? I'm surprised that you missed all this: I have considerable experience of marking up dates in microformats, [...] for historic events, on Wikipedia and Wikimedia Commons. [...] Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (find me all the pages about events in 1923 — recent developments in Yahoo's YQL searching API (which now supports searching for microformats): http://developer.yahoo.net/blog/archives/2009/01/yql_with_microformats.html have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a SIMILE http://simile.mit.edu/timeline/ or similar time-line. They can be translated into other languages more effectively than raw prose; they can be disambiguated (does “5/6/09 mean “5th June 2009? or “6th May 2009?); and they can be presented in the user's preferred format (I might want to see “5th June 2009; you might see “June 5, 2009 — such presentational preferences have generated arguments of little-endian proportions on Wikipedia). hCalendar microformats are already used to mark up imprecise dates (June 1977; 2009) [...] Surely the use case for marking-up a sortable table of Roman emperors, should allow all such emperors, and not just those who ruled from 0001AD, to be included? in my original post. -- Andy Mabbett
Re: [whatwg] Dates and coordinates in HTML5
In message 49a3e9b9.4090...@lachy.id.au, Lachlan Hunt lachlan.h...@lachy.id.au writes Andy Mabbett wrote: It seems to me that there are several outstanding, and overlapping, issues for time in HTML5, which include use-cases, imprecise dates, Gregorian vs. non-Gregorian dates and BCE (aka “BC“) dates. The time element was primarily designed to address use cases involving contemporary dates. It doesn't address non-Gregorian calendars or BCE dates by design, as it is not really meant for historical dates. Yes; and it is that narrow approach with which I take issue. Probably the most historical dates that it would really be suitably optimised for are people's birthdates, Why? Why are those dates more worthy of being semantically marked-up than, say, the date of the sailing of the Mayflower, of the birthdate of Caesar? [...] These issues have all been discussed before, either here in the whatwg or on public-html, and so I won't go into great detail. I did make a point of saying: I've read up on what prior discussion I can find on the list; but may have missed some. I'll be happy to have anything I've overlooked pointed out to me. First, though, I should like to make the observation that, while hCalendar microformats are most commonly used to allow event details to be added to calendar apps, and that that use case drove their development, they should not be seen simply as a tool to that end. I see them, and hope that others do, as a way of adding semantic meaning to mark-up; and that's how I view the “time element, too. Once we indicate that the semantic meaning of a string of text is date, it's up to other people to decide what they use that for — let a thousand flowers bloom, as the adage goes. I think this is a philosophical difference in approach from that which we used in developing the time element, and other features in HTML5. Semantics for the sake of semantics are not, and should not be, a design goal. I am not proposing semantics for the sake of semantics; I am showing that the semantics are already deployed, and that once deployed, the potential use cases are more varied than the current examples. [...] While it may seem like a logical step to go from supporting those real use cases, to supporting theoretical cases involving BCE dates, Julian calendars, leap seconds and whatever else, this actually only ends up introducing unnecessary complexity. The use-cases I gave are not theoretical. Is the complexity really unnecessary, or are we just putting off a difficult piece of work? Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching... Yes, but the question is, are any of the use cases involving historical dates really worth addressing with the time element? If so, what are those use cases and why are they significant enough? The uses cases are in the paragraph you only quote partially, above. I think they are all worth addressing (indeed, I think it would be foolhardy not to), and I'm not alone in thinking so. How do you propose to measure their worth objectively? hCalendar microformats are already used to mark up imprecise dates (June 1977; 2009). ISO8601 already supports them. Why not HTML5? Though care needs to be taken, it's even possible to mark up words like “today with a precise date, if that's generated real-time, server-side. What are the use cases for marking up such imprecise dates? Are people using hCalendar for such purposes? Yes, as I say in the text you quote; and on the sites I gave in my introduction (and unambiguously supported by the hCalendar specification and ISO8601). Use cases as above. The issue of non-Gregorian (chiefly Julian) dates is a vexing one It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like: time schema=[schema-name] datetime=[value][date in plain text]/time Developing such a solution without having clear use cases and a good explanation of why addressing those use cases is worthwhile, is not a good use of our time. Again, use cases have been given. Why do you feel that they are not clear? Even more so because you're trying to make room for a hypothetical solution of marking up Julian dates that doesn't yet exist. No; I'm proposing a solution which allows non-Gregorian date schemas to be used. As for BCE dates, they're already allowed in ISO 8601 (since there was no year 0, the year 3 BCE is given as -0002 in ISO 8601). I see no reason why they should be disallowed in time elements in HTML5. Because allowing them requires additional effort, such as changes to the parsing requirements, for which there is little to nothing gained in practice due to a lack of compelling use cases. Again: why are the use cases given not acceptable
Re: [whatwg] Dates and coordinates in HTML5
In message 619d9f095a7941eebcbb05fd4b03f...@pirate, WeBMartians webmarti...@verizon.net writes Although it can be argued that a standard should not consider the work required for implementation, many of the trade-offs in reference to times and dates do indeed take the present state of code into consideration. What's the expected end-of-life date for HTML5? Do we really want to hamstring ourselves 'til then, by considering only current, as-of-2009, capabilities? One reason for not supporting BCE is a disagreement between historians and, say, astronomers, on how to represent the year immediately preceding year one. Is it year -1 (1 BCE) or year zero? ISO 8601 is, I understand, unequivocal on that matter. [...] I do see the no BCE compromise as a workable one. That's an interesting use of compromise! -- Andy Mabbett
[whatwg] Dates and coordinates in HTML5
longitude=-1.932Great Barr/location Using the “schema attribute shown above, for non-Gregorian dates, we can extend that for Martian, Lunar (and eventually other bodies): location schema=moon latitude=52.548 longitude=23.47297Sea of Tranquility/location and for nonWGS84 coordinates, in a manner similar to that I described in my proposals to extend the related Geo microformat. Now all we need to do is to work-around the abuse of ABBR for durations, in the draft hAudio microformat: abbr title=PT3M23S3 minutes 23 seconds/abbr -- Andy Mabbett
[whatwg] TH scope=TBODY
Hello, I can imagine instances where it would make sense to allow: TH scope=TBODY (or =THEAD/ TFOOT, for that matter) before I expand on that, has anyone made similar suggestions previously, or done any related work (I have searched, without success)? Or does scope=ROWGROUP cover that? -- Andy Mabbett
[whatwg] List captions
How often do we see something like: pAnimals:/p ul liCat/li liDog/li liHorse/li liCow/li /ul This would be more meaningful as: ul caption=Animals liCat/li liDog/li liHorse/li liCow/li /ul There could also be a summary attribute, as with tables. Any interest? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ?
Re: [whatwg] List captions
In message [EMAIL PROTECTED], Magnus Kristiansen [EMAIL PROTECTED] writes On Fri, 06 Apr 2007 14:31:58 +0200, Andy Mabbett [EMAIL PROTECTED] wrote: How often do we see something like: pAnimals:/p ul liCat/li liDog/li liHorse/li liCow/li /ul This would be more meaningful as: ul caption=Animals liCat/li liDog/li liHorse/li liCow/li /ul There could also be a summary attribute, as with tables. Any interest? We should do our best to avoid repeats of alt, title, and friends. Why? A list header would go much better as a separate element, like caption is for tables. Like: ul captionAnimals/caption (or lh, or whatever) liCat/li liDog/li liHorse/li liCow/li /ul Yes, that would work, too. The resurrection of lh was proposed a few days ago on this very list, why not take a look at that thread? Great minds think alike! ;-) -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ?
Re: [whatwg] Should address be more general-purpose?
In message [EMAIL PROTECTED], Simon Pieters [EMAIL PROTECTED] writes should address be more general-purpose? what benefit would that have, over the adr microformat? http://microformats.org/wiki/adr The latter has better granularity, allowing for street-address, locality, region, country and postcode, for example, to be marked up separately. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ?
[whatwg] Profiles in-the-wild (was:Microformats, WebApps 1.0 and UI widgets in browsers)
In message [EMAIL PROTECTED], Karl Dubost [EMAIL PROTECTED] writes I think there is a possible win-win here. The Mozilla UI widget could be activated only when the right URI (profile attribute) is really here. What proportion of pages currently marked up with microformats use the correct profile, and do so correctly? I've created http://microformats.org/wiki/profile-examples-in-wild to collect examples. -- Andy Mabbett http://www.pigsonthewing.org.uk/uFsig/ Welcome to the 29-day week!
Re: [whatwg] [uf-discuss] Microformats, WebApps 1.0 and UI widgets in browsers
In message [EMAIL PROTECTED], Kevin Marks [EMAIL PROTECTED] writes On Jan 31, 2007, at 11:25 PM, Karl Dubost wrote: At first, I say “cool, very cool!”. Then, taking a step back, I think what about the documents which have been created for the last 15 years before microformats effort existed. These documents contain class names which are probably and most certainly very similar to some values defined by microformats community. Karl, can you document instances of use of 'vcard', 'vevent', 'hfeed,' 'hresume', 'hreview' etc before microformats defined them? Very similar isn't an issue; exactly identical is. I shouldn't be in the least surprised if geo wasn't already in use somewhere, and probably adr Also, given that, after sending vast amounts of money, multinational companies still mange to release models of cars with names which translate into things like you smell in certain territories, what efforts have been made to check that, say, hfeed doesn't mean, say, menu in some language or other? -- Andy Mabbett http://www.pigsonthewing.org.uk/uFsig/ Welcome to the 29-day week!
Re: [whatwg] microformats incompatible with WebApps 1.0 ?
In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes Maybe you mean to distinguish microformat from Microformat? Hehe. I used that distinction on uf-discuss simply for the purpose of communicating, and got slapped for potentially creating a meme. ;-) s/creating/describing ;-) -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ?
Re: [whatwg] rel-index comments
In message [EMAIL PROTECTED], Anne van Kesteren [EMAIL PROTECTED] writes For rel-index and such you expect more a long list of words or various chapters with links to the various documents provided from there. I'd expect an index to be an alphabetical list, like: http://www.birmingham.gov.uk/a rather than list of chapters. Think of the index at the back of a book, as opposed to the contents page at the front. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk
