The W3C didn’t just add time back though; they’ve improved it considerably. While nothing has changed with the human-readable part — that is, anything between <time> and </time> — the datetime attribute has been imbued with new superpowers.
The original version of the time element was rather strict; under the original spec datetime data needed to refer to a specific date. For example, to mark up today’s date you might do something like this:
That’s all good and well for days, but what if you just wanted to specify a month? Or a year? What do you do when trying to mark up date-based blog archives, or something in history where the precise date is unknown? The new date spec allows for just that.
To specify a date no more precise than a month you’d do something like this: <time datetime="2012-02">. Take away the month and it would refer to just the year. Other options include the week of the year and a date without a year (for referring to reoccurring events, e.g. holidays).
To see some more examples of the datetime attribute and what you can do with it, head over to Bruce Lawson’s blog. Lawson, who is part of Opera’s developer relations team, recently looked at just about everything you can do with datetime, including specify durations (which uses a somewhat confusing set of abbreviations).
There are two things to keep in mind when using the time element. First, you still can’t represent dates before the Christian era, and second, the pubdate attribute may be cut from the HTML5 spec. Pubdate, which is a boolean attribute for indicating publication dates, is still present in the WHATWG version of HTML5, but there’s a proposal to drop it.
Keeping track of the ever-evolving HTML5 and CSS 3 support in today’s web browsers can be an overwhelming task. Sure you can use CSS animations to create some whiz-bang effects, but should you? Which browsers support it? What should you do about older browsers?
The first question can be answered by When Can I Use, which tracks browser support for HTML5 and CSS 3. You can then add tools like Modernizer to detect whether or not a feature is supported, so that you can gracefully degrade or provide an alternate solution for browsers that don’t support the features you’re using. But just what are those alternate solutions and polyfills? That’s what the new (somewhat poorly named) HTML5 Please site is designed to help with.
HTML5 Please offers a list of HTML5 elements and CSS 3 rules with an overview of browser support and any polyfills for each element listed (CSS 3 is the much more heavily documented of the two, which is why the HTML5 emphasis in the name is perhaps not the best choice). The creators of the site then go a step further and offer recommendations, “so you can decide if and how to put each of these features to use.”
The goal is to help you “use the new and shiny responsibly.”
HTML5 Please was created by Paul Irish, head of Google Chrome developer relations, Divya Manian, Web Opener for Opera Software, (along with many others) who point out that the recommendations offered on the site “represent the collective knowledge of developers who have been deep in the HTML5 trenches.”
The recommendations for HTML5 and CSS 3 features are divided into three groups — “use”, “use with caution” and “avoid”. The result is a site that makes it easy to figure out which new elements are safe to use (with polyfills) and which are still probably too new for mainstream work. If the misleading name bothers you, there’s also Browser Support, which offers similar data.
If you’d like to contribute to the project, head over to the GitHub repo.
[Update: The W3C has added <time> back to the HTML5 specification. See our follow up post for more details]
Ian Hickson, editor of the HTML5 specification, has decided to drop the proposed <time> element from HTML5. The loss of the time element means, among other things, that there will be no semantically meaningful way to specify publication dates in HTML5.
Hickson claims that the <time> element wasn’t being used for two of its primary use cases, namely easier CSS styling and to indicate publication dates for web documents. He goes on to argue that the third main use case for the time element — writing dates in a machine-readable format — is better handled by the more generic <data> element.
However, Hickson’s claim that <time> “does not seem to have much traction” on the web isn’t borne out by the facts.
In fact, support for the time element is already baked into the Opera web browser and it’s being used on popular sites like Reddit, the Boston Globe and in the default WordPress theme, to say nothing of the countless personal sites and blogs already using <time>. That’s more real-world support than many other HTML5 elements can boast (and those elements aren’t being cut from the HTML5 spec).
What makes the “it hasn’t caught on” argument even weaker is that HTML5 is not yet a finished spec, so claiming that no one is using the time element before officially endorsing the time element doesn’t make much sense. It’s a chicken-and-egg problem. For example, some Microformats could have been rewritten to use <time>, but the Microformats developers need the W3C to endorse HTML5 before they can suggest adding HTML5 elements like <time> to Microformats.
Opera’s Bruce Lawson has spoken out against dropping the <time> element, calling it “a bad decision,” and suggesting that the more generic <data> is less useful than <time>. Lawson defends <time>, writing:
(or its precursor, ) has an obvious semantic (easy to learn, easy to read). Because it’s restricted to dates and times, the datetime attribute has a specific syntax that can be checked by a validator. Conversely, it has no such built-in syntax, as it’s for arbitrary lumps of data, so it can’t be machine validated. This will lead to more erroneous dates being published. Therefore, the reliability and thus the utility of the information being communicated in machine-readable format diminishes.
Indeed, Lawson is only one of a handful of prominent web developers questioning Hickson’s decision. Developer Tantek Çelik suggests a compromise, writing that HTML5 should “keep <time>, expand its granularity, drop pubdate, introduce <data> and study how it’s used.”
The question for many developers is, should we continue to use <time>? The answer is that it depends. Hickson does not have a history of bending to popular opinion, but there has been a great deal of outcry surrounding the loss of time. There’s a chance, despite having an official status of “resolved, fixed” on the HTML5 bug tracker, that <time> might be added back into the spec.
Unfortunately that chance seems slim at the moment. Going forward the more conservative plan would be to use a Microformat like hAtom (or some of the similar efforts from schema.org) in conjunction with the HTML5 data element to create markup that’s valid HTML5, but also retains the semantic meaning lost with the removal of the time element.
The new Kindle Format 8 uses HTML5 and CSS for better looking books and graphic novels
Amazon’s new full-color Kindle Fire tablet will arrive next month and with it will come a new e-book format that uses web standards to take advantage of the Fire’s new and improved features.
The new format, Kindle Format 8 (KF8), uses HTML5, CSS 3 formatting rules, embedded custom fonts and SVG graphics to create a richer toolset for book designers. It also means that if you can build a website, you can build a book.
KF8 isn’t the first e-book format to use HTML under the hood. Both EPUB and Mobi — the current Kindle format — are both built on HTML, but KF8 will be the first to embrace nearly all of HTML5 and its associated tools like CSS 3 and SVG.
With KF8 e-book designers can use the same tools web designers have long relied on to handle richer layout options like sidebars, pull quotes, callouts and other common print design elements that don’t translate well to the limited options of current e-book formats. The new tools will be particularly useful for creating better visuals in children’s e-books and graphic novels.
Interestingly, by making it possible to create e-books using the same tools you’d use to create a website, Amazon may be inadvertently making the web the new home of e-books. So far Amazon hasn’t released many specifics surrounding its KF8 format, but if KF8 is essentially a wrapper around HTML5 and CSS 3 then presumably it won’t be too hard to strip away that wrapper. What would be left behind will likely be a “e-book” that’s really just a single page of HTML and CSS — perfect for the web.
When browsers begin to support tools like the proposed Generated Content for Paged Media specification, it will likely be just as easy to markup and release the raw HTML version of an e-book — and let the browser paginate and format it — as it is to put it in Amazon’s storefront where the Kindle can paginate and format it.
Whether or not such an easy dual publishing route is actually possible will be clearer when Amazon releases its updated Kindle Publisher Tools. Amazon hasn’t set a date yet, but you can sign up to be notified when the new tools are available.
Amazon’s Kindle Fire will be the first Kindle to support the new KF8 format, but according to Amazon support for KF8 in the new e-ink Kindles and the various Kindle apps will be added “in coming months.”
Windows 8 will have two versions of Internet Explorer 10: a conventional browser that lives on the legacy desktop, and a new Metro-style, touch-friendly browser that lives in the Metro world. The second of these, the Metro browser, will not support any plugins. Whether Flash, Silverlight, or some custom business app, sites that need plugins will only be accessible in the non-touch, desktop-based browser.
Should one ever come across a page that needs a plugin, the Metro browser has a button to go to that page within the desktop browser. This yanks you out of the Metro experience and places you on the traditional desktop.
The rationale is a familiar one: plugin-based content shortens battery life, and comes with security, reliability, and privacy problems. Sites that currently depend on the capabilities provided by Flash or Silverlight should switch to HTML5.
Microsoft has been vigorously promoting HTML5 for the last year and a half as the best way of providing rich interactivity on the Web. HTML5 potentially has reach far beyond that of Flash, since it can target both conventional browsers and closed ecosystems (such as iOS) alike. However, until now, Microsoft’s messaging has been tempered somewhat: use HTML5 when you can, but if you can’t—if you need support for DRM-protected media streaming, for example—then it’s reasonable to switch to an alternative, plugin-based technology.
With Windows 8, however, those reasonable decisions to use Flash or Silverlight will now be heavily penalized. Technically, there’s nothing wrong with the desktop browser, of course; the rendering engine and performance will be identical between both Metro and desktop. But the experience will be substantially inferior. The desktop browser isn’t designed for touch inputs, meaning that users will either have to switch to a mouse and keyboard, or fumble around with an interface that wasn’t built for fingers. The switch to the desktop browser also appears to discard things like back button history and current page state.
This puts the Metro browser in a peculiar position. Microsoft has positioned tablets as merely a different kind of PC. That, the company argues, affords capabilities and features not possible on iPad-style devices. But PCs have browser plugins—more generally, they have the ability to use the right technology for the job. If Metro doesn’t include that flexibility, that could be seen as diminishing the “PCness” of the platform.
HTML5 still isn’t a total replacement for plugin technologies, either. The gap is certainly narrowing: Web Sockets, Web Workers, built-in support for webcams and microphones, and more, are all coming to HTML5 browsers (or are available already), and these features will obviate the need for plugins for many applications. But certain corners are likely to remain; DRM-protected video, for example, might forever be impossible in HTML5, and while many people find DRM distasteful, many broadcasters feel they have little choice but to use it.
The solution to this conundrum on the iOS platform has been the app: companies like Netflix and the BBC have applications to watch video on these devices. The result is that in the desire to push an open, plugin-free Web, companies are being forced to migrate away from the Web entirely. Silverlight developers, at least, will have an easy migration path available to them: the new Metro development environment, used for producing native Metro applications, borrows heavily from Silverlight, and making the switch from an in-browser plugin-based application to a standalone Metro application should be relatively easier. Flash developers will have to wait to see what tools Adobe delivers.
HTML5 design and developer tools also remain weak, though this situation is improving with the creation of products like Adobe Edge.
With Microsoft’s promotion of HTML5, and the precedent set by iOS, the decision to get rid of plugins in the Metro browser is perhaps unsurprising. But it’s not clear that this will truly help Windows 8; the awkward user experience penalizes users who, for no fault of their own, need to use plugins, and detracts from Windows 8′s PC claims. A switch to a more HTML5-powered Web will happen regardless—does Microsoft really need to force the issue like this?
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.
The HTML5 time element pulled a disappearing act last year. HTML5 editor Ian Hickson deleted it from the specification, but then the W3C, the group that oversees HTML5, stepped in to override Hickson’s decision, adding time back to HTML5. Now you see it, now you don’t, now you do again.
Keeping track of the ever-evolving HTML5 and CSS 3 support in today’s web browsers can be an overwhelming task. Sure you can 
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code