Browsing Posts in HTML5/CSS3

Since June 2004 and it's subsequent first working draft in Jan 2008 HTML5 has, and still is, in flux with a stable recommendation finally slated for the end of 2014, but even as I write HTML5.1 is now being drafted.

One of the many great components of HTML5 was the promise of ubiquitous video and audio content. However due to patent issues, mainly H.264 decoding (licensed through MPEG LA acting as a consortium to these majority stake MPEG Patent holders: Apple, Microsoft, Panasonic, Sony, Dolby, Thomson, and Toshiba (*B)), we've been left with somewhat of a pseudo mash-up of native HTML5 video and Flash Video wrappers unless you wanted to support multiple formats in addition to H.264, namely OGG/Theora.

For a while now Flash has offered a TRULY ubiquitous platform for delivering video and audio content. Gone were the days of having to support .mov for Mac and .wmv for PC

Due to costly patents and the Open Source ethos of projects like Firefox and Opera, these projects have had to, until now, leverage open-source video codecs. Which has led to a slower adoption of video / audio tags in HTML5 across the web.

Spurred on largely by it's Mobile efforts (FirefoxOS) Brendan Eich at Mozilla wrote (Mar 2012) a rather lengthy blog post about their decision to finally, now, adopt H.264.

Instead of building software H.264 decoding directly into the browser they've avoided costly patent fees by relying on H.264 decoding at a hardware level.

What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G (*A) and survive the shift to mobile.

Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance. So I am fully in favor of Andreas’s proposal.

What this means, in short, is that H.264 decoding is now supported in Firefox on a variety of hardware except for Mac OS X due to this bug

OK. This one took a while. Would like to thank Nicolas Gallagher over at HTML5 Boilerplate whose post put me on the right path.


Using native HTML5 video/source tags in an HTML4 XHTML Transitional (Yes! not semantic, but legacy requires it) !doctype destroys the native video controls on a Samsung S3(SPH-L710) running Android 4.1.2 (and possibly other Android versions).


After a few minutes Googling I found this thread on GitHub where the chaps working on HTML5 Boilerplate were running into similar issues. It turns out that simply declaring a generic: input{[some styling];} in CSS destroys the native HTML5 video controls on Android. The resolution, it turns out, was simple. Prefix the generic input with html html input{[some styling];}. That's it!

Hope this helps some folks out. Took me a while to figure this one out.

Came across this one today. A DOM element had CSS3 border-radius: and box-shadow: attributes applied to it. Worked perfectly in everything except good old Internet Explorer, specifically IE9.

Turns out the reason for my ugly looking border-radius: and box-shadow: effect (instead of my nice smooth, anti-aliased shadowed corners) was because a legacy filter: dropshadow(color=#e0e0e0, offx=0, offy=1); attribute had been applied to affect/hack the newer CSS3 text-shadow: attribute for IE8.

Turns out, as of IE9, most of the filter: attribute methods on MSDN are officially deprecated.

Simply removing this attribute and replacing it with the newer, CSS3 standards based, text-shadow: attribute corrected my hideous looking, black rounded corners/box shadow effect in IE9.

Not sure if anyone else is looking to solve this, but hope it helps in some way.