Bug 68156

Summary: HTML5 <time> initial implementation
Product: WebKit Reporter: Vineet Chaudhary (vineetc) <code.vineet>
Component: HTML DOMAssignee: Nobody <webkit-unassigned>
Status: UNCONFIRMED ---    
Severity: Normal CC: abarth, donggwan.kim, eoconnor, eric, ian, jdiggs, jonlee, kihong.kwon, lquinn, ojan, simon.fraser, syoichi, tkent, webkit.review.bot
Priority: P2 Keywords: HTML5
Version: 528+ (Nightly build)   
Hardware: All   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 32934, 40829    
Attachments:
Description Flags
time element initial patch
none
Test Case
none
time_element_initial_patch_01
tkent: review-
updated_patch none

Description Vineet Chaudhary (vineetc) 2011-09-15 05:44:57 PDT
The main objective is to add the files for html elements also providing the initial implementation to support the tag.
Latest Opera(11.51) also have support for this.

Specification reference:
http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element
Comment 1 Vineet Chaudhary (vineetc) 2011-09-15 05:49:50 PDT
I am considering this bug as Master Bug for time tag implementation.
Comment 2 Vineet Chaudhary (vineetc) 2011-09-15 06:03:46 PDT
Created attachment 107484 [details]
time element initial patch
Comment 3 Vineet Chaudhary (vineetc) 2011-09-15 06:15:02 PDT
Attached patch consist of initial implementation of HTML5 time tag.
Below listed items are work in progress.

1) If datetime attribute is not present, then the element's textContent must be considered if valid.
2) pubdate needs to be supported.
Comment 4 Vineet Chaudhary (vineetc) 2011-09-15 06:24:38 PDT
Created attachment 107486 [details]
Test Case

Attached test case explains the usage of time tag.

Also can someone help me to add the new files to xcode project.
Comment 5 Alexey Proskuryakov 2011-09-15 10:27:35 PDT
Please announce this work on webkit-dev mailing list.
Comment 6 Kent Tamura 2011-09-15 17:50:08 PDT
Comment on attachment 107484 [details]
time element initial patch

View in context: https://bugs.webkit.org/attachment.cgi?id=107484&action=review

> Source/WebCore/html/HTMLTimeElement.cpp:2
> + * Copyright (C) 2010 Apple Inc. All rights reserved.

Why does this have Apple copyright?

> Source/WebCore/html/HTMLTimeElement.cpp:58
> +        // <TO_DO> set a bool var and notify the nearest artical element @ this date.

Why do we need to notify?

> Source/WebCore/html/HTMLTimeElement.cpp:86
> +    if (m_dateComponents.type())

Should compare with DateComponents::Invalid.

> Source/WebCore/html/HTMLTimeElement.cpp:88
> +    return 0;

You must not return 0. The specification says we must return null Date in this case.
Comment 7 Vineet Chaudhary (vineetc) 2011-09-19 04:12:15 PDT
Created attachment 107832 [details]
time_element_initial_patch_01

Thanks Kent Tamura for the review comments,
Please find the updated patch.

> + * Copyright (C) 2010 Apple Inc. All rights reserved.
> Why does this have Apple copyright?
Copyrights updated

> Source/WebCore/html/HTMLTimeElement.cpp:86
> +    if (m_dateComponents.type())
> Should compare with DateComponents::Invalid.
Done.

> Source/WebCore/html/HTMLTimeElement.cpp:88
> +    return 0;
> You must not return 0. The specification says we must return null Date in this case.
Corrected.

Also checking if datetime attribute is not present, then the element's 
textContent must be considered if valid.
Comment 8 Kent Tamura 2011-09-19 08:25:22 PDT
Comment on attachment 107832 [details]
time_element_initial_patch_01

No tests in this patch.
Comment 9 Ian 'Hixie' Hickson 2011-09-19 15:24:21 PDT
Please see https://lists.webkit.org/pipermail/webkit-dev/2011-September/018009.html
Comment 10 Vineet Chaudhary (vineetc) 2011-09-20 06:54:12 PDT
My motive to implement this tag is fill the gap between specification and webkit and considering potential usage could be in the Calenders(to set the event), blogs & news feeds where <time> may add more semantic.

But as there is an active discussion going on http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 this thread about replacing <time> with <data>, So I think we should revisit this implementation after the closer of mentioned bug.

Please guide me if anyone have second thought on this.
Comment 11 Vineet Chaudhary (vineetc) 2011-11-11 09:49:35 PST
Created attachment 114719 [details]
updated_patch

(In reply to comment #8)
> (From update of attachment 107832 [details])
> No tests in this patch.

Added tests with patch.
As a part of discussion going http://lists.w3.org/Archives/Public/public-html/2011Nov/0011 <time> is again to added in w3c-spec.
May I start working on this again and have this basic implementation as template for Time Element?
Comment 12 Kent Tamura 2011-11-13 18:06:58 PST
(In reply to comment #11)
> As a part of discussion going http://lists.w3.org/Archives/Public/public-html/2011Nov/0011 <time> is again to added in w3c-spec.
> May I start working on this again and have this basic implementation as template for Time Element?

The status of <time> is not clear yet. e.g. WHATWG specification still has no <time>.
IMO, we should not start the implementation yet.
Comment 13 Adam Barth 2011-11-13 22:55:54 PST
Yeah, <time> seems to be in serious state of flux.  Let's let things settle down a bit before jumping in here.
Comment 14 Ian 'Hixie' Hickson 2011-11-18 16:30:19 PST
I just uploaded a proposal for a new <time> to the HTML spec on the WHATWG site. Still in flux, but now's a good time to send feedback.
Comment 15 Vineet Chaudhary (vineetc) 2011-11-19 01:19:53 PST
Thank you Hixie for updates.

As I see here are few updates with new implementation. 
Ref : http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element

1) Now there are no pubDate(can used with itemprop) and valueAsDate attribute but datetime.

2) The datetime value of a time element is the value of the element's datetime content attribute, if it has one, or the element's textContent, if it does not.

Just a query do we really don't want previous "Date valueAsDate" attribute as it could be useful to get date or time in the form of Date object.
Comment 16 Ian 'Hixie' Hickson 2011-11-19 21:20:17 PST
The plan regarding the API is to see what people do with the element before deciding what API to expose. (In practice so far most usage of the element that I have seen would have no use for an API.)