I’ll discuss quickly the result of that submission, but first I should mention that I’ve since found out that the Google Chrome developers have already implemented their own syntax, and it’s not too far removed from what I proposed. Before I get to that, however, allow me to gripe.

What the feedback on my proposal would be, I have no idea — and may never know. As I mentioned, I submitted it via the www-style list, but my emails were never published. I was told that as a new user my mail would be held for approval, but that was six weeks ago. I emailed the list administrator and tried to submit it again, but never got a reply.

I have to say that, as a developer trying to get involved in the standards process — which is what the W3C claim they want — this was not a good experience for me. I had a serious proposal which I wanted to open up for discussion, but was completely unable to do so and met with a wall of silence. I’m not against there being a moderation and approval process, but only if there’s an eventual result and some kind of communication throughout.

OK, with the moan out of the way, I’ll talk about the Chrome validation error styling syntax. The error message, known as the ‘bubble’, is made of four div elements which are accessible via four pseudo-classes, each of which applies to a different div in the bubble:

::-webkit-validation-bubble {}
::-webkit-validation-bubble-arrow-clipper {}
::-webkit-validation-bubble-arrow {}
::-webkit-validation-bubble-message {}

The parent element is ::-webkit-validation-bubble, which sets the size and position of the bubble, and has two child elements. The first child is ::-webkit-validation-bubble-arrow-clipper, which has its own child, ::-webkit-validation-bubble-arrow; these two set the styles of the tail of the bubble. The body of the bubble is the second child, ::-webkit-validation-bubble-message, which contains the text node with the error itself.

I’ve made a quick example which you can see in action on the HTML5 Forms demo — you’ll need to use Chrome to see it, and you can view the source to see the styles I’ve used. Below is an image comparison of the default message (top) and my styled version. Note: I took a little criticism for calling the default styles ‘ugly’ in my original post, and I don’t want to claim that mine is any better, because it’s really not; it’s just different, to act as an example.

You can read a little more about this syntax on the WebKit wiki, and also see the default styles the error message uses. I’ve no idea if Firefox or Opera implement their error messages in the same way so don’t know if this is likely to become standard, or will always remain a WebKit-only syntax. I have to say it’s not really an elegant solution, but it works.

This is great for the future, but although you can start using these functions now (in many browsers), they aren’t without their drawbacks — well, one big drawback really. I’m going to explain briefly the problem, and then propose a solution.

How Form Validation Works

The simplest form of validation is to say that a field is required, which is done by adding the required attribute (it’s boolean, so needs no explicit value):

<input type="text" required>

This will check to see if a value is supplied, and returns an error if it isn’t. You can add parameters to validation by using the pattern attribute with a JavaScript regex value; for example, to only accept a numeric value you would use the following:

<input type="text" pattern="[-0-9]+" required>

Some field types have pattern validation baked in; email and url will only accept correctly formatted email addresses and URLs, respectively, while number and range can have maximum and minimum numeric values applied. There’s also a maxlength attribute to restrict the number of characters, which can also cause a validation error.

The Problem With Error Messages

Probably the biggest drawback of the validation process is that the error messages are, for the most part — and there’s no polite way to put this — ugly. Take a look at this image showing the validation error message in (from the top) Chrome, Opera, and Firefox:

I think the Opera message is the better of the three, but I think it’s fair to say that the designers weren’t having their best days when they made these. (I’m using Ubuntu here, but they really aren’t any better in any other OS.) The problem I have with these is that I’d like to use them, but I don’t think any designer I work with would find these acceptable and I’d no doubt end up using a JS implementation just to get some form of consistency.

Using JS is a short term solution, and there’s a good Validation API to aid in using it (which I aim to write about soon). But longer term we will need better-designed messages, or a way to style them ourselves, or both. I don’t think that the error messages need to look identical in every browser on every OS, but I do think they should be more closely aligned with the browser chrome and sympathetic to the OS; they should feel like a natural part of the platform, rather than an add-on.

