A Standard HTML5 Standard Standard
After working on www.wayoutwars.com, and tinkering with other ideas since, my original thoughts on HTML5 increasing the gap between browsers is becoming apparent. Having the HTML standard is awesome, but until everyone has a standard approach to the standard, we’ll still be making exceptions.
Not everything in this post is HTML5, more HTML and JavaScript in general, but with HTML becoming an evolving standard it makes it more important for there to be consistency as adoption of HTML features will become increasingly staggered.
The core issue is with interpretation, and/or certification. Who certifies that a browser is HTML* compliant? Whether it’s a central body, or an individual tester, they need to ensure there is consistency, but in the scenario of the individual tester, what is the benchmark? If text is being rendered on the page, what are the metric to measure that it is rendered correctly? I’ll take a step back from HTML to explain.
Bad Jump
If I was to write a specification for a computer game, one of the aspects to be described is controls. To simplify it for discussions sake ”when a player hits ‘fire’, the character will jump. Jump duration is a maximum of 2 seconds, to a height of 10 units”. But how this occurs has many options:
- Is there in air control?
- Is there hang time at peak or is it a parabolic jump?
- Does the character slow down in the air?
- If the character hits a ceiling/wall do they fall immediately or still hang?
- …
New initiatives in games are benchmarked against all the previous successors. There is always a parallel. This is why jump times in all 2D platform games are about the same.
Coming back to HTML, the standard may be open for interpretation, but just because a new standard is being implemented doesn’t mean that the function of the standard should behave any differently that you would normally expect.
I’ll start with the basics.
Text Rendering
One of the fundamental things that every browser does and has done since the beginning, is render text. Visually, this is the primary concern of the browser. So one would expect that this is something that does not merit discussion.
As such, I’m not sure how this gets through testing, but take a look at the following in Firefox and in parallel have a look in Chrome and IE9.
Chrome just AA’s the entire thing into a blurry mess, but at least it makes sense, if undesirable. IE9 realises it’s rendering text, and does more intelligent text smoothing.
But Firefox’s behaviour be described as a bug. By default, text should be render with no anti aliasing, and if you have some smoothing it shouldn’t degrade the legibility of the text. Having to design for another browser, or cater for it in code, is bad. This just makes everyone design in to keep their designs predictable and maintainable. For those without HTML5, or Firefox, or super sonic zoom eyes, let’s have a closer look at FF’s rendering.
NOTE: You do not need 3D glasses to view the above picture.
Once your eyes stop bleeding, lets look at what is actually being rendered. Anti aliasing with shades of red, green, and blue? What is going on here isn’t in the style of Apple IIE monochrome monitors (for those that remember) but actual colours being rendered. A single vertical line has a line of blue, a line of green, and a line of red. Did anyone actually test this? It’s like no one knew how to do text smoothing, so they just put 1 of each colour around the text.
Also notice how the vertical line in IE is doing anti aliasing on the 1 pixel line, making it appear transparent, and in Firefox it decides to make a 2 pixel wide line to avoid the issue altogether. So while IE9 has good text smoothing, the anti aliasing logic in both browsers is broken and inconsistent.
It also negates the awesomeness of WOFF and the Google font API if you have to use bitmap font templates to have consistency (and even then not 100% reliably).
Media Handling
MP3 vs OGG. I’ve stated my views on this. Support OGG if you want, but don’t ignore MP3 if you want to be serious about creating a media rich web. MP3 is out there, everywhere, and creating a barrier for innovation is dumb.
I won’t start on video codecs, that’s just too much of a mess for now.
Secondly, the extremely poor memory management regarding audio. In all browsers, eventually media elements hit a limit. For most sites this isn’t an issue. But at about 50 megs of audio, IE9 stops loading new audio, even though the previous audio elements were removed. They had to be ‘delete’ed. Chrome hit this issue a few tracks later.
When deleted every browser behaves consistently and smoothly, except Chrome, which goes silent for no apparent reason at around 280 megs of audio.
You may ask why on earth would a page have 280 megs of audio? This isn’t isolated to www.wayoutwars.com but is also a problem for audio stores where you can preview sample audio, and online radio such as www.lastfm.com that could be playing gigabytes of tracks.
JavaScript
I’m not talking syntax, but being able to crash a browser in JavaScript doing a standard JavaScript call just isn’t acceptable.
The line was ‘delete a;’ where a was null. I was trying to reproduce the error, but in isolation it seems to work. Why does it crash Chrome but not consistently? I’m currently assuming it’s to do with Chrome trying to be smart around garbage collection that is not thread safe.
Never mind whether the syntax used is good form, JavaScript should not crash the browser. And since it crashes the browser, it doesn’t throw a JavaScript error, and has to be debugged from an external debugger like Visual Studio.
Final Thoughts
My biggest issue is that we’ll end up in a world supporting multiple codecs for audio and video to support different browsers, increasing cost of implementation, and reducing budget for innovation.
It’s not all doom and gloom, but for the discussed issues, and others, I feel that there is no short term win. The LCCD (lowest common common denominator) consistently will be the target platform.
Flickr
|
