Category: standards

Henri Sivonen has written a fantastically well-considered post called Vendor Prefixes Are Hurting The Web which I urge you to read in full, as I’m about to discuss it. I think some of his points are absolutely right, but I disagree on the final conclusion. The points that I think he nails are:

• Demos that work in one browser/engine only and aren’t updated even when other browsers implement the new features, are harmful.
• Using prefixed features as a way of actively excluding other browsers is lazy and anti-competitive.
• Including an unprefixed property in anticipation of eventual standardisation works against the principle of using prefixes
• When browsers have working, largely compatible, implementations of properties (like transform) they should remove the prefix even if the spec hasn’t reached the stage required by the W3C.

However, I still think using prefixed properties is the right approach. If we do as Henri suggests and leave experimental features in experimental builds (an eminently sensible suggestion, I might add), the pace of progress will be much slower. I believe that having these features out there and getting people using them encourages competition (and collaboration) between browser makers, and the benefits of that competition are given to us, the developers, and passed on to the audiences of the sites we build.

That doesn’t mean that the current situation is ideal; far from it. But improving things will involve more effort from us, the developers and writers, the community in general. Chief responsibilities will be:

• Commit to supporting old demos that we have made.
• Always make sure we plan our designs and builds in a way that they are not reliant on prefixed features, but degrade gracefully.
• Don’t use an unprefixed property before standardisation has happened unless we can have reasonable confidence that it is safe.
• Make sure we stress that the things we use and teach are experimental and subject to change.

As an author and writer I’m guilty of some of the faults that are pointed out in his article, and I promise to do better in the future.

In closing, I want to congratulate Henri on writing this thought-provoking post. I was ready to dismiss it as one of the lazy articles criticising prefixes that occur regularly, but the argument was very well thought and well made, and made me change my mind a few times while I was writing this post.

I recently wrote a feature for .net Magazine, The Future of CSS Layouts, which took a look at several proposed CSS modules intended to provide more flexibility for laying out websites. One of those modules, Grid Layout, has been experimentally implemented in IE10 Platform Preview, and it prompted Mark Boulton to propose an alternative approach in his article Rethinking CSS Grids.

While I think the alternative syntax is pretty robust, I did detect a couple of flaws in it which I promised Mark I would write about, and that’s what I’ll do in this article. Before I get to that, I just want to quickly address one of the key points from his proposal.

Read the full article

A lot of the attention paid to HTML5 Forms has been centred around the new input types. email, url, date, and the rest are all very convenient, but for me the really useful feature is the built-in validation. In case you’re not aware of it, the browser will now handle all of the validation that we used to use JavaScript for.

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.

Read the full article

This weekend I attended the London Web Standards group’s State of the Browser, a one-day event with representatives of many of the major browser makers giving us status reports on their products. Chrome, Firefox, Opera and Blackberry were all there; a member of the IE team was due to show but had to pull out for personal reasons (he viewed the live stream and answered some questions from home). The notable absence was Safari, whose community engagement is really not good enough.

There were long talks and shorter breakout sessions, as well as plenty of time to socialise; the LWS must really be congratulated on organising such a good event. There was plenty of news and talking points throughout the day — far too much, really, for me to write here, so I’ll just write up notes of what I found most interesting to me.

Read the full article

I’m not a blind Microsoft-basher, neither am I an MS fanboy (in fact, I think the whole idea of aligning yourself with any single technology or brand is pretty narrow-minded). I think MS do some things well, and some things poorly. I am going to have a bit of a pop at them at the end of this article, but I’m going to start by defending them.

Read the full article

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