I just had a wonderful time on the train home reading Jeff Croft’s Two Thousand Twenty Two post, following the whole trail of comments is like watching a TV show. I got to the end although there is a distinct lack of explosions, car chases, gracious nudity or even kittens!

In essence, Jeff (who is a top chap to meet in real life – let’s not let personal hygiene become an issue here) makes fun of an interview about HTML5 that he read:

Today, it was brought to my attention that HTML 5 Editor Ian Hickson, in an August 27 interview with TechRepublic outlined a timetable for the “new” spec, which began life back in 2003. Hixie suggests HTML 5 will reach the “Proposed Recommendation” stage sometime in 2022. Go ahead, read it again. It’s not a typo. Two thousand twenty two.

As a result, and mocking the, shall we say, adventurous outlook of seeing 2022 as an foreseeable goal young Jeff in his innocence managed to kick off a trail of comments that must have registered in some earthquake pre-warning centre in Southern California. He dared to say that he is done with reading specs and that today is more important:

I care about right fucking now. My clients care about right fucking now. Our users care about right fucking now. The only people that really give a damn about two thousand twenty two are people who write timetables for a living.

Potty mouth language aside, there is some truth to that. I was also pretty impressed with the following:

We’ve all learned a lot through this standards movement. We are now capable of identifying a good idea when we see it (like the namespacing of experimental CSS properties, for example). We are equally capable of knowing when something feels inelegant (like maintaining different code bases to achieve the same thing in multiple browsers). Our bullshit radar is strong these days. We don’t need a spec to tell us whether something is useful or not (XMLHttpRequest was incredibly useful, despite not being a ‘standard’).

Check out the post and especially the long trail of comments. It reads like the oh so classic misunderstandings we have to deal with every single day on the web: humour and sarcasm and irony do not translate in online reading unless you really lay it on thick. There’s the “oh I understand, I really have nothing against you personally”, there’s the “read the thing again, you missed the point”, there’s also the “people will quote this wrongly” which is sadly enough the case.

So, before you bring the pitchforks and torches: Jeff is not a traitor to the cause and he is not the “designer that doesn’t get standards as they want their own stuff all the time”. It was a funny sarcastic remark that shows just how inbred a lot of discussions around standards have become.

A standard to me is an agreement between several parties to deliver a certain task to make it easy for all parties involved to deliver to the best quality with the least effort. It is something to take out the random element of any delivery and battles having to learn the details before delivering a job we should be able to deliver easily as we’ve done it before. Not more and not less. It is about aiding working together, making handover very easy or even obsolete and making sure that what we build works where it is supposed to work.

What messes with our goal is that we are moving fast and innovating a lot whilst the market we cater for is less happy or able to keep up with our pace or doesn’t see the need for being up-to-date. This is the real issue that needs solving.

I just spent an hour on the cycle in the gym watching the video of Douglas Crockford’s Web Forward presentation on my iPod touch. Douglas makes some great points about the state of the current technology for the web – especially browsers – being counterproductive to innovation.

I agree with all of what Douglas says (especially the security aspects of JavaScript and the need for vats), but I am not too sure about the notion at the end that we need another browser war to go forward.

I understand Douglas’ point about browser vendors and users knowing what they need, but I also see a big danger in allowing the way we work on the web to become multi-track once again. I worked through the first browser wars, and I am thoroughly sick of having to write code to work for one or the other browser. This is why we use libraries to work around these issues. The thing that is a bit academic about the view that browser vendors could fuel innovation by navel-gazing is that the end users are not really going to upgrade their browsers just to make our lives easier. Even serious security flaws don’t really get people to upgrade their browsers (I am not talking about us geeks, I am talking about offices and home users that just want to read their mails and get the news). We can innovate until the cows come home, but if it doesn’t reach the people we work for this is progress that makes us move away rather than forward.

I agree with Douglas that the W3C standards are a failure when it comes to innovation. For starters they haven’t moved in ages and the standards are not nearly as good as they should be to make us work efficiently. The DOM standard is too complex, HTML does not really provide what we need to describe interfaces and interaction and CSS is not the layout engine it could be and we need to hack with positioning and floating just to get a multi column layout.

