When Written: Feb 2013
I wrote in my last article about the joys of adding video to an HTM5 web site and the pain that is it to create several file format versions of each video just to satisfy all of the browsers out there. The news has since broken that Mozilla, the team behind Firefox, is proposing to adopt the H.264 standard of encoding videos for the web rather than supporting Google’s suggested WebM VP8 standard that uses the Ogg Theora codecs. http://appleinsider.com/articles/12/03/14/mozilla_considers_h264_video_support_after_googles_vp8_fails_to_gain_traction.
The reason for this is the lack of adoption by other browsers of this Ogg Theora codec despite the fact that this codec is open source and free to use. On the other hand the H.264 codec is based on a set of techniques which are patented and although they are currently free to use there is a danger that licensing fees may be levied at a future date. Nevertheless, H.264 is preferred by Apple and Microsoft and with Google not continuing with their threat to remove H.264 support (http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html ) from their Chrome browser and with all the Apple mobile devices not supporting the Ogg Theora codec it seems that the battle of video formats for the web may finally be over – or will be once the legacy browsers disappear from use (http://caniuse.com/mpeg4 ). Opera has announced that it will be using the Webkit rendering engine as used in Safari for future versions of the Opera browser and so the support of H.264 on all the devices out there on the web takes a step closer. In the meantime, however, in order to be sure that your users, and in particular the ones on corporate networks who are unable to upgrade or change their browser, you will still have to keep making those four file formats and the messy HTML code to get videos working.
The browser compatibility chart, migraines come free!
Whilst on the subject of WebKit based browsers, there is currently a lot of concern in the industry over the use of WebKit only based extensions to CSS. Vendor specific prefixes are not unique to WebKit, being used in other browsers as well, but the worry is that the increasing dominance of WebKit, helped I’m sure by the fact that it is often used for the preview rendering engine in many web development tools like Dreamweaver, will mean that web sites are being built that will become browser specific. This means that there is a danger that inexperienced developers will assume that if it looks fine in their development tool and their default browser then all is well and this is often far from the case.
The reason for the ability to be able to add vendor specific extensions to CSS was, according to the W3C, to allow browser enhancements to be implemented and used by the web community much sooner than if we had to wait for it to become an adopted HTML standard. I would also guess that it would be a way of seeing what enhancements were genuinely useful and became adopted by the majority of the web rather than wasting time discussing a standard for a feature that would barely be used. The important thing to remember here is that this mechanism for extending CSS was implemented to allow for the use of features that were being developed and thus that these enhancements should not be fundamental to the usability of the site. We are now seeing some sites with a ‘best viewed in a WebKit based browser’ proviso, I really thought that we had grown out of this stupidity after the ‘best viewed in IE6” days of long ago. It never was and never will be a good way to build web sites or web applications.
If your site is one of these, I suggest you go back now and re-code it. This not to say that these extensions are evil and that you should not use them, far from it. But the important thing is always to bear in mind that you should code for as many user clients as possible. If you feel that you have to use CSS extensions to achieve the effect that you desire then you should also use them to support a similar effect in non-WebKit based browsers. In doing this your simple attempt to use a border radius on a box can go from:
border-radius: 1em;
To:
-moz-border-radius: 1em;
-webkit-border-radius: 1em;
border-radius: 1em;
As you can see, your style sheets can grow in complexity fairly quickly. Worse than this though is the issue that these extensions are not standards and the exact syntax is liable to changes from the browser manufacturer, with all the updating headaches that can bring.
Prefix-my-css takes some of the work of building style sheets by adding Vendor Prefixes but is it a good idea to use them?
Whilst there are web sites like http://prefixmycss.com/ that will convert your CSS and add the vendor specific prefixes or installable applications that will convert of CSS code and generate a new style sheet like http://cssprefixer.appspot.com/ neither of these are automatic, so should a change in a vendor prefix happen, often the first you will know about it is likely to be when a visitor to your site emails you to complain. The client-side javascript based ‘prefix-free’ http://leaverou.github.com/prefixfree/#test-drive is an interesting way around this as it generates the vendor prefixes on the fly as a user browses your web site. You have no control over this conversion but at least your style sheets can become tidier and easier to maintain. You may be asking yourself why all these vendor specific prefixes? Why do we need them? Well a lot of the time we don’t NEED them as they often deal with graphic effects like rounded corners, and shadows to text and boxes, so they give an easy way to achieve some of the previously tricky effects that our clients ask for. The trouble starts with some of the other prefixes that deal with effects like transitions and transformations which could have an effect on the user interface and so affect the working of the application. If you want to take a look at a comprehensive list of all the differing vendor prefixes and their equivalents, where available, in other browsers then there is a list at http://peter.sh/experiments/vendor-prefixed-css-property-overview/ .
There are a large range of Vendor Prefixes and any of them could change at any time
By coding specifically for WebKit browsers we are in danger of building web sites and applications that either only work or look their best in one sub-set of user clients, albeit a large and ever growing one, but I think everyone will agree that we don’t want to go back to the times when we had to switch between browsers to use certain sites. Oh sorry I forgot we are still there! Isn’t it about time that all the browser manufacturers adopted the WebKit rendering engine and then leave us to write the great sites and applications without us having to waste time checking for compatibility and researching fixes for CSS ‘bugs’ that cause rendering differences? Come on Microsoft and Google, it’s your turn next to embrace WebKit in your browser. Then we might also end up with development tools where the design view is the same as the view that you would get in a browser and we can finally stop using text editors to build graphical pages.
Article by: Mark Newton
Published in: Mark Newton