A Proposal For Styling Error Messages

There’s no formalised suggestion for CSS styling of error messages, but I think it’s probably inevitable that there will be. This could take the form of a pseudo-element, perhaps something like:

input::error {}

This would allow us to set background, colour and font options. It may be necessary to also have a property to set where the validation error message appears in relation to the input it’s attached to; perhaps modifying position with values of above, below, before, or after:

input::error { position: below; }

And, perhaps, another property to set the appearance of the box which contains the message; perhaps the appearance property with values of box for a rectangle, or balloon for the current speech balloon style:

input::error { appearance: balloon; }

There’s also the text inside the validation error; the main message, and an optional extra which can be set with the title attribute (or JavaScript). These could have further pseudo-elements for finer control over the text formatting:

input::error-message { }
input::error-text { }

This is all straight off the top of my head, of course, and no doubt needs plenty of development; but as there’s no formal proposal at the moment, it’s a good time to be thinking about these things.

The syntax is a key:value pair, with the key being a keyword prefixed with data–, like so:

<div data-foo="bar"></div>

Note that this is not intended to compete with or replace Microformats or RDFa; data attributes were developed only to store custom data [about an element] when there is no more appropriate attribute or element available.

jQuery introduced support for data attributes in version 1.4.3, which was released in October 2010. You use the existing data() method to get and set values. Getting a value involves just using the keyword, as in this example which operates on the markup above:

var baz = $('div').data('foo');

This would set the value of ‘bar’ to the baz variable. jQuery’s implemenation is so clever that the variable will take on the correct value type — string, number, boolean — automatically. In the example above it would be a string, but given markup like this:

<div data-retail="3.99"></div>

The value of the variable would be provided as a number type. You can also use JSON syntax in data attributes, like so:

<div data-foobar='{"foo":"bar"}'></div>

Note that the attribute uses single quotes while the key:value pair inside are in double quotes; this is required to be valid JSON syntax. To access this with jQuery, just add the key name as an object at the end of the string:

var baz = $('div').data('foobar').foo;

This will once again instruct the variable baz to have the value ‘bar’.

<a href="http://example.com">
  <div>
    <h3>I'm an example</h3>
  </div>
</a>

You can begin to use this straight away, as every browser supports it — although you must be wary of one rather glaring bug in Internet Explorer.

The bug occurs if you try to nest other a elements inside the block-level one, as shown in this example markup:

<a href="http://example.com">
  <div>
    <h3><a href="http://example.com">I'm an example</a></h3>
  </div>
</a>

With this markup IE7 fails to render some elements, and IE8 and IE9 create an empty, ‘phantom’ element. I’ll show you what I mean, starting with the way this markup should render; on the left is the HTML markup as it displays in your browser, and on the right I’ve placed a screenshot from Firefox to act as a comparison.

And now see how they appear in IE7 (left) and IE8 & IE9 (right):

As you can see, in IE7 the h3 element loses its background color and margin, and in IE8 & IE9 there’s an empty box above my markup; this is the ‘phantom’ element, which is inheriting the border from the div element, and the margin-bottom from the h3. Were I to add margin-top (or further properties that affect the box model) to my markup, they would also show up here.

Strangely, this bug doesn’t seem to occur in IE6.

The fix is quite simple: don’t nest a elements. I only did it as I needed an element to create a particular style effect, but it can be done just as easily with a span. I tried a number of other approaches but this seemed to be the only one that worked.

Update: As has been pointed out in the comments, nesting a elements is in fact prohibited by the HTML5 specification. I’ll leave this post here for the other people like me who weren’t aware of that.

I’ve no idea how the web video format war will end. My preference is that a free, non-patent encumbered, high-quality video codec will become the standard, and WebM is the best fit for that description. Despite the recent announcement by the MPEG LA, the patent pool which controls licensing of H.264, that it will always be free for ‘video delivered to the internet without charge’, that still doesn’t make it free-as-in-speech, and still not free-as-in-beer for anyone wanting to build a business around video encoding/decoding (which includes, if I’m not mistaken, bundling it with a browser). All that said, my preference is meaningless in the face of so many vested business interests.

