In defence of pubdate
At the end of October, the <time> element was removed from the HTML5 specification. I and others blogged on our dismay at this, but thankfully the decision was reversed and the <time> element was restored to the specification. This is good.
However, the pubdate attribute is also under threat of disappearing, and I even joined the W3C to register my opposition to the removal of the pubdate attribute.
What does the pubdate attribute do?
As it stands at the moment, the pubdate attribute, which is a Boolean attribute, can be added to a <time> element and it allows you to specify that this particular time value is the published date of the article or relevant data. Or as the W3C specification says:
If specified, it indicates that the date and time given by the element is the publication date and time of the nearest ancestor article element, or, if the element has no ancestor article element, of the document as a whole.
Usefulness
This, to me, is quite handy. It allows anything that might be traversing the page to instantly locate and recognise the publication date of articles or data on a page. This can only be a good thing, as it helps to indicate how recent the data on the page actually is. And let’s face it, most articles on the web have a published date, so the data itself is prevalent.
Google themselves have hinted how useful being able to do such a thing might be (although they don’t specifically talk about the <time> element nor the pubdate attribute).
In my defence of the pubdate attribute to the W3C, I gave a simple example of a list of events or concert dates on a page, which could of course be littered with <time> elements, only one of which is the actual published date of the listing. Surely it would be very useful to be able to locate this date quickly, and accurately?
An argument against this suggested that a Microdata vocabulary like vEvent could be used to list the timings, in which case the pubdate attribute wouldn’t be of any use. I must admit, I know nothing of this vocabulary, having never used it. But if I, a fairly seasoned web developer, knows nothing about it, what chance do non-developers have of supplying such useful information? Surely it’s our job to make things easier, and adding a simple attribute to a specific element would be much easier than learning some Microdata vocabulary. In addition, CMS’ like WordPress could automatically enclose the published date in a <time> element containing the pubdate attribute.
Issues
It was mentioned, and I agree, that this does lead to the problem of the pubdate attribute not necessarily reflecting how recent the data on the page might be. Since pubdate indicates when the data was published, it doesn’t reflect any changes that might have taken place since.
Suggestions
This leads me to two suggestions:
- The
pubdateattribute should always indicate the latest modified date of the data in question. This of course then makes the name of the attribute itself potentially misleading - The
pubdateattribute should stay as it is, and another attribute, themoddateattribute should be added which allows the modified date to be specified in an alternative<time>element. If both themoddateandpubdateattributes appear on the same<time>element, thenmoddatetakes precedence
Feedback Required
These are just some thoughts I’m throwing out there and I’d be interested in hearing other people’s feedback and perhaps any “real world” data on how much the pubdate attribute is currently being used.
5 Responses
When I consider this in the context of a blog, suggestion #1 does not fit. I regularly go back and update an entry with some new information and I always note it in a heading. I still want the blog post as a whole to reflect the date on which it was published, but I want it to also reflect that it has changed since then. Then it’s up to a sorting/filtering process to determine whether I as a user can see only my recent posts, or posts that were updated recently.
I know I am over-simplifying, but at least I have an example on which to draw.
Pingback: 復活した time 要素
Unlike vEvent, both moddate and pubdate have semantic meaning. They indicate a specific date on which something occurred. Both pieces of information are important to anyone or any bibliographic search process.
Use of both would obviate what I expect is a great deal of fiddling research that occurs when a user has to pin down one or the other of these facts.
As a graphic designer and teacher of bibliography, I learned long ago that if you print a poster (or anything for that matter) with say, just the month and day, that piece will immediately be classified as ephemera rather than a document. Without the full date, the work floats in time and is not a legal record, rather just an indication that this “thing” happened at some time in the past but you can never place it on a timeline with any accuracy.
Excellent point on
<time>being used for bibliography dates. Thepubdateattribute could be confusing for these though. This could lead to a long list of items each containing a<time>element with, quite legitimately, apubdateattribute, which would confuse matters. This requires further thinking.Pingback: Keep pubdate and add moddate | iandevlin.com - blog