Intent to implement (and ship?): <time>

[Philip Jägenstedt]

Hi all,

Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element

<time> has some history and used to be more complicated, but was
simplified a while back and has stayed put since. I think it's so
simple that we should either decide to ship it or not bother at all,
but I can use a flag if required.

(Investigating implementation effort quickly turned into
implementation, so I actually already have a review
<https://codereview.chromium.org/28953005> lined up, but please ignore
that until this intent has been accepted or rejected.)

Philip

[Erik Arvidsson]

What does this mean?

"A time element that does not have a datetime content attribute must not have any element descendants."

Enforcing that does not seem like a good thing.

--
erik

[Michael[tm] Smith]

Erik Arvidsson <a...@chromium.org>, 2013-10-18 14:27 -0400:

> What does this mean?
>
> "A time element that does not have a datetime content attribute must not
> have any element descendants."
>
> Enforcing that does not seem like a good thing.

It's not specifying anything for UAs to enforce. It's a
document-conformance requirement for authors, not an
implementation-conformance requirement for UAs.

--Mike

--
Michael[tm] Smith http://people.w3.org/mike

[Eric Seidel]

What does it mean for it to be a "document conformance requirement for authors"?

Sounds like something which Blink doesn't need to do anything for.
Authors can chose to use a <time> elements to denote their times if
they like or not...

[Dimitri Glazkov]

I think it's one of those <maincontent> cases, where the value of adding this element to HTML is hard to determine objectively (you'll have at least two divergent opinions on that) and the impact on the codebase is too low for strong technical objections. The battles are so fierce because the stakes are so small.

:DG<

[Michael[tm] Smith]

Eric Seidel <ese...@chromium.org>, 2013-10-21 10:11 -0700:

> What does it mean for it to be a "document conformance requirement for authors"?

It means there are some restrictions in the spec for what particular markup
cases are considered valid in documents but that are unrelated to how UAs
parse and process that markup.

http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#conformance-requirements-for-authors

Like, the spec says <table><hr> is not valid markup, so authors shouldn't use
it (and the validator will emit an error for it), but despite that the spec
then also places specific requirements on how <table><hr> must be parsed.

> Sounds like something which Blink doesn't need to do anything for.

Yeah, Blink doesn't need to do anything with the "A time element that does

not have a datetime content attribute must not have any element

descendants" requirement.

> Authors can chose to use a <time> elements to denote their times if
> they like or not...

Yeah, I would think implementing support for <time> in blink basically just
amounts to implementing support for the HTMLTimeElement interface (the sole
purpose of which seems to be to reflect the value of the datetime attribute).

--Mike

[Michael[tm] Smith]

Dimitri Glazkov <dgla...@chromium.org>, 2013-10-21 10:12 -0700:

Yeah, I think that's not a completely inaccurate way to describe it.

--Mike

P.S., Myself I'd rather <time> didn't exist, because unlike the low cost
for implementing it in UAs, in the case of implementing support for it in
the validator I have to add special parsing and error checking/reporting for
the baroque set of nearly a dozen different microsyntax/datatypes the spec
says it's allowed to have -- a lot of which I'm not personally aware of any
valid use cases for.

[Eric Seidel]

I see. This seems like something much better handled by
custom-elements (once we get that):

var HTMLTimeElement = document.register('time', {
prototype: Object.create(HTMLElement.prototype, {
datetime: {
get: function() { return this.getAttribute('datetime'); }
set: function(value) { return this.setAttribute('datetime'); }
}
});

That's certainly *much* safe/simpler than adding any more C++ code to Blink. :)

[Eric Seidel]

To make it official: not lgtm. We have much bigger fish to fry than
this tiny piece of confusion in HTML5.

[Philip Jägenstedt]

OK, this will have to wait until it becomes required for site compat,
if that ever happens. Thanks for your input, everyone!

[Ian Hickson]

On Mon, 21 Oct 2013, Eric Seidel wrote:
>
> I see. This seems like something much better handled by
> custom-elements (once we get that):
>
> var HTMLTimeElement = document.register('time', {
> prototype: Object.create(HTMLElement.prototype, {
> datetime: {
> get: function() { return this.getAttribute('datetime'); }
> set: function(value) { return this.setAttribute('datetime'); }
> }
> });
>
> That's certainly *much* safe/simpler than adding any more C++ code to Blink. :)

There's four main purposes for <time>:

- helping authors who want to mark up times and have a reliable way to do
so, for internal purposes. Browsers don't need to do much for this; as
you say, the above would be sufficient.

- in the future, providing a place for hooking localisation of
time-related values, should CSS provide a way to do that. This is
currently academic since CSS doesn't provide this.

- a place for giving time-related values when doing stuff with microdata.
Browsers aren't really affected by this (there's some minor stuff
involved if you have the microdata DOM API, but that's all).

- integration with the table sorting model. This one requires significant
work to be implemented in the browser; the times have to be parsed,
their type has to be identified, etc.

Basically, whenever there's something related to encoding times in HTML,
the <time> element is what gets used. Except for sorting, this has very
little impact on HTML.

The sorting model hasn't received much review from browser vendors; I'm
curious to hear what y'all have to say about it. It was designed to take
care of a quite wide variety of needs, so there's quite a lot to it, but
it's described in quite a lot of detail, so it should be relatively
straight forward to implement. It's certainly something a lot of authors
have been asking for. The API it exposes to authors is really simple given
the amount of power it packs.

http://whatwg.org/html#table-sorting-model

(Note: There's an open question about how to handle cells with two types
of data that I haven't dealt with yet.)

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'