But this post isn’t really about that; it’s about clearing up a misconception. One common statement I keep seeing repeated (WebMonkey said this in May, but I’ve seen it even more recently) is that Safari will be the only browser to not support WebM, when even the Internet Explorer team have promised to. That’s not the case. What the IE team said was that they will support WebM (or rather, the VP8 codec) as long as the user has installed the codec on Windows. Safari’s position is identical, they just haven’t publicly stated so.

The current free alternative to H.264, OGG video, is also not supported in Safari — but you can play OGG videos in Safari by downloading and installing the Xiph Quicktime Components. Likewise, Windows Media files are supported through Flip4Mac. WebM can be supported in Safari in the same way, as soon as someone creates a QuickTime plugin (I believe experimental support is in Perian already). This is exactly the same situation as with IE.

Where this doesn’t apply is on mobile devices; many — principal amongst them, the iOS range — don’t allow extra codecs to be installed. However, this is slightly supplemental to my point, which is that both IE and Safari — on desktop — are capable of playing WebM via a plugin. I believe that if people will install the Flash plugin, they will install the WebM plugin — and when we have choice and competition, a true standard can be reached by consensus, rather than financial clout.

Now, there are loads of blog and forum posts which give differing advice on presets and parameters, and I’m no expert — so what I’ll do is just show you two quick ways that worked for me (I have a Samsung Galaxy S).

A couple of things to note: this post refers specifically to video embedded in web pages with the video element, so the other two requirements from my previous blog post still stand; also, the methods shown below should mean your videos play on iOS too, so you don’t have to encode for different platforms.

The first is cross-platform, using Handbrake. What I did with this was to use the iPhone & iPod Touch preset, check the Web Optimized option, and change the Average bitrate option (in the Quality section) to ~1000kbps (you should then save this as a new preset called Android).

You’ll also need to change the size of the output video in the Picture Settings options — I changed mine to 480 wide (keeping the aspect ratio) and they came out really crisp and sharp. You can see the result of that below (if your browser supports it).

The second method is also cross-platform, and uses VLC (I’m using version 1.1.1, not sure if older versions work the same). It involves more set-up the first time around, but will be easier with each subsequent conversion. Update: I was using VLC for Linux, but the OSX version seems to be quite different.

Go to Media > Convert/Save, add the file to be converted, and choose Convert from the selection at the bottom. Name your Destination File [filename].mp4, and from the Profile list choose Video — H.264 + AAC (TS).

Hit the Edit icon next to the list, and go through each tab in turn; in Encapsulation choose MP4/MOV; in Video Codec un-check the Keep original video track box, choose H-264 from the Codec list, empty the Scale field and enter a value in Width (I used 480); in Audio un-check the Keep original audio track box and select MPEG4 Audio (AAC) from the Codec list. Now click Save, and all of these settings will be remembered so you don’t have to enter them again.

With all that done, hit Start to encode your video. You can see the result of the VLC encoding below. Update: This video doesn’t seem to play on iOS.

The third method is the simplest, but works on Mac OSX 10.6 only. Open up your source video in Quicktime, then go to File > Save As. Choose iPhone from the Format selector. You get less control over your output with this — the width is always 480 and the bitrate is calculated automatically — but it works without fuss. The output of this method is shown below.

A slightly more convoluted method is to use DoubleTwist, which performs on-the-fly conversion. Connect your Android device, then transfer your video to it — the optimum parameters will be automatically selected. When complete, copy the file back from the device to your computer. (I haven’t actually tried this myself).

I’ve read that you can use WinFF, although I haven’t been able to make this work so far.

I’ll keep this post updated as I discover different methods, and do feel free to let me know in the comments what works for you.

From what I can tell, there are three requirements for video to work in Android browsers:

