I am considering this bug as Master Bug for time tag implementation.

Created attachment 107484 [details] time element initial patch

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.

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.

Please announce this work on webkit-dev mailing list.

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.

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 on attachment 107832 [details] time_element_initial_patch_01 No tests in this patch.

Please see https://lists.webkit.org/pipermail/webkit-dev/2011-September/018009.html

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.

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?

(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.

Yeah, <time> seems to be in serious state of flux. Let's let things settle down a bit before jumping in here.

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.

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.

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.)

This element has an implementation now.