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.