It”s easy to scope the latter, but not the former.

…But the latter can and should be stored as a precise datum, because in all likelihood its apparent format will be implemented programmatically.

Of greater concern to me are ranges and approximate timestamps — to the extent that I share your skepticism, it’s because I’m not entirely certain that those use cases can be easily contained within the value of a single attribute.

The yellow bit, the sentence of ‘Proposed Solution’ in the ‘Review of Data Section’ reads ‘If that is the body than the footer is secondary content to the document as a whole.’ and should probably read ‘If that is the body, then the footer is secondary content to the document as a whole.’

The first sentence of the last paragraph ‘ABSENT ELEMENTS AND ATTRIBUTES’ reads ‘….even if their loss makes some us feel rather….’ and probably should read ‘…even if their loss makes some of us feel rather…’

Thanks,
Dunc

Why do you think this isn’t the right answer? Just want to hear what you’ve been thinking.

I’ve been mulling over time this week, and the one thing I keep coming back to is that ISO 8601 and RFC 3339 are tuned to handle hyper-specific points in time (down to the millisecond with RFC 3339). RFC 2445, from which iCalendar and hCal follow, uses ISO 8601 to define machine-readable dates and times.

So I’ve been left wondering if we’re at cross-purposes with time. The HTML5 spec wants it to work for calendaring, where minute-level accuracy would be important. The general community wants a tag to semantic mark up specific dates, even if they’re these general dates (or even those pesky estimations, like “c.1000″). But if we’re being governed by these ISOs and RFCs around dates, those general dates just don’t work. We’d either need to revise ISO 8601 to take non-specific dates, or we’d need to kludge something from the patterns encased in ISO 8601 and hope that the calendaring programs would know what to do with them (or just ignore them).

I worry, like with calendar, this is going to be a completely misunderstood tag. time will either need a very specific definition (i.e. only for calendaring) or a very open one (i.e. open to months/years/ranges), and each definition appears to contraindicate one of the two possible usages.

The specification does not just serve us web developers as page authors. It serves the browser vendors — _any_ browser vendor, now and in the future — in building a rendering engine that behaves compatibly with the open web. That is a complex problem, and requires depth and precision in specification to be achievable. The process is made harder because a lot of this detail work was never produced for features of HTML3 and HTML4, so it’s happening now.

The way I would expect this to play out is as follows: The HTML5 specification as a single document will not be the document that serves front-end developers directly. It won’t be the go-to reference in the way that HTML4.01 is. Once HTML5 is stable (perhaps when it reaches Last Call in October) separate, companion documents will be produced. “HTML5 for Content Authors”, you might call it. It will cover the content of HTML5 at the correct depth and breadth for developers.

I think a lot of people are concerned that the huge HTML5 spec is going to be their only reference. It won’t be. Either from the working group itself or from enterprising others, audience-focused but no-less accurate reference works will come. But, you must understand, such documents cannot be produced accurately or in an efficient use of the author’s time until HTML5 itself is stable. For now, whilst HTML5 is still in active development, it is necessary that you go to the extra effort — as the HTML5 Super Friends have done — to consume a spec that is in part “not for you”.

Kudos to those who do take the time.

Is the address element as currently specified in HTML 5 an improvement?

Robert, I do have that very much in mind, and that will probably be the subject of my next post.

Thanks, Bob. My wife really likes that shirt, too.

And I really like the color blue of that t-shirt you were wearing.