Category: standards

As you’re no doubt aware, HTML5 video is this year’s big thing — but there’s a dispute going on about which should become the default standard video codec. The current nascent de facto standard is H.264, but recently the new WebM format is gaining traction.

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.

Read the full article

While having a look through the list of features for developers planned for Firefox 4 earlier today, I noticed this:

You can now use SVG with the img element, as well as the background image in CSS.

I know you can already use SVG in background-image with Safari, Chrome and Opera, and this, coupled with Internet Explorer’s push towards SVG and the strong chance this will be available in IE9, made me decide to take a closer look.

Read the full article

We, as website makers, quite often advise our clients to avoid generic link text (read more,click here, etc.), and explain that more verbose descriptions help give context to users with screen readers. But using semantic link descriptions actually helps everyone.

I recently read Peter Morville’s fantastic book, Ambient Findability, which defined really well the motivation to use semantic descriptions for links: they give the target page aboutness.

Read the full article

Last month the W3C released a working draft of the File API, which defines the basic representations for files, lists of files, errors raised by access to files, and programmatic ways to read files. The Firefox team have already implemented much of it, and have released a series of impressive demos on hacks.mozilla.org, which you can see if you have a recent beta of Firefox 3.6 (or a nightly trunk build).

The four demos shown to date display different (although related) aspects of the API, showing first multiple file uploads, then a drag and drop upload interface, next adding progress information (although this doesn’t work for me), then reading EXIF data from a JPEG image. You can imagine how these combined would be used for native drag and drop uploading to Flickr, for example.

The File API plays a big part in integrating the browser more tightly with the OS, particularly when combined with the drag and drop functionality, and I’m sure it’s only a matter of time until the other browsers implement this. Congratulations to the Firefox team for their work on this, and hacks.mozilla.org for some great demos.

In the first part of this post I gave a potted history of the differing syntaxes, and provided an overview of how that affected linear gradients. In this second part I’m going to look at radial gradients.

Here the syntaxes diverge slightly more, with WebKit requiring more values than Mozilla; while that adds some flexibility, it also increases the complexity.

Read the full article

CSS Gradients were originally proposed by the WebKit team in April 2008, modified from the syntax proposed for the Canvas element of HTML5. In August of this year, Mozilla announced that an implementation slightly modified from that of WebKit would be in the next version of Firefox (3.6).

Since then, however, the CSS WG have discussed a different syntax, and a resolution was passed to add this to the Image Values module. Mozilla have decided to implement the new syntax, which is simpler than WebKit’s but less flexible.

In this article, which will be split into at least two parts, I’m going to compare the two syntaxes.

Read the full article