It’s happening again. Once upon a time, browser vendors started adding their own features without consulting with each other and agreeing upon standards. What they created was a giant mess of inconsistencies across browsers and platforms that is still in effect today. Ask any web developer and they can tell you of the pains that they have suffered trying to make seemingly trivial things work everywhere consistently. It’s no easy task. Before IE 7, even an ajax required something along the lines of:
That’s right, IE 6 didn’t support the native xmlHttpRequest object (more here). This is just one of many examples in JavaScript and CSS. document.all anyone?
The end result of this problem became to be known as the “Web Standards” movement. Simply put it’s an idea that code should follow a standard that results in consistent output across all browsers on various platforms. Write once, run anywhere. While it’s taken years for this to manifest, it’s slowly become a reality. Firefox, Safari, Opera have fairly consistent rendering (at least in comparison to the mess of just a few years ago on the browser scene. IE 6 was fairly poor in terms of modern web development, but IE 7 made progress, and IE 8 is Microsoft’s greatest effort to date to bring their browser up to speed.
Unfortunately, all that “progress” is really catch up and making specs from several years ago work across browsers as the biggest area of problems (CSS 2) become a recommendation in 1998. 10 years and a few days ago. Web sites, and developers want to do new things.
As a result groups like WHATWG and HTML 5 formed with the intent to provide modern features such as 2D drawing (canvas), media playback, drag and drop, offline mode, and storage. All things desperately desired by web developers. Some of this stuff to date has been supplemented by the use of plugins such as Flash which can provide some of this functionality, in particular video. It should be noted the development of standards is a historically slow process since it’s essentially a bunch of geeks arguing until their keyboards wear out. This process takes a long time.
To speed things up, some once again bypassed standards and instead decided to implement things on their own:
- Apple implemented Canvas, which has some notable concerns regarding intellectual property, though can still be standardized (and is still in the HTML5 specs as I’m typing this).
- Google released Gears which originally provided offline support for web browsers, but has since expanded to allow for better desktop integration and running javascript in the background on browsers it supports.
- Yahoo just announced BrowserPlus, which is an API “that allows developers to create rich web applications with desktop capabilities” (that’s verbatim from their page).
- Mozilla added to Firefox 3 Online/Offline events, Web-based protocol handling, which are both part of the WHATWG Web Application 1.0 specs. In addition, APNG and text extensions to Canvas were added, though it’s noted that they are experimental and essentially Firefox only for now.
There are dozens of other little things in various browsers that are specific to them, but I won’t even go into that. These are just the more high profile things at this time.
Does anyone else see the problem here? At the rate things are progressing, it’s going to be pretty tough to build a competitive and user-friendly web application without requiring at least one framework being installed on the client side. This means before a user can enjoy a good web experience they will need to install:
- Standards Compliant Web Browser (may come with OS)
- Latest version of Adobe Flash (essentially the video standard right now)
- BrowserPlus (for some sites)
- Google Gears (for some sites)
This really is starting to feel like another browser-bubble, this one being more of a “browser feature bubble”. People rapidly trying to add features to meet application needs without standardizing. This time instead of building it all into the browser, they are also providing plugins to add the functionality. This is marginally better at best. While it allows for support on multiple browsers/platforms it restricts innovation since not all browsers/platforms are supported.
Google Gears still doesn’t support the iPhone, despite it running in Safari due to Apple’s restrictions on 3rd party software. It also doesn’t run on all portable Linux devices, or Blackberry’s. Not to mention Opera or Camino. It works on other Mozilla browsers that support extensions provided you tell your users to follow these instructions (you can essentially call that “unsupported”).
Yahoo’s BrowserPlus is no darling either. As of yet, it only supports Intel Mac’s running 10.4 or later (sorry PPC millions), and only Windows / Mac running Firefox 2+ or IE 7+. That leaves out millions of IE 6, Safari, and Opera users. Plus all of the mobile users (who are growing in number). Yahoo promises that will improve, but we’ve got to wait for Yahoo engineers to get around to that. If Yahoo is acquired by someone, who knows what that companies priorities will be for this project.
Apple implemented Canvas in Safari, Mozilla implemented it in Firefox. But it’s adoption has been slow from a developer’s point of view since IE doesn’t support it. There are several libraries (including one by Google) that attempt to add support, but they are pretty slow and don’t provide the same experience to IE users (in particular older IE 6 users). APNG is supported in Firefox 3 and Opera 9.5, both not released just yet. APNG degrades nicely, but if your using an animation, you want an animation for all users, not just Firefox and Opera users.
Yes, adoption can grow for canvas, Yahoo and Google can support more platforms and browsers, but that doesn’t fix the root problems here:
- The entire web is waiting on a company to update their enhancements to support a platform/browser. Open sourcing the code doesn’t really fix the problem since distribution is still problematic. Also just increases the chances of forking which makes it even more painful. Installing a browser in bits and pieces sucks. Users shouldn’t be subjected to that.
- There are multiple API’s to essentially do the same thing (drag & drop, offline support, video, etc.).
Does anyone else see this new form of fragmenting to be problematic?
While I agree the features each vendor is adding in are desired, I don’t think this is the right way to do it. One of a few things will happen here:
- After a period of time, one or more of these API’s will become deprecated as one becomes dominant. That’s a major pain for developers who choose the “wrong” one, and an expense for companies who are in that situation. Nobody wants to be in this situation.
- Things will continue to fragment and we’ll be back to the “Designed For Netscape” era, but it will be “Designed for Firefox 3+, Google Gears, Flash 9.0 r124, whatever”. I get a chill just thinking about it.
- Horrifically complicated code that essentially supports multiple products by using a subset of their functionality. This might be the “best” and it still sucks on a massive scale since it increases costs for development and decreases fun. You could use a JS library to abstract functionality to a more platform neutral API, but more libraries add overhead you may not want. Not to mention more code your relying on someone else for.
None of these are a good outcome.
I’m not saying that the standards route is perfect. There’s no binding requirement for anyone to adopt anything, or even accomplish a final spec. There are many half implemented specs, and many that never go anywhere. Perhaps that’s part of the problem. Perhaps it’s that standardization has historically been a closed process, though it’s slowly opening up (thanks WHATWG). Participation is also pretty touch as not many can manage to read all that email.
Browser vendors are not without their faults either. They are historically a slow to fully adopt specs, and generally don’t collaborate on where they will start their implementation. Partial support is as good as no support unless a it’s adopted uniformly across all popular browsers. Perhaps that’s a place that browser vendors can best help developers. By simply agreeing to implement XY.
That said, one could create a plugin that implements a standard. It’s already be done. Adobe released an SVG plugin (prior to the whole Macromedia deal as I’m not sure what the status is considering the Flash business is a closed source competitor), there’s also an XForms plugin for Mozilla browsers.
I really hope some caution is used before we have a browser feature bubble. This is just going to become a mess of technologies that nobody can keep up with. A lot of progress has been made in the past few years to fix mistakes of the past. Is this process of add-ons really the right method of giving web developers what they want?
To be fair, Google’s Aaron Boodman recently blogged regarding Google Gears and standards. And does indicate the desire to become become compatible with HTML5:
Currently, the Gears Database and LocalServer modules are not fully compatible with the HTML5 proposals for the same functionality. This is only because those specs were written after Gears was released, and not because of any desire to be different. In fact, we were involved in the design of both HTML5 specs, and we are currently implementing the proposal for database access.
This is good, but it’s still a moving target on a moving target as Google Gears is in beta and still being changed to match specs which are still evolving.
To avoid any misconceptions, I do think these features are a good thing. I like canvas, offline support, drag & drop integration, and want to implement them myself as well. But I don’t think the process to add them has been successful thus far. I think it’s just asking for trouble later on and will take a long time to repair. This isn’t about Firefox extensions, or javascript libraries like jQuery, YUI or Prototype. I love them and use them every day. This is about having non standard ways to do things that clearly need to be standardized (and are in the process of being standardized), and encouraging other developers to implement a method that’s tied to a particular piece of software.
Who is at fault here? Pretty much everyone. Standards bodies are to slow for a fast moving industry for starters. Secondly browser vendors fail to coordinate their progress on spec implementations. While nobody expects CSS 3 to be implemented overnight, of vendors would agree on milestones in which certain features would be implemented, that would greatly help implementation for web developers. Lastly plugin developers need to ensure what they are offering is widely available, free of any licensing problems that would impede implementation in other products, and are on a parallel track for standardization.
The web wouldn’t have succeeded if you needed to install a plugin for a <a href=""/>, or <img/>.
15 replies on “Rebreaking The Web”
Using the same technique to supply a different graphic design, you could also provide a more accessible design for your site. For example, larger fonts and high-contrast colors may help low-vision users.
Is the situation today any different to any point in the browser history? I don’t think so.
Open Source and standards are so ******* slow, no wonder other companies just get on and write something. It’s either wite something now that solves a problem and make some money, or wait 5 – 10 years for it to become a standard part of the browser.
I personally think standards are the right thing to do. But I wish there was one smart guy writing them, not 20 ****-wits (10 of who are bought by Microsoft Apple)….
monk.e.boy
you **** out swear words?! How old are you? Like 5? Pathetic.
Some of these problems can (or could until now) be solved by providing libraries for “old” or “broken” browsers to bring them inline with whatever the current spec happens to be. But this will be hard — if not impossible — to do if Javascript gets locked down (as is happening with ES4). In that case, you’ll have to cook up a proprietary-looking library or nothing.
If browsers had the right “backend” technologies (and canvas/svg/video/audio plus xbl and completely mutable js almost gives you the lot), you don’t need a plugin, you just need another library. Actually, the main thing missing on the Firefox side is that you can’t hook your own attributes/data into CSS (surprisingly, IE works really well in this regard).
I guess my overall point is that if browser creators give web developers the right tools, we will solve almost all these problems ourselves.
W3C proofed that waiting too long forces vendors to do their own thing. Otherwise we wouldn’t have WhatWG. So, to be ready for all the new technologies, each web developer needs a wrapper for specific functionality. For example, I use dojox.gfx for drawing which works fine and I don’t need to care about the browser backend. The same goes for lower level parts like events with YUI.
The only drawback is that if you aren’t experienced enough, you need to load a lot of libs for even trivial tasks.
@voracity: Good point. Not everything can be implemented given a particular browser, but many things can. Sometimes it’s not a technical limitation but a legal one (such as Google Gears on the iPhone).
@monk.e.boy: Unfortunately I feel the need to, because people like you can’t be civil.
To say that IE6 didn’t support native XMLHttpRequest is misleading. As the article you linked to points out, IE6 implemented it first, and the other browsers copied the idea.
I’m not so sure that the last browser-divergence sheds any light on the current situation. For one, the browser vendors and plug-in providers seem to be talking.
And the concept of progressive enhancement will mitigate some of the possible fragmentation:
– canvas is almost the perfect test-case. Surely no-one designs a web-page that can live without canvas.
– Gears vs BrowserPlus vs mozilla-extras. I think there will be libraries to abstract the common features, and proghancement for the rest
I also think google (search) will be a stabilizing influence here. If you want people to find you with google then you have to present your data in such a way that google can find it.
Anyway, predictions are tricky, especially about the future (so feel free to tear apart my wishful thinking).
@Sean: xmlHttpRequest was originally implemented as an ActiveX object. Because ActiveX is proprietary (and pretty much impossible on anything but Windows), the statement is correct. They didn’t implement native xmlHttpRequest until IE 7. They implemented the idea first… but in a form nobody could mimic, which proves my point that browsers were fragmenting in terms of compatibility.
the problem is that all you highfalutin W3C and WHATWG types spend forever arsing about and eventually trying to dictate what the web will be. Meanwhile the world moves on and adopts **** like Flash.
You all rabbit on about how browsers need offline storage and desktop integration when fundamental elements of the most trivial web-only based applications are not natively supported. See rich text editing. All the blogs of this world and all the CMSes have the most clunky, diffficult to implement text editing environments, it’s pathetic! Midas, contentEditable, babble on however much you like. The web needs fundamentals before it pretends to be a medium that can support genuine desktop-comparable applications.
Meanwhile Flash just continues to plough it’s security and performance compromising way forward.
*sigh*
A simple way to fight off Flash is to give standards-supporting developers some decent visual tools. Where are rounded corners in the priority list? Where are multi-position background images?
The web is farked, I’ve had enough.
[…] Accettura/Planet Mozilla: Rebreaking The Web. Web Standards was supposed to put an end to the hodgepodge of features added by different web […]
Minor correction: Gears will not break backwards compatibility with it’s initial Database API when we add standards support; we’ll have both.
Unfortunately, standards bodies are seldom inclined to add groundbreaking new technology until multiple vendors have implemented and proven it. It’s a chicken and egg problem that we’re trying to correct in HTML5 and WhatWG.
At the end of the day, the most important thing is interop not “standards”. To that end, Gears is working with Mozilla and WebKit more closely to attempt to come out of the gate with roughly compatible features. It’s just not practical, however, to expect this to be perfect overnight. There will be a period of divergence and a period of convergence. As long as everyone involved is committed to the convergence (and I get the strong impression this is true this time around), this should happen much faster than it has in the past.
@Aaron Boodman: Thanks for chiming in. I didn’t mean to infer anything about breaking backwards compatibility. The primary issue I have is the cost of these premature implementations. Moving targets suck. Agreed that “interop” is likely more important than “standards”, though I don’t think you can successfully do so without having standards (my definition of a “standard” being merely an agreed upon set of specifications). This of course raises the question: Is the standardization process the real problem? And how can it be fixed?
Personally I think W3C needs to put some more emphasis on specs including levels of implementation, and milestones that parties agree to meet. Publishing a spec. and hoping someone implements it is pointless and a waste of time. Each vendor implementing random pieces at their own leisure helps nobody as the features are useless until it’s available to all browsers (or plugins implementing functionality). In this respect, Google’s approach is good since it succeeds. The failure I see is to have all this legacy code that won’t work on non-Google Gears enabled browsers because it’s not up to spec. Bloating the spec is out of the question too.
I guess I’m more of fan of incremental efforts rather than giant monolithic specs.
There’s no easy fix or it would have been done years ago. But I question if the seemingly diverging efforts are the best method. In particular because we have to live with anything that doesn’t converge at the end.
Maybe I’m not “cool” enough for the Web 2.0 nonsense, but honestly, is canvas a necessity for a regular website? Is there anything actually useful for the end user that can be accomplished with these fancy new features? I mean, yes, offline storage would be great to have, but I don’t think it is a crucial that we can’t wait for all major vendors to support it. The rest is just fluff in my opinion.
I’m not against the advancement of standards, and I agree with you that it would be great that vendors agree on a common set of new standard features for their future releases. But these standards you mention are not particularly relevant for 99% of websites out there. HTML Javascript CSS is enough to make something good, even some really great stuff.
The standards I think are really important for the future are the audio and video tags. Those are really important, and they deserve special attention IMO.
“Publishing a spec. and hoping someone implements it is pointless and a waste of time” is a sentiment that Ian Hickson (HTML5 spec editor) generally agrees with, and part of the HTML5 process has been to try and have as much dialog as possible with Mozilla, Apple, Opera etc. in order to have the standard reflect what people actually wish to/can implement (cough, SVG, cough).
I view Gears as a way of rapid-prototyping features that can then be specced in HTML5, providing an open-source implementation of those features for browser developers to use, and bringing HTML5 features that are native in some browsers to other browsers that lack them (e.g. we could use Gears to add to IE if desired). In this sense it seems like a useful complement to the standards process. I don’t know much about BrowserPlus; hopefully the Yahoo! folks will be similarly interested in moving as many browsers forward as possible.
[…] Sun 07-12-2008 Multi-Platform/Cross-Browser Transparent PNGs Saved by dizid on Sat 06-12-2008 Rebreaking The Web Saved by amott1973 on Mon 17-11-2008 Is your teen just too stressed? Saved by nikitabono on Thu […]