You have to cut the W3C some slack though – if browser vendors hadn’t concentrated on putting bespoke functionality in browsers and followed the guidelines we’d have had a much easier life as web developers in the last few years and could have concentrated on working with the W3C to get the standards extended. This has improved immensely in the last years and even the biggest evildoers now got the CSS2 specs supported in the 8th revision of their browser. Communication is happening, the problem is speed.

The process of the W3C is academic and broken, I do very much agree with that. The WHATWG are kicking butt left right and center with the HTML5 specs and got a good gig going working with browser vendors to get support for what they do. I think this is a great approach and seeing that the W3C is now looking at HTML5 in favour of the overly complex XHTML shows we are moving in the right direction.

What I lack in the proposals of innovating with techies is that a standard is much more than how it works technically. This is what we have already done in the first browser wars: we coded to make it work. It bit us in the butt a few years later as what we built was either flaky and broke or bloated and full of hacks that are not needed any longer (I doubt you’d ever need a if(document.layers){} these days).

Web Development is a very frustrating and complex job. Simply making things work to me is not enough – it needs to work, be usable and easy to understand for developer who take over from you. Hacks and browser specific solutions are the opposite of that.

To me, pragmatic development means “keep it easy to understand”, not “make it work in all browsers” as “all browsers” is a very moving target. The danger we are running into right now is that we are looking at (bleeding) edge cases and see them as innovation and great pragmatic ways of working. I am a big fan of performance tweaking and saving bytes wherever we can. However you can overdo that. As Dustin Diaz explained Google are using as their doctype to save on some bytes and David Calhoun proved that it is working across the browser board right now. Fine and in the case of Google or Yahoo this does make quite a difference. However, a DOCTYPE is not only there to trigger standards mode – this is a nice side-effect. Its purpose is to tell user agents (and that is more than a browser) what the document is, how it is structured and what elements are allowed in which hierarchy. If you wanted to convert a document with this “skinny doctype” you are in trouble as the conversion tool has to hope that all is fine and dandy. Systems like Yahoo Pipes or YQL are a great way of getting data from the web and re-using it. If the data we put out on the web is not in a format we can rely on being valid, this data is unavailable.

I like to see the web as a pool of semantic and linked information, not as a collection of documents that render correctly.

At least one thing is for sure: this year will be interesting in terms of innovation and how we build for the web.

Check out Douglas’ video:

(I am tempted to add VNV Nation’s Darkangel as the ambient soundtrack)

It is quite fascinating to me that the newest article on dev.opera.com entitled ‘Stop using Ajax!’ is such a big thing right now. Tweets, shared bookmarks and Google Reader items are pouring in and people seem to consider it an amazingly daring article.

Here’s the truth: James is right. He also was right when he more or less gave the same information as a talk at Highland Fling last year following my presentation on progressive enhancement and JavaScript.

However, there is nothing shocking or daring or new about this. All he says is:

• Don’t use any technology for the sake of using it
• Consider the users you want to reach before using a technology that may not be appropriate
• Make sure your solution is usable and accessible
• Build your solution on stuff that works, then enhance it.

This is what I consider to be a normal practice when developing any software or web solution.

However, the real question is now why we are at this state – how come that we see this information as daring, shocking or controversial, and how come a lot of comments are still “I don’t care about accessibility because it is not needed for my users”? How come the assumptions and plain accessibility lies are prevailing while the good stuff remains unheard of?

Well, the truth is that we have been preaching far too long to the choir. I’ve been in the web accessibility and standards preaching community for a long time and whenever I asked what about enterprise development and CMS I was told that it is not worth fighting that fight as “We will never reach them”. Well, this is where the money and a lot of jobs are and it is a fact that both accessibility and standards activists in a lot of instances don’t even know the issues that keep the stakeholders in these areas busy. My Digital Web Article ‘10 reasons why clients don’t care about accessibility’ and the follow-up Seven Accessibility Mistakes Part One and Part 2 listed these issues and the wrong ways of how we try to tackle them 3 years ago. My talk at the AbilityNet conference last week Fencing-in the habitat also mentioned this attitude and problems.

