All posts tagged ‘HTML5’

Mozilla Builds Video Chat App Using Nothing but Web Standards

Mozilla recently showed off a demo of a video chat app built entirely from web standards. Most of the demo runs on top of the proposed Web Real Time Communication (WebRTC) standard, the W3C’s answer to the audio and video streaming capabilities once found only in proprietary plugins like Flash.

Mozilla’s demo movie shows two users signed in with BrowserID (recently renamed Persona) start a video chat right in the browser. The Persona features, combined with the SocialAPI add-on for Firefox, make the demo browser look a bit like Facebook or other social sites with a “buddy list” of currently signed in users available in the sidebar. Select a user from that list and just click the video chat link to start a call.

Currently Mozilla’s video chat demo requires an experimental build of Firefox and actually uses “a custom API intended to simulate the getUserMedia and PeerConnection APIs currently being standardized.” In other words, video chat in Firefox is still a long way from replacing Skype, but Mozilla does plan to bring at least preliminary support to Firefox later this year.

The short-term goal, according to Mozilla hacker Anant Narayanan, who narrates the video above, is to add WebRTC support to Firefox’s Nightly channel “by the end of this quarter.” Narayanan cautions that in the beginning support may be “limited to just getUserMedia and not the full PeerConnection.”

While the demo video focuses on making video calls work in the desktop browser, with help from some other elements in Mozilla’s larger WebAPI project — which is developing a set of APIs that will allow web apps to better compete with platform-native applications — web-based video chat could work on any device. We recently looked at Mozilla’s Camera API, which gives developers access to your device’s camera, and, in conjunction with these video chat tools, could theoretically bring video chat to mobile browsers as well.

For more info on the video chat experiment, including the source code for the demo, head over to the Mozilla Hacks blog.

BrowserQuest Is Pure HTML5 Gaming Goodness

NyanCat is one of several Easter eggs in BrowserQuest

Mozilla has partnered with developers at Little Workshop to launch BrowserQuest, a Zelda-inspired multiplayer roleplaying game built entirely on the open web stack — HTML5, JavaScript and CSS.

While BrowserQuest is a fun game to play, it was written as much to prove a point as to be a game — namely, that web developers no longer need to rely on Flash to create sophisticated online games. Using today’s web standards, game developers can build impressively complex games that work across devices.

To give BrowserQuest a try, just head on over to the site and pick a username. BrowserQuest will work in most modern web browsers including Firefox, Chrome, Safari, Opera (provided you enable WebSockets), Mobile Safari and Firefox for Android.

In an effort to help game developers looking to build more serious HTML5-based games, the code behind BrowserQuest has been released on GitHub.

BrowserQuest’s backend, which handles the real-time multiplayer aspect of the game, is written in JavaScript and runs on Node.js. As you would expect BrowserQuest uses the HTML5 Canvas element to actually render its 16-bit-style world and hooks into the HTML5 audio APIs for sound effects.

BrowserQuest is responsive as well, using @media queries to adapt to the size of your screen.

WebSockets — which are back, after being rewritten to fix some early flaws — handle the chat feature, which allows players to communicate within BrowserQuest. The final element in BrowserQuest’s HTML5 puzzle is localStorage, which saves your progress as you move through the game.

Although designed as much to showcase the power of WebSockets as to be an actual videogame, BrowserQuest is addictive and can easily suck you into its world for an entire morning if you’re not careful. (Not that we’d know.) There are also quite a few Easter eggs hidden away in its depths.

For more info on BrowserQuest either dive into the game, dig through the code or watch the screencast from developer Guillaume Lecollinet:

File Under: HTML5

The HTML5 Time Element Is Back and Better Than Ever

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.

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.

File Under: CSS, HTML, HTML5

‘HTML5 Please’ Helps You Decide Which Parts of HTML5 and CSS 3 to Use

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.

File Under: HTML5, Web Standards

HTML5 Drops the Time Element [Updated]

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

See Also: