Stack Overflow: HTML5 — Is it possible to add HTML5 validation to Visual Studio?

I'm working on a page using <canvas>, which is a HTML5 tag, in Visual Web Developer Express Edition 2008, and the validator in the HTML editor is telling me it's an invalid tag. That's because it's set to validate against XHTML 1.0 Transitional. I'd prefer for it to not do that and tell me what's valid or invalid based on the HTML5 doctype, but I can't find anywhere in the preferences that suggests this would be possible.

Is there a way to tell Visual Studio to validate against HTML5, or add a new spec reference manually? I'd prefer not to have to go in and add tags manually, which appears to be the only option at the moment.

Stack Overflow: HTML5 — Authoring HTML5 in Emacs?

What's the best solution for authoring HTML5 in Emacs? Is there a mode that will do conformance checking?

Stack Overflow: HTML5 — Facebook Connect and HTML5, xmlns available?

Facebook Connect and their "Social Widgets" documentation mention that you need to add an xmlns attribute to your <html> tag on the page where it will be used.

I understand that xmlns is for XML Name-spacing, and have used such with XHTML before. However, with all the recent talk about HTML4 / HTML5, without having read through the entire spec, is the xmlns attribute compatible with valid HTML5? What about HTML4?

If I've looked over an obvious mention of this in the docs, I'm sorry... point it out?

EDIT: A couple docs references/cites: http://developers.facebook.com/news.php?blog=1&story=198 http://wiki.developers.facebook.com/index.php/Facebook_Connect

Stack Overflow: HTML5 — What is a polyglot document?

In this answer to this question, Lachlan-Hunt writes the following:

With HTML5, you can choose to use HTML-only syntax, meaning that it is only compatible with being served and processed as text/html it is not well-formed XML. Or use XHTML-only syntax, meaning that is is well-formed XML, but uses XML features that are not compatible with HTML. Or, you can write a Polyglot document, which is conforming and compatible with both HTML and XHTML processing (In principle, this is conceptually similar to writing XHTML 1.0 that conforms with Appendix C guidelines).

What is a Polyglot document?

Stack Overflow: HTML5 — HTML5 syntax - HTML vs XHTML

Even with HTML5 being the path forward for HTML we get two options as developers: XHTML syntax and HTML syntax. I've been using XHTML as my main doctype for 5 or so years so I'm very comfortable with it.

But my question is given that non-xml syntax will be allowed, is there any reason to stick with a valid XML syntax? Do you gain anything going with one over another, besides preference (compatibility, etc)? Personally I'll feel a little dirty going back to not closing tags,
is second nature to me now, but would I gain something going back to HTML syntax?

Update: I guess my true question is is there a reason to switch from XHTML to HTML syntax? I've been using XHTML for years and not sure if there is a reason to switch back. Browser compatibility (IE was sometimes finiky with the application/xhtml+xml mime-type), etc?

Ajaxian — It’s Friday. Play some drums…. HTML5 style

Brian Arnold created a fun sample drum machine simulator using HTML5 <audio>.

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. function playBeat() {
  3.         if (isPlaying) {
  4.                 var nextBeat = 60000 / curTempo / 4;
  5.                 // Turn off all lights on the tracker's row
  6.                 $("#tracker li.pip").removeClass("active");
  7.                 // Stop all audio
  8.                 stopAllAudio();
  9.                 // Light up the tracker on the current pip
  10.                 $("#tracker li.pip.col_" + curBeat).addClass("active");
  11.                 // Find each active beat, play it
  12.                 $(".soundrow[id^=control] li.pip.active.col_" + curBeat).each(function(i){
  13.                         document.getElementById($(this).data('sound_id')).play();
  14.                 });
  15.                 // Move the pip forward
  16.                 curBeat = (curBeat + 1) % 16;
  17.                 // Schedule the next one
  18.                 setTimeout(playBeat, nextBeat);
  19.         }
  20. }
  21.  

That's not all Brian is working on:

I'm also working on something like the ToneMatrix or Tenori-on (Flash and actual devices, respectively) in pure HTML/JS. It works too, but the sounds aren't exactly designed to be great together (it's currently working on a C scale) and so if you're careful, you can get some decent sound but otherwise, it'll hurt your ears.

Sam Ruby — XHML 2 Charter Set To Expire

Philippe Le Hegaret and Ian Jacobs: W3C management has decided to allow the Working Group’s charter to expire at the end of 2009 and not to renew it ... we expect the next generation XML serialization of HTML to be defined in the HTML 5 specification.

Planet Mozilla — Faces Of The Web Video Revolution

There's a lot of press these days about the HTML5 <video> tag and the struggle for universal unencumbered video and audio codecs --- much of it associated with the Firefox 3.5 launch. I wonder how many people know that the Firefox video implementation is almost entirely due to just a few people in the Mozilla office in Newmarket --- Chris Double, Matthew Gregan, Chris Pearce, and to a lesser extent, me. (Justin Dolske did the controls UI, but I'm not sure where he lives!) I'm proud that we managed to get considerably more done for the 3.5 release than I expected.

It's a great privilege to have the opportunity to really shake up the world for the better, with a very small team, in a relatively small amount of time, and do it right here in Auckland. I'm very thankful.

Chris Pearce, Chris Double and Matthew Gregan

Google Code Blog — Gmail for Mobile HTML5 Series: Using Timers Effectively

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week, I'll talk about two kinds of timers Javascript provides and how you can put them to good use in your own web applications.

Javascript Timer API

Timers provide a way to schedule a function to run at some later point in time. The two functions used to create timers are:
  • var id = setTimeout(fn, delay) creates a timer which calls the specified function once after the given delay.
  • var id = setInterval(fn, delay) is similar, but the function is called continually until the timer is canceled.
Each type of timer has a corresponding clear method (e.g., clearTimeout(id)) that stops a timer while it is running.

There are many great resources online already that document the nitty-gritty details of this API. That's not our focus here. Instead, I want to talk about specific ways in which you can put these timers to work for you in your web application.

Let's Do the Time Warp Again

It's important to keep in mind that just because you ask for a timer with a certain delay doesn't mean it will fire precisely that many milliseconds later. On current browsers, all Javascript code executes within a single thread. This means all your timers have to contend for execution time not only with each other, but also with all the other Javascript code in your application. If another block of code is in the middle of executing when a timer should fire, the timer will be delayed until that block of code is done. (Help is on the way: HTML5's Web Workers will allow web applications to spawn workers that run scripts in parallel.)

Let's look at a concrete example of what this means in practice. I added a timer to Gmail for mobile that is supposed to fire every 200 ms. Each time it fires, it records the time between consecutive timer ticks. Here are the results after 100 ticks:


The dashed blue line represents the requested timer interval, 200 ms. Notice that the median was almost 50% higher than requested, at 276 ms; the time between ticks varied from 98 ms to almost 4 seconds, with an average delay of 493 ms.

This highlights the fact that the interval at which your timer actually fires may differ greatly from the requested delay. In fact, the time between ticks is typically highly variable. It will fluctuate based on what else is happening in your application and on the device. Don't rely on yours timer being precise!

Buy One Timer, Get One Free?

When I first started working on the new version of Gmail for mobile, the application used only a couple of timers. As we continued adding more and more features, the number of timers grew. We were curious about the performance implications: would 10 concurrent timers make the app feel slow? How about 100? How would the performance of many low-frequency timers compare to a single high-frequency timer?

To answer these questions, we conducted a few experiments. We injected some extra code into a development build of Gmail that created a lot of different timers, each of which just performed some simple calculations. Then we fired up the app on an iPhone 3G and Android G1 (both running the latest version of their respective firmware) and observed the performance. Note that although we could have just created a separate test page for this, we chose to inject the code right into our app so we could see how fast it would be to read and process mail with all those timers running.

Here's what we learned. With low-frequency timers — timers with a delay of one second or more — we could create many timers without significantly degrading performance on either device. Even with 100 timers scheduled, our app was not noticeably less responsive. With high-frequency timers, however, the story was exactly the opposite. A few timers firing every 100-200 ms was sufficient to make our UI feel sluggish.

This led us to take a mixed approach with the timers we use in our application. For timers that have a reasonably long delay, we just freely create new timers wherever they are needed. However, for timers that need to execute many times each second, we consolidate all of the work into a single global high-frequency timer.

One High-Frequency Timer to Rule Them All

A global high-frequency timer strikes a balance between needing several different functions to execute frequently and application performance. The idea is simple: create a single timer in a central class that calls as many functions as required. Ours looks something like this: 


var highFrequencyTimerId_ = window.setInterval(globalTimerCallback, 100);

globalTimerCallback = function() {
  navigationManager.checkHash();
  spinnerManager.spin();
  detectWakeFromSleep_();
};

Why did we choose to hardcode the various function calls in onTick_() rather than implementing a more generic callback registration interface? Keep in mind that this code is going to execute many times every second. Looping over an array of registered callbacks might be slightly "cleaner" code, but it's critical that this function execute as quickly as possible. Hardcoding the function calls also makes it really easy to keep track of all the work that is being done within the timer.

To Die, To Sleep; To Sleep, Perchance to Tick

One neat application of a high-frequency timer is to detect when the device has been woken from sleep. When your application is put to sleep — either because the device is put into sleep mode or because the user has navigated away from the browser to another application — time, as perceived by your app, pauses. No timers fire until the user navigates back to your app and it wakes up. By keeping a close eye on the actual time that elapses between high-frequency timer ticks, you can detect when the app wakes from sleep.

First, create a high-frequency timer, as described above. In your timer, call a function that keeps track of the time between ticks: 


// The time, in ms, that must be "missed" before we
// assume the app was put to sleep.
var THRESHOLD = 10000;

var lastTick_;
detectWakeFromSleep_ = function() {
  var now = new Date().getTime();
  var delta = now - this.lastTick_;
  if (delta > THRESHOLD) {
    // The app probably just woke up after being asleep.
    fetchUpdatedData();
  }
  lastTick_ = now;
};

Now your users will always have the latest data available when they return to your app without having to manually perform a refresh!

I hope this helps you make the most of timers in your web application. Stay tuned for the next post, where we'll discuss some cool tricks to spice up the text areas on your forms.

By Neil Thomas, Software Engineering Intern, Google Mobile

Planet Opera — Slashdot: Browser Vendors Force W3C To Scrap HTML 5 Codecs

Planet Mozilla — (R)evolution Number 5

Cross-posted from hacks.mozilla.org

We’ve just launched Firefox 3.5, and we’re incredibly proud. Naturally, we have engaged in plentiful Mozilla advocacy — this site is, amongst other things, a vehicle for showcasing the latest browser’s new capabilities. We like to think about this release as an upgrade for the whole World Wide Web, because of the new developer-facing features that have just been introduced into the web platform. When talking about some of the next generation standards, the appearance of the number “5″ is almost uncanny — consider HTML5 and ECMAScript 5 (PDF). The recent (and very welcome) hype around HTML5 in the press is what motivates this article. Let’s take a step back, and consider some of Mozilla’s web advocacy in the context of events leading up to the release of Firefox 3.5.

Standardization of many of these features often came after much spirited discussion, and we’re pleased to see the prominent placement of HTML5 as a key strategic initiative by major web development companies. Indeed, exciting new web applications hold a great deal of promise, and really showcase what the future of the web platform holds in store for aspiring developers. Many herald the triumphant arrival of the browser as the computer, an old theme that gets bolstered with the arrival of attractive HTML5 platform features that are implemented across Safari, Chrome, Opera, and of course, Firefox (with IE8 getting an honorable mention for having both some HTML5 features and some ECMAScript, 5th Edition features).

Call it what you will — Web 5.0, Open Web 5th Generation (wince!), or, (R)evolution # 5, the future is now. But lest anyone forget, HTML5 is not a completed standard yet, as the W3C was quick to point out. The editor doesn’t anticipate completion till 2010. The path taken from the start of what is now called HTML5 to the present-day era of (very welcome) hype has been a long one, and Mozilla has been part of the journey from the very beginning.

For one thing, we were there to point out, in no uncertain terms, that the W3C had perhaps lost its way. Exactly 5 summers ago (again, with that magic number!), it became evident that the W3C was no longer able to serve as sole custodian of the standards governing the open web of browser-based applications, so Mozilla, along with Opera, started the WHATWG. Of course, back then, we didn’t call it HTML5, and while Firefox itself made a splash in 2004, the steps taken towards standardization were definitive but tentative. Soon, other browser vendors joined us, and by the time the reconciliation with W3C occurred two years later, the innovations introduced into the web platform via the movement initiated by Mozilla had gained substantial momentum.

The net result is a specification that is not yet complete called “HTML5″ which is implemented piecemeal by most modern browsers. The features we choose to implement as an industry are in response to developers, and our modus operandi is (for the most part) in the open. Mozilla funds the HTML5 Validator, producing the first real HTML5 parser, which now drives W3C’s markup validation for HTML5. That parser has made its way back into Firefox. It’s important to note that capabilities that are of greatest interest (many of which are showcased on this blog) are not only developed within the HTML5 specification, but also as part of the W3C Geolocation WG, the Web Apps WG, and the CSS WG.

The release of Firefox 3.5, along with updates to other modern browsers, seems to declare that HTML5 has arrived. But with the foresight that comes with having been around this for a while, we also know that we have a lot of work ahead of us. For one thing, we’ve got to finish HTML5, or at least publish a subset of it that we all agree is ready for implementation, soon. We’ve also got to ensure that accessibility serves as an important design principle in the emerging web platform, and resolve sticky differences here. Also, an open standard does not an open platform make, as debates about web fonts and audio/video codecs show. We’ve got a lot of work ahead of us, but for now, 5 years after the summer we started the ball rolling, we’re enjoying the hype around (R)evolution Number 5.

Planet Mozilla — Web Video Codecs

Anne van Kesteren: “Opera has announced support for Ogg Theora and Vorbis“

Planet Mozilla — Secrets

That’s right, the WHATWG accepts secret feedback.

But… I thought secrets were bad.

Something must have changed. Secrets seem to be OK now. What am I missing?

Anne van Kesteren — Web Video Codecs

Despite mention of codecs being removed from HTML5 for now, I think there is all the indication that this open video thing might actually work. Where with open video I mean a format that can be implemented without having to pay any royalties. I believe it is very important that standards and formats we actively deploy to the Web are both royalty free and documented in enough detail that independent implementations can be made. In terms of usage it seems pretty clear that Wikipedia will be using Ogg Theora and Vorbis. In a previous post on Web video I mentioned Dailymotion. Since then The Video Bay has been announced. It would be really great if YouTube started delivering Ogg Theora and Vorbis as well, but so far Google has not shared much about this. Firefox 3.5 has been released with — based on limited testing — a great implementation of the video element. Opera has announced support for Ogg Theora and Vorbis for a post Opera 10 release. (I suppose we will make that announcement on a non-mailing list place in due course.) Google Chrome will support Ogg Theora and Vorbis out of the box. (Chris DiBona from Google meanwhile explained why Google thinks that Chrome’s usage of H.264 is done in such a way that downstream usage of FFmpeg is not covered by their patent license while still complying with the LGPL by the way.)

The other good news about Theora is called Thusnelda. The Xiph.Org Foundation is working hard on making a better encoder for Theora video. The nice thing here is that the format itself is stable. So an encoder that makes the video more compressed and of higher quality will run fine in existing decoders (e.g. the one shipping in Firefox 3.5). The quality is getting really close to H.264 and is better than older formats which are also still widely deployed on the Web today.

I think the HTML5 specification should make the requirement for Ogg Theora and Vorbis. Everything we do has the risk of patents after all and Mozilla and Opera not being able to commit to H.264 is a red herring. H.264 is not suitable regardless as it is not a royalty free format. And once Ogg Theora and Vorbis support is in browsers and content is encoded using these formats, hardware support for it will most definitely come.

Ajaxian — Modernizr: HTML5 and CSS3 detection

Modernizr is a new library that detects various HTML5 and CSS3 features and lets you know so you can use them:

Writing conditional CSS with Modernizr

Now, once your page loads, Modernizr will run and go through all of its tests. It will automatically add all the classes to the <body> element of the page, and these classes will be along the lines of body.feature or body.no-feature, with the former indicating that the current browser supports that specific feature and the latter indicating that the browser does not support the feature.

Additionally, it will create a new JavaScript object in the global scope, called Modernizr. This object will contain properties for each of the features that Modernizr detects for, and their value will be set to TRUE or FALSE depending on the browser's support for it.

What you can do from this point on is write pseudo-IF/ELSE statements in your CSS. Let's look at an example from the Modernizr.com site itself:

PLAIN TEXT
CSS:
  1.  
  2. .cssgradients #main {
  3.     background: -webkit-gradient(linear, left 0, right bottom,
  4.         from(rgba(255,255,255, .82)),
  5.         to(rgba(255,255,255, 0))) 0 0 no-repeat;
  6. }
  7.  

In the above example, we're doing an "IF" condition in CSS: IF the browser supports both CSS gradients, THEN apply this background property to the #main element (instead of the original background property).

Writing conditional JavaScript with Modernizr

When leveraging Modernizr in your JavaScript, it's as straight-forward as it can be to do IF-conditions based on what the browser currently supports:

PLAIN TEXT
CSS:
  1.  
  2. if (Modernizr.cssgradients) {
  3.     // perform some actions you only want to
  4.     // execute if the browser supports gradients
  5. }
  6.  

We are seeing a growth in these kinds of tools and shims to get HTML5 features into developers hands. Another great site to help is the new HTML5 Doctor.

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>