Here’s where I am now: I am bored and tired of people fighting the good fight by blaming each other’s mistakes or pointing out problems on systems that are within reach. When people ask for accessibility or Ajax usability advice you’ll get a lot of bashing and “go validate then come back” answers but not much information that can be used immediately or even questions that ask what lead to the state of the product. You’d be surprised what you can find out by asking this simple question.

We have to understand that large systems, frameworks and companies do still run the show, even when we think that bloggers, books on webdesign and mashups push the envelope. They do, but so far they are a minor discomfort for companies that sell Ajax and other out-of-the-box solutions that are inaccessible and to larger parts unusable for humans. When was the last time you used a clever expense or time tracking system in companies that are not a startup or a small web agency? When I was at the AjaxWorld conference in NYC earlier this year I heard a lot about security, ease of deployment and scalability but only a little bit about accessibility (the Dojo talk and the YUI talk, actually). People are a lot more concerned about the cost of software and the speed of release than about the quality or maintainability. It is cheaper to buy a new system every few years than to build one that is properly tested and works for all users. Does your company still have systems or third party solutions that only work on IE/Windows? I am sure there is at least one, ask the HR or finance department.

It doesn’t help to coin another term and call an accessible and usable Ajax solution Hijax, either. As much as I like the idea of it I have to agree with James’ comment – we don’t need another word, we need a reason for people to not just use things out of the box without thinking about them or – even better – offer help to the companies that build the solutions on assumptions in the first place. When I ranted about a system by a large corporation some weeks ago on twitter their marketing manager for EMEA starting following me and I am starting some talks with them.

I have heard numerous times that my ideas about progressive enhancement and accessibility are just a “passing fad” and “that in the real software market you don’t have time for that”. Challenging this attitude is what makes a difference – by proving that by using the technologies we are given in a predictable and secure way does save you time and money. However, there are not many case studies on that…

I cannot change the world when I don’t know what obstacles people have to remove to do the right thing. Deep down every developer wants to do things right, in a clean and maintainable fashion and be proud of what they’ve done. Bad products happen because of rushed projects, bad management and developers getting so frustrated that they are OK with releasing sub-par just to get the money or finally get allocated to a different project.

This is the battle we need to fight – where do these problems come from? Not what technology to avoid. You can use any technology in a good way, you just need to be able to sell it past the hype and the assumption that software is developed as fast as it takes to write a cool press release about it.

This is the presentation I have just given at the Coder’s Saturday in Montreal, Canada. The theme revolves around the adoption of standards and why this is important not only in a technological sense but much more necessary to appear as a professional developer. Most standards we talk about are really recommendations and we need to find convincing arguments why people should follow them or even why they are important to us.

Ok, as several people wondered (in tweets and emails) what my stance on the whole IE8 malarkey is, first of all an explanation why I didn’t bother to blog about it yet:

• I was busy with more immediate concerns about my professional future
• Far too many people already blog about it, speculating this or that way and cross-link the same speculative articles over and over again. This will make it hard to find real information once we know the outcome of the dispute (and it is still a dispute as the rendering issues are only the tip of the iceberg). But hey, hits for their blogs = teh win!
• I am lucky to be on a mailing list consisting of a lot of very clever people who are involved in the development of a lot of the big JS libraries and are part of companies that will have an impact on Microsoft’s decision and there is a full out email avalanche going on there.
• It will be damn hard to beat Katemonkey’s explanation of IE8 and lemurs anyways

Now, to sum it up in some short words: Microsoft is in a pickle, or let’s say in between the devil and the deep blue see

The Devil – all the old badly developed sites

The biggest issue for Microsoft is that they “don’t want to break the web” – or in reality all the web sites that were built believing in the promise that Microsoft or WYSIWYG products create future-proof code. These are a part of the web – in a lot of cases the part that is behind a firewall and start with “intranet.company”

The Deep Blue Sea – standard aware web developers

The other big party Microsoft tries to make happy are the standard aware web developers. You might now say freaks and why bother when the enterprise market works happily without it but let’s remember what the benefits of working with standards is:

