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] Geographic hyperlinks
The RFC already includes such a facility. On 10 October 2011 20:26, Christoph Päper wrote: > Tantek Çelik: > >> See RFC 5870[1] for a proposed standard geo URI scheme for "geo:" hyperlinks. > > I wonder whether this scheme, someday, will be extended to include a domain > part, e.g. geo:13.4125,103.8667@mars, or whether we’ll rather get a ‘astro:’ > scheme. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] a rel=attachment
On 16 July 2011 02:20, Peter Kasting wrote: > On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik wrote: > >> * 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] a rel=attachment
2011/7/14 Ian Fette (イアンフェッティ) : > Many websites wish to offer a file for download, even though it could > potentially be viewed inline (take images, PDFs, or word documents as an > example). Traditionally the only way to achieve this is to set a > content-disposition header. *However, sometimes it is not possible for the > page author to have control over the response headers sent by the > server.*(A related example is offline apps, which may wish to provide > the user with > a way to "download" a file stored locally using the filesystem API but again > can't set any headers.) It would be nice to provide the page author with a > client side mechanism to trigger a download. > > After mulling this over with some application developers who are trying to > use this functionality, it seems like adding a "rel" attribute to the > tag would be a straightforward, minimally invasive way to address this use > case. would indicate that the browser > should treat this link as if the response came with a content-disposition: > attachment header, and offer to download/save the file for the user. How would this be different to the already-available rel="enclosure" ? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] Interpretation issue: can be used for "extended paragraphs"?
On 14 June 2011 08:32, Ian Hickson 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 be used for "extended paragraphs"?
On 10 March 2011 08:20, Jukka K. Korpela 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: I always like to eat these cheeses: Cheddar Stilton Red Lester but I enjoy them most with one of these biscuits: wheat crackers rye crackers digestives and some chutney. What I would like to be able to do is: I always like to eat these cheeses: Cheddar Stilton Red Lester but I enjoy them most with one of these biscuits: wheat crackers rye crackers digestives and some chutney. Now I'm hungry :-( -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Re: [whatwg] element in HTML5 Spec?
Perhaps what is needed is some kind of "in-reply-to" attribute: I like beer Me too! or even: I like beer Me too! On 14 December 2010 17:41, Richard Summers wrote: > Thanks for the feedback guys, really appreciate it. > > Using elements within other elements feels a bit like > we'd just be replacing for , 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 (or similar) element, as suggested by Bruce Hyslop? > > A ,or similar, (?) 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 element. > > Thoughts? > > Rich > > > On 13/12/2010 19:23, "Tab Atkins Jr." wrote: > >> On Mon, Dec 13, 2010 at 10:49 AM, Richard Summers >> 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 element within the >>> HTML5 spec? I¹m suggesting this as a complimentary element to the >>> 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 of their own (as >> each is a piece of independent content). >> >> What benefits could be brought along by instead using ? 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 s like that, >> authors could just naturally gravitate towards using and >> together. >> >> One thing to note - 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 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 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= (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 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] Please consider adding a couple more datetime 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 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 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 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]
In message <20090314083450.ga30...@stripey.com>, Smylers 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 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]
In message , David Singer
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:
[date in
plain text]
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]
In message , Geoffrey Sneddon 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]
In message <49b90c20.9040...@lachy.id.au>, Lachlan Hunt 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: > >9–22 April 2009 > > Or would it be better to give the precise date range, as > >9–22 >April, 2009 > > Or would supporting a range directly in the datetime field support > this better: > >9–22 April 2009 > >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: 9 - 22 April 2009 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: > >2009 is The International Year of Astronomy. > >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 ? > >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 ? >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]
> 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 **
[whatwg] Coordinates and measurements in HTML5
In message , I wrote: >Another abuse of ABBR in microformats for coordinates: > >Great Barr > >Bruce and I agree that this could be resolved, and HTML5 usefully >extended, by a “location" element: > >Great >Barr > >Using the “schema" attribute shown above, for non-Gregorian dates, we >can extend that for Martian, Lunar (and eventually other bodies): > >longitude="23.47297">Sea of Tranquility > >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 , 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: 5cm or: 1 inch Those suggestions seem to have been lost, in the discussion of Any thoughts? Bruce subsequently preferred for the former, while on reflection, I think might be more appropriate, given that it's derived from the "geo" property in vCard. -- Andy Mabbett
[whatwg] Profiles in-the-wild (was: Microformats, WebApps 1.0 and UI widgets in browsers)
In message , in February 2007, I wrote: >In message <8434a459-7c78-42f8-bef6-98e6f0a5d...@w3.org>, Karl Dubost > 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
Re: [whatwg]
In message <22c1222d0903091317i4dccafd0peb182de2ba008...@mail.gmail.com>, Tom Duhamel writes >Julian for instance cannot give a precise date In what way is "Henry VIII (28 June 1491 – 28 January 1547)" not precise? >Wikipedia is often mentioned as a use-case, but based on my own experience >(I am not an historian or anything, so my use of Wikipedia for historical >events is sporadic) they most usually convert Julian dates to the Gregorian >calendar. Julius Caesar died in 14 BC, not 52 of the Julius era on the >Julian calendar (or whatever date it would convert to). The above dates are from Wikipedia. >Gregorian calendar entered common use somewhere during the 15th century, I >believe. It was first proposed in 1582 but was not widely used until later: <http://en.wikipedia.org/wiki/Gregorian_calendar> >Dates in 16th, 17th, 18th, 19th and 20th centuries are very common. >Dates before the 15th centurie are less common I think there were still ~365 per year ;-) >they are usually not precise >(just 14th century, for example, as the exact year cannot be determined), >but there are cases where the exact date is known. Julius Caesar is one >instance where a precise date is known (for both his birth and death) and >this is around 50 BC. I don't think there are many known precise date before >that. Thee are in some fields, for instance astronomy, when the exact times of eclipses can be calculated; or the appearance of the night sky on a given date can be determined. >I would accept that dates before year 1 be not represented. You have just represented one, in your preceding paragraph. Why should an author not be able to do so on a web page? -- Andy Mabbett
Re: [whatwg]
In message <20090309215532.ga3...@stripey.com>, Smylers 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 April 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
Re: [whatwg]
In message , Jim O'Donnell 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 Feb. 11, 1731. 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]
In message , David Singer writes At 3:22 +0100 10/03/09, Charles McCathieNevile wrote: That format has some serious limitations for heavy metadata users. In particular for those who are producing information about historical objects, from British Parliamentary records to histories of pre-communist Russia or China to museum collections, the fact that it doesn't handle Julian dates is a big problem - albeit one that could be solved relatively simply in a couple of different ways. The trouble is, that opens a large can of worms. It may do. Does that mean we ignore the issue? Hope that somebody else will solve it? More than one possible method of dealing with Julian dates has been proposed, and I'm sure that I'm not alone in being open to further ideas. Once we step out of the Gregorian calendar, we'll get questions about various other calendar systems (e.g. Roman ab urbe condita <http://en.wikipedia.org/wiki/Ab_urbe_condita>, Byzantine Indiction cycles <http://en.wikipedia.org/wiki/Indiction>, and any number of other calendar systems from history and in current use). Then, of course, are the systems with a different 'year' (e.g. lunar rather than solar). And if we were to introduce a 'calendar system designator', we'd have to talk about how one converted/normalized. How widely - compared to Julian dates - are those published, in the wild? You might be tending towards 'Reductio ad absurdum'. -- Andy Mabbett
Re: [whatwg] Historic dates in HTML5
In message <49b58c3d.5000...@lachy.id.au>, Lachlan Hunt writes >Bruce Lawson quoted Andy Mabbat: Mabbett; as below. >> Andy Mabbett has already listed use cases >> >http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018639 .html >> ... >> They can be mapped visually on a "SIMILE" >> >> <http://simile.mit.edu/timeline/> >> >> or similar time-line. > >It's not clear how such a timeline would make use of the time element >and I couldn't find any use of microformats on that page. Could you >please elaborate on the relevance of that page in regards to this >issue? Neither of us claimed that that site is using microformats (though there is no reason why it could not do so). It was given as evidence that people are publishing historic, non-Gregorian , BCE and low-granularity dates "in the wild"; and as a use case for parsing sets of such dates found on other pages. Furthermore, such timelines can be created from pages which publish microformats (and which could thus use ). An example of a tool to generate a SIMILE timeline from a page with hCalendar microformats is: <http://www.siatec.net/timeline/> and a simple timeline generated using that tool, by parsing the microformats on: <http://en.wikipedia.org/wiki/Survivors_(2008_TV_series)> is: <http://www.siatec.net/timeline/index.php?hcal=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSurvivors_(2008_TV_series)> (aka <http://is.gd/mGJm> ) -- Andy Mabbett
Re: [whatwg] Historic dates in HTML5
In message <10c0368b-e984-42a7-933f-b7cb6f1f2...@iki.fi>, Henri Sivonen 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 element is meant as a replacement for the microformat design pattern in hCalendar Is it? What about the other abuses of ABBR in microformats, such as for coordinates and duration: 5:48 ? (if the microformat community embraces ; if not, 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 (at the first URL given above). -- Andy Mabbett
Re: [whatwg] Dates and coordinates in HTML5
In message <49a5d6e8.5070...@lachy.id.au>, Lachlan Hunt
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 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 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 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 <619d9f095a7941eebcbb05fd4b03f...@pirate>, WeBMartians 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
Re: [whatwg] Dates and coordinates in HTML5
In message <49a3e9b9.4090...@lachy.id.au>, Lachlan Hunt
writes
>Andy Mabbett wrote:
>> It seems to me that there are several outstanding, and overlapping,
>>issues for 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:
>> [date in
>>plain
>> text]
>
>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 date
[whatwg] Dates and coordinates in HTML5
is could be resolved, and HTML5 usefully extended, by a “location" element: Great Barr Using the “schema" attribute shown above, for non-Gregorian dates, we can extend that for Martian, Lunar (and eventually other bodies): Sea of Tranquility 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: 3 minutes 23 seconds -- Andy Mabbett
[whatwg] TH scope="TBODY"
Hello, I can imagine instances where it would make sense to allow: (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
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:
>>
>> Animals:
>>
>> Cat
>> Dog
>> Horse
>> Cow
>>
>>
>> This would be more meaningful as:
>>
>>
>> Cat
>> Dog
>> Horse
>> Cow
>>
>>
>> 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
> is for tables.
Like:
Animals (or lh, or whatever)
Cat
Dog
Horse
Cow
Yes, that would work, too.
>The resurrection of 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/> ?
[whatwg] List captions
How often do we see something like: Animals: Cat Dog Horse Cow This would be more meaningful as: Cat Dog Horse Cow 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] Should be more general-purpose?
In message <[EMAIL PROTECTED]>, Simon Pieters <[EMAIL PROTECTED]> writes >should 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/> ?
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!
[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] 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>
