- From: Hugh Guiney <hugh.guiney@gmail.com>
- Date: Thu, 10 Dec 2009 12:52:06 -0500
On Thu, Dec 10, 2009 at 9:06 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote: > Are you planning on using the information in <time> to *do* the > sorting? ?That is, when someone chooses "sort by date", do you have > scripting that searches in each section for a <time> and extracts the > date to determine where in the order it should go? Yes, ideally I would like to store all of my data as XHTML+XML. Though I suppose I could describe that data with an arbitrary vocabulary server-side, sort on that, and transform the result into HTML, it makes the script much smaller and easier to write if there's a common syntax in place. > Fairness isn't a justification for putting anything in the spec, > fortunately. ?Each piece of the spec has to justify itself. It just seems to me that *requiring* this sort of specificity (rather than simply allowing it) is contrary to the typically rather permissive nature of HTML. If we don't even need to close our tags, why do we need to specify whole dates? As far as I know, there hasn't ever been an element that made validation fail because of a malformed microsyntax; why start now? ISO 8601 (which has been footnoted by the W3C since 1997) allows for several levels of granularity, up to the year. What is it that necessitates this particular level of granularity (aside from adding dates to calendars, which is only one use case)? > I agree with Meyer on the first one. ?That's a useful case. ?In > addition, <time>'s usefulness in Microdata is somewhat impaired by its > inability to mark up months or years. ?These are by far the most > common 'fuzzy dates' that one would have to mark up for embedded > metadata. ?Their lack means that vocabularies need to structure > themselves to take two dates per real 'date', to allow such fuzziness, > which means that date *ranges* would need *four* dates specified. > That's just silly. I agree. > However, the second one isn't quite an argument for expanding time. > It's an outlining of, *if* we decide that we want <time> to be useful > for *all* dates, how we should go about doing it. ?ppk recognizes that > such an approach may not be what the spec wants. I realize that, but the fact that he was able to write that much on the topic just strengthens the argument that <time> has far more use cases than it's been allotted, and as such, its current definition needs to be addressed, be it in that capacity or smaller.
Received on Thursday, 10 December 2009 09:52:06 UTC