This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element Currently, we have 'pubdate' attribute for date of _publication_, but there is no way to specify date of article _update_. Publication date and update date are usually used together. One of most obvious examples is any Wiki article which is updated a thousand times after it's created. Another example is any quality website with articles that are updated regularly to maintain they applicability. Currently, update date on such sites is just a date without a special meaning (unlike publication date which has 'pubdate' attribute). Moreover, date of update is often even more important than initial publication date. So we need to add accompanying 'update' boolean attribute to TIME element sothat we could specify both publication and update dates: <time pubdate>2008-01-22</time> <time update>2011-09-14</time> 'update' attribute is similar to 'pubdate' one (it's boolean too and has similar semantic rules), but specifies date of _update_. Thanks.
We're probably going to be dropping <time> altogether. Not sure what we're going to do with pubdate="" (that's actually the main reason I haven't dropped <time> yet). I agree that it would be good to have an update="" value too. We don't really want to do <article pubdate="" update=""> situation, since hidden metadata goes out of date quickly. But I don't really know what else we can do. Opinions?
Syndication could be made some kind of Microdata vocabulary instead of having native support.
Something like this?: <article itemscope itemtype="http://n.whatwg.org/article"> <h1>Example</h1> <p><data value="2011-01-01">January 1 2011</data> (updated <data value="2011-01-02">January 2nd</data>)</p> <p>Hello.</p> </article> Or maybe we could just use the http://schema.org/Blog type (and other types in that schema.org bucket). Any objections to such an approach?
With itemprop attributes on <data> that should be fine I think.
(In reply to comment #1) > We're probably going to be dropping <time> altogether. One of the most odd things I've ever heard as for HTML5 spec development. (Or maybe you are going not to drop <time> at all, but _rename_ it to something more suitable like <date>?) Quite the contrary, it makes sense to add more date-related elements, such as <year> and <month>. In general, there should be dedicated HTML element for _each_ _general_ class of things. This could make possible for robots to determine text sense more accurately and thus provide more relevant parsing results (search results in particular). For example, for search query like "birth year of Some Man", search engine could prefer a year that is marked-up as <year> element instead of making _assumptions_ about whether a number (not marked-up as year) in an indexed text is a year or not. > I agree that it would be good to have an update="" value too. Good. > We don't really want to do <article pubdate="" update=""> situation, since hidden > metadata goes out of date quickly. Reasonable. > But I don't really know what else we can do. Keep the <time> element intact. Only thing to probably do here is maybe rename verbose and to usecase-narrow 'datetime' attribute to more compact and universal 'value' attribute. 'value' attribute could be _consistently_ used in <time>, <year>, and <month> elements (as well as for other elements that are currently noninvented yet). For example: <time value="2011-10-20">October 20, 2011</time> <date value="2011-10-20">October 20, 2011</date> (in case of time->date renaming) <year value="2011">'11</year> <month value="10">October</month> (In reply to comment #3) > <article itemscope itemtype="http://n.whatwg.org/article"> Looks very like to exactly an XML things that have made XHTML inapplicable in real world and have lead to dropping XHTML 2.0 at all in favor of HTML5 langugage which is more _simple_ and usable for _people_. Forgetting about this would be a _big mistake_. Things like itemtype="http://n.whatwg.org/article" are obviously _much harder_ to understand and remember than simple and easy to remember and use things like <time pubdate>. To be clear, things like itemtype="http://n.whatwg.org/article" could exist themselves, but _besides_ of more simple alternatives, _not instead_ of them. Thanks.
For discussion on keeping <time> or not, please see bug 13240.
Why is this an issue within HTML5 spec? The article element is a section within a document that may describe "...any other independent item of content" and has no relation to data markup or temporality. To define partial (even optional) attribute specification of the content is to imply and restrict usage. When an author wants to include and markup the candidate content of blog post, atom entry, etc they would do better to use a chosen schema vocabulary than for html to include a common, yet extraneous, attributes. Without a formal decleration of what 'pubdate' definitively refers to, which is impossible for all contexts, the inclusion will only harbor temporal ambiguity and dimensionlessness. This would be better described and defined within the microdata specification as this is what it seeks to define.
(In reply to comment #3) > Something like this?: > > <article itemscope itemtype="http://n.whatwg.org/article"> > <h1>Example</h1> > <p><data value="2011-01-01">January 1 2011</data> (updated <data > value="2011-01-02">January 2nd</data>)</p> > <p>Hello.</p> > </article> > > Or maybe we could just use the http://schema.org/Blog type (and other types in > that schema.org bucket). > > Any objections to such an approach? None whatsoever, the approach is sound.
(In reply to comment #3) > <article itemscope itemtype="http://n.whatwg.org/article"> > <h1>Example</h1> > <p><data value="2011-01-01">January 1 2011</data> (updated <data > value="2011-01-02">January 2nd</data>)</p> > <p>Hello.</p> > </article> I presume you forgot itemprop, as this empty item is not very useful. Anyway, unless the text of the article can be marked up and its formatting retained, this can't be used for syndication. Microdata (currently) has no relationship to the elements it happens to be scraped from, so I don't quite understand what the above would enable.
Ian, I think microdata has nothing to do with HTML5 spec, and such drastic change in bug's summary is harmful and confusing. Just in case, original summary was following: "Add 'update' boolean attribute to TIME element". This bug in its current form should not be resolved until having clear resolution for bug 13240 (related to odd probable dropping TIME element).
foolip: yeah, good point. It would allow the post information to be extracted for snippets in a search engine, but not much else. I guess the question here is what exactly is the use case? What will these dates be used for, on the consumer side? marat: Microdata is just a minor part of HTML, it has nothing to do with anything _but_ HTML. Saying it has nothing to do with HTML is like saying forms or canvas have nothing to do with HTML.
If the use case here is just a replacement for Atom/RSS, i.e. inline syndication annotations for aggregators, then we can still use the schema.org vocabulary, we just need to also tell people to specify a "url" and make sure that the permalink is what is used. e.g. <article itemscope itemtype="http://schema.org/Blog" id="post24"> <h1>Example</h1> <p><data itemprop="datePublished" value="2011-01-01">January 1 2011</data> (updated <data itemprop="dateModified" value="2011-01-02">January 2nd</data>)</p> <p>Hello.</p> <footer> <p><a itemprop="url" href="#post24">Permalink</a></p> </footer> </article> Then we would say that an aggregator would have to look up the <article> given by the "url" property of the Blog items and syndicate that. Or something.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: see diff in bug 13240 Rationale: I've dropped <time> and changed the examples showing article publication and modification dates to use the schema.org microdata vocabulary.
Summary is restored to original state to make the proposal again applicable to <time> element that the bug was originally intended for.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: There's already ways to do this using existing microdata and microformats vocabularies, so we don't have to add a dedicated element. The primary consumers of this kind of information have already indicated that they would rather use the aforementioned solutions.