1. You must not use the type attribute when calling the video
2. You must manually call the play() method using JavaScript
3. The video must be encoded as .m4v, not .mp4 Update: This is not correct (see below)

Update: This may be a specific encoding issue rather than all .mp4s; some .mp4 videos seem to play with no problems, others do not. Further update: The video type was a red herring; see my follow-up post, Encoding Video for Android, for more about this.

You can see this working in the demo attached to an older post of mine: Demo: HTML5 Video Controls With JavaScript. This works, AFAIK, in Android, iPhone and all video-enabled desktop browsers. The markup I’ve used is:

<video id="video" autobuffer height="240" width="360">
<source src="BigBuck.m4v">
<source src="BigBuck.webm" type="video/webm">
<source src="BigBuck.theora.ogv" type="video/ogg">
</video>

The first source element calls the video in .m4v format, without specifying the MIME type in the type attribute; I’ve tried both video/mp4 and video/x-m4v, and neither works. Omitting the type attribute altogether lets the video play, and seems to have no ill-effect on other browsers which play the .m4v file.

In order to play the video in Android, I also have an event listener in the JavaScript which plays the video when the element is clicked on, somewhat like this:

var video = document.getElementById('video');
video.addEventListener('click',function(){
  video.play();
},false);

I tested this on my own phone and an HTC Desire, and it works just fine on both. Hope this is of help to someone.

* It’s a Samsung Galaxy S, and I’m delighted by it.

In the article I explain how to build a dynamic Contact area, as we did on our recent redesign of Preloaded.com, using the Web Storage API and the BBC’s Glow Javascript library.

I’m not sure what the rights situation is with this article, but I hope that at some point in the future I’ll be able to post it here on my blog. But in the meantime, you can buy a copy of Net magazine in the UK at all good newsagents, as the saying goes (I don’t know if it will be in overseas editions also).

On the subject of print, I’m also currently writing a book about CSS3 which should be published later this year. I’ll have more information on that nearer the time.

In this (somewhat belated) follow-up I’m going to explore building a more interactive set of controls using a JavaScript UI library; I’m going to use Glow, but it could easily be adapted to jQuery UI or similar.

You can see the player I’ll be using as an example here — although it must be stressed that it’s not a final version, for reasons I’ll cover at the end:

HTML5 & Glow Video Player

The markup

The video player itself is pretty straightforward:

<video autobuffer controls height="180" poster="BBB_poster.jpg" width="320">
  <source src="bbb.mp4" type="video/mp4">
  <source src="bbb.webm" type="video/ogg">
  <source src="bbb.theora.ogg" type="video/ogg">
  <img alt="Film Poster" height="180" src="BBB_poster.jpg" width="320">
</video>

The video element has the controls attribute set, which we’ll remove with JavaScript later. Note also the poster attribute, which displays a still image until the video is ready to be played, at which point it displays the first frame instead.

Next there are two source elements, which serve the video to Firefox, Opera and Chrome (ogg) and Safari (mp4). Finally there’s an img element, which displays if the browser doesn’t have video support. Update: Added WebM support.

As for the controls, rather than list them here I’ll ask you to view the source to see what I’ve done. Basically I’ve added a bunch of form elements; two input image types for the play and volume icons, and two input text types for the duration and volume sliders. The latter two aren’t necessary, but I wanted them there for accessibility reasons.

The style

How I’ve styled the player doesn’t matter too much; I’ve been influenced by the Quicktime player for the layout of the controls, but really the CSS isn’t too important here. The only thing to note is that I’ve added some rules here for screen overlays, which I’ll explain in due course:

.overlay { background-repeat: no-repeat; height: 180px; position: absolute; width: 320px; }
.paused { background-color: rgba(0,0,0,0.2); background-image: url('pause.png'); background-position: left bottom; }
.play { background-image: url('play.png'); background-position: center center; }

The JavaScript

You can see all the script I’ve used in the file video.js. I’ll go through some of the more important functions in turn.

Setting up

The first thing I’ve done is removed the native controls from the player for people who have JS enabled, so as not to provide two conflicting sets of controls:

video[0].controls = false;

Next I’ve defined some of the key variables which I’ll be using throughout the script. One of those variables, volumeSlide, is assigned to one of Glow’s native widgets, a Slider; this will be used to control the volume:

volumeSlide = new glow.widgets.Slider('#volume',{bindTo:'#vol_count', buttons:false, step:0.1, min:0, max:1, size:70, val:1});

You can see what all the options do in the Glow documentation, but the key ones I’ve set are for it to appear in <div id=“volume”>, to have a minimum value of 0 and a max of 1, and to increment in steps of 0.1. This matches the volume setting for the video element.

Waiting for the metadata

For the next step I’m going to create another slider, but this time for the duration/seek bar. In order to do this, however, I need to query the video’s metadata to know what the duration of the video is, and in Safari (which uses mp4 video) that doesn’t load before the rest of my JS has run.

To get around this I’ll poll the readyState attribute every half a second — with the setInterval function — until it’s value is at least 1, which means the metadata has loaded; once that’s done, I’ll load the slider:

t = window.setInterval(function() {
  if (video[0].readyState >= 1) {
    window.clearInterval(t);
    durationSlide = new glow.widgets.Slider('#vid_duration',{bindTo:'#duration_count', buttons:false, step:1, min:1, max:Math.round(video[0].duration-1), size:260, val:0});
    playVid();
  }
},500);

So you can see there that I’ve created the slider with a minimum value of 1 and a maximum of the duration of the video (in seconds), to increment in steps of 1. After that the setup is complete so I can begin the actual playback functions.

Playback controls

There are too many functions to go into in detail, so I’ll quickly go through what happens. First an overlay is placed over the top of the video, which begins playback when clicked. Next, event listeners are added to the play button, the volume icon, and the volume and duration sliders.

The listener on the play button runs the function playControl, which determines the state of playback (ended, paused or playing) and either plays or pauses the video accordingly. It also updates the icon to reflect its action (if it is paused, the icon changes to a play icon, and vice versa), and adds the pause overlay onto the video screen when relevant:

function playControl() {
  if (video[0].paused === true) {
    video[0].play();
    /* Further functions here */
  };
} else if (video[0].ended === true) {
    video[0].play();
     /* Further functions here */
} else {
    video[0].pause();
     /* Further functions here */
}

There’s a function called startCount which uses setInterval to move the duration slider along by one second while the video is playing, and a function called pauseCount which uses clearInterval to pause.

The muteToggle function does what you expect, and mutes the video; it also changes the volume icon to show that state, and disables the volume slider while it is active.

A further function, volumeIcons, sets the state of the volume icon; there are four possible icon states, which are used depending on the value of the volume.

And the last function, secondsToTime, converts second values into hour/minute/second values, allowing for the timer to be updated. This is done every second by the startCount function, and also used for the function which is called from the event listener on the duration slider.

That event is probably worth looking at in detail:

glow.events.addListener(durationSlide,'slideStop',function(event){
  video[0].currentTime = event.currentVal;
  var currentSecs = secondsToTime(event.currentVal);
  vidTimer.text(currentSecs.h + ':' + currentSecs.m + ':' + currentSecs.s);
});

Using the slideStop event I can check when the slider has been moved, and first set the video to begin playback from that point, then update the timer with the same values. The volume slider has a similar event set on it.

Next steps

So as a reminder, here’s what I have so far:

HTML5 & Glow Video Player

Please bear in mind that this is very much a work in progress; I started writing the controls without Glow and introduced it at a later stage, so some of the JavaScript could do with being optimised.

The markup for the controls could also do with some extra work to make them fully accessible, which they probably aren’t right now. Also, all of the dimensions are built around this video size, and won’t scale if different sized videos are used.

I hope to return to this topic when I have more time, and create a robust set of video player controls which can be used in any site without extra work.

Please feel free to let me know if you encounter any bugs or oddities as you use this; it will help with the next stage of development.