I'd be curious to see this backed up. Certainly with a long enough timeline we are not at a maximum of "works only in x", and -- ignoring those beleaguered Opera users still subjected to crappy UA sniffing -- I can't think of the last time I came across a site that blocked me for whatever my choice of browser (I'm a Chrome and Firefox user as well).
If, on the other hand, you're talking about fancy new CSS3 or WebGL (or whatever) demos leaving out some browser due to neglecting to add a particular prefixed property (or whatever), I don't really see that as a problem. Prototype then standardize, right? Yes, not feature detecting and prefixing properly is poor web development practice and yes, they are cutting out part of their audience, but using an experimental feature inherently means that it may break at some point, and almost certainly isn't supported in all browsers.
When 3d CSS transforms land in Firefox soon, there are going to be a whole lot of demos out there that won't work. I would say that's an education and library problem, not a fragmentation one.
Google is doing deals and marketing web apps and add-ons as "Chrome". This is showing up all over the place, most recently in my experience on the Starbucks free wireless service agreement page.
Major content publishers Mozilla has talked to are surprised that we can host their Chrome-targeted web apps and HTML5-based extensions. They think such things are exclusive to Chrome. If they use Dart and need native performance, then that'll be true. There is a slippery slope, especially when more and more of the differentiation is not on a standards track (Dart, NaCl, WebSQL).
Nevertheless most of the current differentiation is bogus and any modern browser will do. There's certainly some "WebKit required" fragmentation. We saw this with Amazon's kindle web app, which is specifically built to WebSQL and not IndexedDB. But I do not believe any big player is pushing "WebKit required" as an agenda or marketing program. In contrast, Google is clearly pushing "Chrome" as a requirement or works-best-in brand.
The Chrome experiments, most recently
are obvious, maybe too obvious. Defenders can always play up the "experiment" hedge. That helps but only so much, especially when many of these experiments could work in other browsers with trivial changes.
I'm told that people have run chrome.angrybirds.com in Firefox. So it should be html5.angrybirds.com but -- no surprise from a marketing angle -- the domain name starts with C not H.
First, I'm a huge fan. :)
... and I was with you until the WebSQL vs IndexedDB thing.
IndexedDB is a horrible, horrible thing. It should be put out of its misery and replaced with WebSQL in Firefox.
Mozilla is singlehandedly holding back offline web apps with the insistance on a slow and hard to program -- yet buzzword friendly -- technology that no one actually wants to use. There's no reason what so ever to stick with a dumbed down K/V store when you're not trying to replicate data across data centers.
So, IMHO, you've bought this bit of "WebKit required" onto yourselves. WebSQL is the only production ready offline web app technology available today.
Take it from someone who offline enabled one of the biggest web apps on the web: I'd rather leave out offline entirely than code IndexedDB.
Considering that Apple will never support it, it's pretty much dead. And I feel that Mozilla is really on the losing end of this particular battle.
TL:DR; Please support WebSQL in Firefox. :)
I personally think there's definitely room for a SQL database API built into the browser, but Mozilla did have a point. It should be something a little bit better specified than that.
Also, it's not singlehanded -- IE refused to support Web SQL as well IIRC, and they aren't going away anytime soon.
it makes a lot of sense IMHO. it abstracts away dependency on exact SQLite version, but preserves a familiar SQL-like mental model. it is stable, mature, well understood and widely deployed/used (god i sound like a shill.. ;)
check out the two code samples, and a list of language extension (all feeling right at home in JS): http://en.wikipedia.org/wiki/Language_Integrated_Query#Langu...
if it wasn't proposed, can someone from WHATWG (like you Brendan ;) politely ask Microsoft to "contribute" any related intellectual property to W3C? how likely do you think would it be for AAPL/GOOG to accept it? (and if not, it could simply be implemented as a thin layer above WebSQL ;)
We could go awry on H.264 vs. VP8 too (I'm not religious), but note how Chrome has best of both worlds, including paying the gangster fee (MPEG-LA license). Not exactly "open".
The minor point for this discussion is that works-in-WebKit happens, but mostly unintentionally or out of rank laziness on content authors' parts. It may even (as you suggest and I agree) provide a big clue-stick to repair a standardization mistake or pox-on-both-houses-try-again situation.
Meanwhile, and this is the major point: works-best/only-in-Chrome looks like an intentional marketing game, backed by a nine-figure budget. Big difference there.
Howver, I am not sure it is fair to tar WebSQL with the same brush as these other technologies. WebSQL was on the standards track, and in fact started there. The main reason it isn't any more is that Mozilla representatives insisted on kicking it off the standards track instead of fleshing out the spec to be truly independently implementable.
The most common use of SQL you see is in iOS/Android-targeted Web apps, because WebSQL has been around there fore a few years while IndexedDB is new and isn't shipping in production quality anywhere.
Google is actually pretty sanguine about replacing WebSQL with IndexedDB.
Better examples of this trend would be:
SPDY as a replacement for HTTP, actually used in production by Chrome talking to Google servers, not a hint of it on any standards track.
VP8, where Google's single-source implementation is more authoritative than their spec, and no hint of it on any standards track. No apparent interest in putting it there.
(I realize Mozilla is on board with VP8 due to the patent licensing issues with MPEG, but consider the risk of giving Google total unilateral control of video codec design. I would have hoped that Mozilla insisted on taking VP8 through a real standards process before signing on wholeheartedly.)
In VP8's case, what alternative do we have that isn't OS-dependent? We can't afford the gangster fee.
The video codec situation is really quite sad. There is no technology option that is all of an open standard, RF licensed and sufficient quality. Vendors all have to make their choices out of the imperfect options we have.