Did standards sterilize or enrich the web?
I know, I know, it is not very nice even to ask this question, especially coming from a Microsoftee. But really, I'd like to know what you think. We have had many discussions on this subject in the team and many of us have very sharply defined opinions one way or another.
On the one hand, standards have enabled the adoption of some innovations by all important browsers so that you can actually use them and not limit your audience to users of a specific browser, without having to write the same application three times.
On the other hand, it is impossible for a web developer to use a new browser innovation because it needs first to be standardized, adopted, implemented by all and the implementations need to be installed by a majority of users. It usually takes about five years. That's why we have the Ajax boom only now whereas the technology has been available for a very long time.
Of course, standards are not really responsible for that. But there's worse: any browser innovation is likely to be severly criticized as not being standard. There's a chicken and egg problem here that's not trivial to solve.
Furthermore, if you look at some of the nicest things in Ajax applications, they are not part of any widely adopted standard. I'm thinking in particular about things like XmlHttp and online HTML editing for which standards may have been drafted but were not adopted: the browsers agreed on the APIs in the absence of standards.
So honestly, what do you think? Any bright ideas on how to have both standards and innovation in the Web browser space?
Update: some answers to your comments (by the way, thanks for their excellent quality)...
Michel, who was first to comment, pretty well sums it up.
Joakim made the very interesting point of accessibility. This is right on point. That's an area where the standard is absolutely necessary, but it falls short on a few things.
First, many web developers, if they know/care about the norm at all, tend to mark all the checkboxes and consider to be done. That's unfortunately not enough and experimentation is key to having a truly accessible site. Of course, that's a very expensive process.
Second, until very recently, browser support for essential accessibility features such as accessKey, tabIndex and focusability on all elements has been limited to IE (which has supported it for years). Firefox implemented it in 1.5 thanks to some code donated by IBM and I think Safari and Opera are still lagging behind on this (correct me if I'm wrong here). Screen readers are pretty much limited to Windows/IE.
I'm not even talking about JavaScript not being considered accessible: it does in fact create accessibility scenarios that would be impossible without it so that's a standard requirement that's safe to ignore if done properly, but you won't get to check that checkbox.
In Atlas, accessibility is a key goal. For example, if you set the tabIndex on a listView, it immediately becomes keyboard-accessible: you can tab to it, use arrow keys to navigate between items, select using the keyboard, etc. As we go, we're going to bake more out-of-the-box accessibility features into the controls. This is I think a great example of JavaScript enabling better accessibility.
Wesley comments about not implementing existing standards and about filters nicely extending them. Of course when the standard exists it should be implemented. Now there are quite a few cases where the implementation actually predates the standard and the standard deliberately decides to do things differently from the existing implementation. That's fine if there is a good reason and that's usually the case, but what is the existing implementation supposed to do? They can't break their existing customers (well, they can: it seems sometimes like Microsoft is the only software company to care about that
Now about filters. That is a *great* example of something extremely useful, entirely optional in the sense that if the browser doesn't know how to handle it it's fine to ignore and absolutely non-standard. The cursor style is another example. So everything looks nice and that's an innovation everybody should be happy about. Except that if you use this style and have the javascipt console open in Firefox (maybe strict mode is also necessary to see that), you'll see that it considers any non-standard CSS attribute as an error. Yes, as en error, not even a warning. Google's home page throws errors in the console because of that. So that's clearly a case of yeah, sure, standards, ok, but let's just not go crazy about restricting possible things to what the standard defined. There must always be an extensibility path. XHTML is great at that.
Steve makes the point that browser developers should work closer together, be it inside or outside standards bodies. Yep. It seems like this is starting to happen. He also asks what happened to JavaScript 2.0. Oh yes, I would also like to know. It would make our lives so much easier (in five years).
Joe gets constructive and proposes that vendors take on the task of providing better documentation for standards. That is a very good point: the W3C documentation is just horrible. But of course, this is due to their not being written to be reference documentation for Web developers. They were written to be a reference specification for browser implementers. There definitely is a need for a standard reference documentation for Web developers (yes, there are some efforts to do that here and there but nothing really comprehensive). Maybe that should even be a joint effort from browser vendors.
Stan: it's a little sad that you would think that we don't know/care/understand about web standards. I especially liked this sentence in your post: "If you understood CSS and Style Sheets and some of the unbelievable things that you can do once you understand what a selector is I think that your view of standards would change". It is really symptomatic that you would assume that we don't.
You raise very specific point so let me answer them.
Where did you see that our navigation controls do not have their scripts in separate js files? Menu and TreeView both have their logic encapsulated into their own files. The only javascript that we emit on the page is instance specific and thus can't be isolated into a separate file.
I'm with you on inline styles. This is a legacy of the time when not all browsers supported CSS. We now recommend that people use CssClass on their styles instead whenever possible. Visual Studio will make that a much more natural first choice in the Orcas timeframe.
On table tags, we've debated that a lot and it was just not possible to get consistent rendering across all supported browsers without them. I'm actually implementing a simpler menu control on my personal time (which is not a lot of time) that's based on list items, css and JavaScript. The thing is this does not conform to the same constraints as the ASP.NET menu. For example, it won't ensure consistent rendering across browsers, it will look funny out-of-the-box until you style it, the list goes on. My point is, that will certainly be a useful control, but it definitely is a different control and not the one we chose to implement, I think for good reasons.
It sure is really easy to implement a simple pure HTML+CSS menu. Now you tell me how to do the following with pure HTML+CSS and no JavaScript:
- delay the disappearance of a menu
- position the popouts so that they are always on the visible part of the page, including positioning it on the left or on the right of the previous one depending on the available space and the size of the new menu
- size the popouts so that they always fit in the visible part of the page and add scrollers if they don't
- keyboard accessibility (with arrow key navigation)
The list goes on. We did implement all that.
I agree that the master page ids are an annoyance but that is necessary as master pages are containers and we need to manage id collisions. That doesn't mean you can't put most of your javascript in a js file. You'll just need to initialize a data structure inline for your generic script to use, which should be a fairly small amount of script. I agree it's inconvenient and we're working on ways to make that simpler in Atlas.
The thing about the master page set in web.config not being handled well by the designer is a known limitation. It's one that I personally would have liked to see fixed in Whidbey but it was unfortunately cut. It's high on the list for Orcas.
Finally, the thing about XmlHttp is a little of a cheap shot. Let's put things in perspective here. XmlHttp was invented by Microsoft, which decided to implement it (way before anybody else) as an ActiveX control at a time when ActiveX was the big new thing. Several years later, Mozilla decides that it's not a bad idea and comes up with their own implementation (compatible at the API level, which is a nice gesture). They don't have ActiveX (good for them, yes) so they go for a built-in object. Cool. We can't recall all copies of IE and change the existing implementation, can we? So what we do instead is implement it also as a built-in object in IE7. What's wrong with that (except for the delay between IE6 and IE7)?
Update to this comment: Stan answers this and clarifies his initial comment. No hard feelings here but I think just an animated technical conversation.
Bob seems to be reasonably happy with IE. Wow!
Wilco makes the point that what we consider to be innovation on the web would hardly qualify as such in the desktop application space. Yup. I've had the occasion to say it before, if you can use truly rich client technology such as WPF, by all means do so. Ajax is about making the web better, not about making it better than your desktop.
Finally, I'd like to add a few things about other platforms that had different experiences with standards.
First, there's Java. In the Java world, which is a multi-vendor thing, a standard body is a necessary thing. Still, there is a fair amount of complaints in the community on how the whole JSR process is weighing on innovation and most of the innovation happens in open-source projects (again, correct me if I'm wrong on that: it's my perception). Some of that ends up in JSRs, some just die, some are never standardized but still live happily ever after.
Second, there's .NET. Being pretty much conceived as a single vendor thing, there was no absolute need for a standard. Microsoft decided to submit the essential parts of the framework to ISO and ECMA anyway, which enabled great innovations like Mono. But only the smallest working set is really standardized. It's working pretty well though and innovation is florishing.
And there's Flash. Until recently it's been a single-vendor, proprietary thing. Now that there's been some standardization and format opening, a lot of companies are innovating in this space (XAMLON is an amazing example).
Update 2: Rick has an excellent comment.
Update 3: Colin makes the point of standard extensibility, to which John answers that browser vendors should form comittees to decide which features to implement. While it looks like a good idea, there are several problems with that. First, isn't that exactly what the standards bodies are supposed to be? And second, doesn't that just prevent any form of competition between browsers? If they are all the same, why not just group our efforts and have a single browser? Wait, that would be a monopoly and would probably be even worse.