• interoperability
• option to convert to different formats in the future
• making web development a more mature job, and not something anyone can hack together – which also makes it easier to assess the quality of applicants and hire them faster
• ease of bug tracking and QA (you know how it should work and can find out what caused it not to)
• ease of maintenance, as developers see what is going on and don’t have to try to understand what the earlier developer has done, fail in doing so and just slap some more code on at the end to make the product work.

Microsoft’s relationship with these people has never been easy but improved a lot in the recent months. The IE team took research found on the web to fix CSS problems of IE6 in IE7 and have invited experts to help them make IE better. The problem that still persists is history. Let’s do a quick time travel:

Pitch situation (around 2003)

Freaky, border-line hippie small agency: Hello Mr. Moneybags, you asked us for an offer for a web portal for your company that covers both the outside world and your employees’ needs. Here’s what we came up with. You might see that we did some extra time padding to make sure we follow web development standards and test on different platforms to ensure that everybody in and outside the company can use the system.

Man in suit: Hello Mr.Moneybags and thank you for asking us to provide you with a new e-portal covering intranet and internet with CMS and customer care features. Well, you are in luck! We will be using industry leading systems by Microsoft and Oracle to give you a system that ties in seamlessly with your current infrastructure needs. Let me see that computer, ah! Internet Explorer. You’ll be happy to know that what we give you will work with this and with your Outlook solutions! And the best is – we have fixed prices for initial delivery and a very good customer care program (but that is an agenda for another meeting in the future).

What did you think Mr.Moneybags went for?

OK, so let’s help Microsoft with their problem

Now we have a situation where the proposal is to add another META element to ensure that these problems don’t happen. This doesn’t seem much, but it is once again delivering extra work to please one browser on the internet and follow the standards other vendors have much less problem adhering to. Let’s not forget that we already did that when the other MSIE’s came out:

• We do use DOCTYPE switching and don’t use an XML prologue for XHTML (oh, wait, we don’t do XHTML as MSIE doesn’t support it)
• We grumbled but we agreed to use conditional comments as the most useful way to patch for MSIE
• other browser vendors started supporting MSIE-only solutions like innerHTML and clientWidth not to break sites that were built for IE only. Isn’t that enough good will?

Then we got the carrot of “IE8 supports Acid2” and went “Wahey! No more hacking for IE in the future” and got the cold shower of this proposal. Again we were let down.

But what about the broken web?

The broken web is there because salesmen and product descriptions promised something they cannot deliver – that by sticking to a monoculture you can save time and money. History proved that the brave new world of interoperability of products from one single company does not happen. People have the choice of different operating systems and browsers and they should have that. Many councils and schools in Germany for example completely moved to Linux solutions in order to save money – and it works.

I get the distinct impression that the broken web is not as big as we make it to be and if it is then it really is broken because it was built on wrong assumptions and developed with shortcut after shortcut sacrificing maintainability and interoperability.

How many intranets, expense systems and room booking software did we have to use that did not only work in IE exclusively but also were borderline unusable as they considered options a nice to have rather than a decision to make? How many intranet systems are inaccesible to non-JavaScript users, keyboard users or blind people? Yes, it is hard to make a company change these systems, but for Pete’s sake, let’s get rid of this cruft!

Web-Appers and Microsoft unite

And this is what I think is the main step forward: instead of trying to accommodate for a broken web that should have been ditched years ago we should offer patches, tutorials, coaching and mentoring for maintainers how to upgrade these systems.

As most are built with frameworks and CMS and one of the main selling points of these was that the outcome can be easily changed in the future, how about proving that now? In the last few years we shifted more and more away from web site development to web app development and I have yet to see a big impact on the enterprise market. I see a lot of cool RoR tools for the lower and middle market, but nobody takes on Mr.Moneybags and counteracts the promised of the men in suits.

So please, Microsoft, launch a “make your systems more secure, future proof and available” campaign with fixes, patches and good information and I am happy to chip in. I am much less reluctant to cover your butt once again though just to prevent you from having to admit that things change. You ditched all DOS applications when you simulated it in more modern windows than 95, why not show the same power of decision making now?