In yet another interesting turn of events, two of the biggest issues when it comes to web design and development make way for the newer, better versions of themselves.
Goodbye, IE6!
Asa Dotzler of Mozilla reports that IE6 usage has now been overtaken by IE8, based on the browser tracking data from Net Applications. This happened as recently as June 2009.
Of course, specific demographics on your respective websites will vary, but this trend is a sign of things to come. And we’re not talking about years anymore, but months.
I’d have to commend Internet Explorer team on their great marketing efforts to improve the IE8 adoption rate. Even if Microsoft’s latest browser is up to snuff compared to the likes of Firefox, WebKit (Safari/Chrome), and Opera—see these comparison charts for HTML5—it’s a big step.
This is it, guys. Freedom.
Goodbye, XHTML2!
Slashdot reports that the XHTML2 Working Group charter is expiring by the end of 2009, and it will not be renewed. The W3C has also decided to pour more resources into the HTML5 working group.
Those who weren’t paying attention to this seeming sibling rivalry between XHTML2 and HTML5 can now rest easy. Though I’m not sure if XHTML2 ever stood a chance given how all the web gurus were backing HTML5 as early as last year. Google is on board, too. And everybody else is starting cash in on its growing popularity.
The good thing about XTHML was that it enforced well-formed markup, with strict provisions for lowercase code, quoted attributes, and trailing slashes for empty elements. Thankfully HTML5 this coding convention too, and can be served as a serialized XML document dubbed XHTML5.
At least we wouldn’t be forced to choose between the two anymore. Competition is good, but not here. We need standards.
Unwanted competition eliminated
How convenient is it that we have two less things to worry about now? Very, but now that they’re gone, it’s time to make up for lost time:
- Microformats. (This is the easiest to jump into.)
- Fluid layouts.
@font-face and custom web fonts: this time it’s not just the browser makers that web designers and developers are up against, but the type foundries. TypeKit and Kernest are attempting to bridge that gap.- CSS nested declarations, variables, and operations: LESS
- CSS if statements: Modernizr
- Animated PNGs.
Exciting times, people!
Eric Meyer has started poring over the WaSP community’s suggestions for CSS3 with a series of posts on his weblog—3 so far in less than a week. The original feedback compiled by Fantasai is a monstrous read in itself, but all these are worth perusing if you care remotely about the future of web design.
It’s comforting to have one of the gurus like him to really go over this. Although he didn’t promise to address every single point on the list, what I’m seeing so far is extremely comprehensive. More importantly, we have a strong figurehead that’s rolling up his sleeves and setting up these blog posts as the stage for discussion with people who are not necessarily involved with the W3C and other stakeholders like the browser vendors.
Between debating over specific CSS features (e.g., containing floats, center positioning, selector blocks) and looking at the bigger picture…
Maybe CSS isn’t the place for this. Maybe there needs to be a new layout language that can be defined and implemented without regard to the constraints of the existing CSS syntax rules, without worrying about backwards compatibility. Maybe that way we can not only get strong layout but also arbitrary shapes, thus leaving behind the rectangular prison that’s defined the web for almost two decades.
I don’t have a concrete idea to propose here, because it’s not up to us any more. A solution was worked out over the course of several years and then found wanting by the implementors. Really, it’s up to the implementors to figure it out now. I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they’ve defined something that works and they’ve all agreed to implement soonest. I might even supply food and water.
…we have to keep talking and stay restless but hopeful. We may not be able to give the final word on the next version of HTML and CSS and the web browsers, but we can talk about what could go into them while the W3C listens.
IE6 is declining. HTML5 is gaining traction. JavaScript libraries and CSS frameworks abstract the process of squashing browser bugs and incompatibilities. And progressive enhancement reassures us that we don’t have to serve up exactly the same features in ancient browsers.
And maybe we can stop acting like the current technologies are our handicap and take the plunge. Okay, maybe splashing water all over might not be a good idea at once. Try dipping your toes. Try your left leg. Try wading. The key is to at least try.
All the hoopla over Everything You Know About CSS Is Wrong!, a book by Rachel Andrew and Kevin Yank (see also the Digital Web article) is making me feel uneasy.
We’re not wrong; the title is wrong
I detest the title of the book. No, I don’t think “everything” I know about CSS is wrong. I “know” about the display:table technique for months now (thanks to Sitepoint, again).
Neither do I think it’s a good idea to go around belittling people by telling them they are wrong, whether in printed book or online article format. It’s harsh and misleading.
We’ve got issues
As for the CSS Tables technique presented in the book, these are some of the issues plaguing it:
- tag soup
- lack of source order control
- the question of semantics and presentation vs. content: is making
<div>s behave like tables/table cells any different from using tables as layouts?
- IE6 and IE7 incompatibility (no surprise there!)
And not too long after the uproar, the authors have addressed the above problems:
Andrew Tetlaw responds to #1 and #3:
No one is negatively affected by the overuse of structural div tags. The same can’t be said for the use of HTML tables for layout.
And here’s an interesting quip which points out the very valid woe of web developers, who have had to adjust to all these changes in coding conventions because of our “flakiness”:
Congratulations on years of punishing web devs for using common sense. Finally the circle turns, but somehow you think that you were ‘right all along.
Matthew Pennell of Digital Web has this to say about those who question semantics and standards:
I must say that I’m surprised that an audience of (presumably) conscientious, standards-aware developers are almost all declaring that they will not use new features of CSS when they are available and supported. Are you all so short-sighted that you cannot see any application for the techniques discussed here beyond wholesale replacement of site layouts?
And Rachel has written this regarding #4:
Some commentators have suggested that we shouldn’t have put a book out about a technique that can’t be used immediately, that will require workarounds to still provide support for older versions of Internet Explorer. I disagree. Something I point back to in the book is how the web community began to use CSS for layout even though support in Netscape 4 was limited and buggy. If those of us who were building CSS layouts right in those early days had said, “nah, it doesn’t work in Netscape, can’t do it”, then our recent history would look very different.
Are we hesitant about change and innovation?
In a sense, browser usage does “cripple” our ability to look towards a future of web design innovation (and bliss) when IE6 is finally disappears. But are things right now are exactly the same as when Netscape Navigator 4 was the stumbling block?
More importantly, will the CSS Tables technique actually push our level of innovation by a significant degree? The past few months of new websites tell me innovation is not too hard to come by still.
And what about next-generation HTML5, which will have new structural tags like <header>, <section>, <article>, <footer>? Can one not feel guilty using all those <div>s in the midst of these elegant new tags? Perhaps that’s another debate for another day—in 2022.
When will the next version of HTML be ready? Apparently, we have 4859 days to go before HTML5 reaches the “Proposed Recommendation” status. That’s 13 years, according to Ian Hickson, editor of the HTML5 specification.
It’s been 10 years since HTML4 came out. And it will take a total of 19 years for HTML5 to come to fruition. Here’s staggering journey HTML5 has gone and will go through:
- First W3C Working Draft in October 2007.
- Last Call Working Draft in October 2009.
- Call for contributions for the test suite in 2011.
- Candidate Recommendation in 2012.
- First draft of test suite in 2012.
- Second draft of test suite in 2015.
- Final version of test suite in 2019.
- Reissued Last Call Working Draft in 2020.
- Proposed Recommendation in 2022.
So what do we do about this excruciating piece of information? Jeff Croft says we should just go back to work. And ignore HTML5 until we absolute don’t have to.
If and when HTML 5 becomes something that can help me serve my clients and the users of their websites, then I will absolutely learn all there is to know about it and incorporate it into my arsenal. Until then, I don’t see the point.
It’s only a bit disappointing since the knowledge of the beautiful things one can achieve with HTML5 has been coming and going for the past few years now. But the thing is, as Kroc Camen said, “HTML5 is doable in the here and now”—his site is excellent proof of that. Except, of course, it will take extra work for it to work properly as not even the standards-compliant browsers support it. Which brings us back to Jeff Croft’s point.
In an interesting development regarding web standards and the browser wars, Ars Technica reports that Mozilla is taking Internet Explorer’s problematic webpage rendering into its own hands starting with a plugin for HTML5′s canvas element.
IE’s shortcomings won’t hold back the Internet for much longer, however, because Mozilla plans to drag IE into the next generation of open web technologies without Microsoft’s help. One of the first steps towards achieving this goal is a new experimental plugin that adapts Mozilla’s implementation of the HTML5 Canvas element so that it can be used in Internet Explorer.
Vladimir Vukićević says it’s “a very direct way of getting 2D (and soon 3D) graphics into web pages, and removes many of the barriers between developers and graphics rendering.” Here’s a screenshot of how it works:
HTML5 Canvas on IE, by Vladimir Vukićević
Mozilla doesn’t stop there, though. It plans bring its “next-generation JavaScript engine directly into Microsoft’s web browser” through a project called ScreamingMonkey. The plugin strategy will also be employed here.
Mixed reactions
Reactions from the crowd range from amusement to confusion to outrage. On the one hand, this move from the makers of the record-making Firefox browser is commendable. It shows that in the midst of IE’s dominating market share and FF’s sheer drive to beat it, Mozilla still wants the Web to work, one way or the other. Even if it means having to “drag IE” itself. Indeed:
Is it a sad or happy day for Microsoft, when their competitors get bored with beating them, and instead try to improve the Microsoft products to make them competitive – for free?
And what does Microsoft have to say about this? Isn’t this an insult wrapped inside a well-meaning gesture since it is coming from a competitor? Anything that gets Microsoft’s attention to hurry things up in the web standards compliance department is okay by me.
Try Adobe
But it’s not just about the browser vendors but the users themselves. How many of them will take the time to install this not-so-popular plugin? Do they care enough to see the advantages? Ars Technica thus wonders if Adobe could have been the better messenger, since Flash is ultimately indispensable these days:
This is purely speculation, but If Adobe decided to ship Screaming Monkey and the Canvas functionality as part of the next major iteration of the Flash plugin, it would rapidly accelerate adoption and get it onto lots of computers.
Cross-browser nirvana? Not quite
News of this plugin suggests that it’s taking a so much effort to make IE play nice that even competing browsers have to step in. And we’re only talking about the HTML5 canvas element here, a far less common feature, or should we say issue, than things like the double-margin bug or pixel font sizes.
*/
