Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Misdirection

You turn it into a smug "my browser is better so shut up".

But that doesn't matter either. Even ignoring other engines, prefixes have failed.

Prefixes have failed WebKit. WebKit can't remove them. WebKit can't be web-compatible without legacy cruft it created.

Would you have balls to remove prefixes and break web(kit) compat? No? So you see why other vendors are pissed.

You can have innovation and not shit on the web. Don't cling to a failed scheme that didn't even work for WebKit.

by klkll at
"The explicit goal of the prefixes system is to enable diversity of early opinion and fast coalescing around the best answer, thereby enabling the writing of a standard which is likely to need less revising and iteration."

I think you're spot-on. My only wish (as a webdev) is that "fast coalescing" would go faster :)

If webdevs are hurting other browsers by relying on non-standardized CSS. I think they are to blame, not the browser vendors who just want to quickly enhance and standardize a new feature.

Prefixed CSS features are like the tag for HTML. Both should not be used in ways which, if not supported, would make your website un-viewable. At least the new CSS features have the decency to explicitly tell me they are not standardized, by being prefixed. If they weren't, wouldn't it just make it harder for a webdev to create high-usability websites?

Of course, just like blink, if it is not getting standardized, it should be removed.

PS: "If you’ve read this far, congrats. You may be the only one." Thanks! ^^

"Prefixed CSS features are like the tag for HTML." Blink was removed when I posted. I meant "blink tag".
As you guessed, there were space restrictions—too long a piece would have lost readers—but also time restrictions, as we had only a couple of days to conduct the interview and then I had a day to edit it before passing it over to production.

Of course, even given two weeks and twice the length, I couldn’t have done all sides of the situation justice. You covered more ground than I could, and even at that left a lot out of a quite lengthy post!

(Also: coughmisspelledmynamecough.)

My primary goal was to get the discussion started, clear up some misconceptions (some of which I held at the interview’s outset), and allow Tantek room to make at least the basic case while injecting some of the most obvious objections. From there, it was and is up to the community to expand things further.

Personally, I love how far you’ve gone with it here! Though I disagree with a few of your points, the conclusions are all very well argued and that’s what we need now: articulate discussion. Thanks for putting your shoulder to the blogging wheel on this.

I loved every word that I just read. I agree that Mozilla even considering adopting (squatting) the -webkit- prefix is both crazy and indicative of a greater problem. The fact that experimental and non-standards features get shipped with webkit is the real problem. As a front-end dev, I love playing with all the very futuristic features that are included with the -webkit- prefix, but it's scary to me that they can be used in a production environment.

Also, I think that members of my industry are to blame just as much as everyone else. It's not hard to add the corresponding -ms- and -moz- prefixes to our CSS, but we choose not to based solely on efficiency (read: laziness). We have to be more forward thinking than that. Who would've imagined two years ago that the single biggest browser in the world would be Chrome and the most prevalent mobile OS would be Android? If we are unwilling to take the extra steps needed to make our sites both present and future-proof, we are the problem when we could be the solution.

Thank you so much four writing this down. It's being tweeted, Facebooked, and G+'d as we speak.

Maybe Google Teams could start a big campaign toward Web developers on how to code the right way. It seems from your post that you care about an healthy diverse Web environment. Promoting that ecosystem would do a lot of good.

I'm also curious to see when Chrome, Safari and Co. will not shiped the unprefixed properties.

My major difference of opinions with your post is that I think that vendor prefixes should be available only in beta builds and not in final release builds.

by karl at
klkll, I believe the entire point was thast prefixes *do* need to be removed as soon as possible once standardized. The issue being that standardization takes way too long.

And I'm having a hard time taking someone seriously when they just flat out state that "prefixes have failed webkit". Citation, proof and thorough explanation needed.

by Jerome Leclanche at
Hey Eric, I understand. Thanks for what y'all added. Typo fixed.
by alex at
That's a very good article but all of this is based on the assumption WebKit will at some point drop prefixes. And we all know it won't happen. That said, what do we do?
Nice use of kerfuffle ;)

I crave mixins so badly.


It's not an assumption, it's a thing I'm explicitly advocating for and believe I can make happen for Chrome. Not all of WebKit need move for us to use build flags to independently change the behavior of our port.


by alex at
Your post seems to suggest that the problem is prefixed properties proceeding too slowly to standardisation. In fact, the most problematic property, -webkit-text-size-adjust, has been implemented by Apple in Webkit but never specced or submitted for standardisation.

Apple's participation, or lack thereof, in the open web, is the real problem here. The prefix debate, and other browser vendors response, is simply a symptom of the underlying disease. Apple are the most wealthy company in the world, but they don't pay a single employee working full-time on web standardisation. Their participation in the mailing lists, speccing efforts, etc is small and decreasing. They add proprietary features that help them lock down market share on mobile.

What's needed is a radical change to the Webkit project itself, one that ties specific open web commitments into the project's governance and its licensing. The Webkit code license should explicitly preclude the addition of any proprietary features and require that any features which are added are fully specified and submitted to the appropriate standards bodies.

Google are the only contributor to Webkit who have a chance of pushing this through. If necessary, you should fork it to a new project, bringing all the other non-Apple contributors with you. Otherwise, you are letting Apple free-ride on your contributions, which they can upstream to their iOS fork alongside their proprietary extensions.

by Jon Rimmer at
Idea: Chrome for Android (only) should change from using -webkit-* to using -goog-*.

This action would cause lots of articles to be written in the press about vendor prefixes, and web developers would have a great opportunity to add them in for everyone, where appropriate.

If you hate the idea, then I've got a long blog post to send to you on the subject :)

Also advocating to the CSS WG may be beyond your power, as noted, however advocating to the Chrome for Android team should not.

I'm not sure if I'm serious or not about the idea, or if I just want to hear you argue against it.

Hey Joe,

I think this is a special form of the "Chrome should sunset prefix versions of standardized properties" point I've argued, and I can only say it makes sense to me along the same lines. That said, it's unclear what other WebKit ports should do/evangelize. There's pretty clearly diminishing returns, highly correlated to distribution (as always).

by alex at
I think you're clearly correct that CSS development is moving far slower than it should, and slower than other parts of the web platform. I also think that prefixes have done nothing to help here.

Consider the part of the web platform that has made huge progress in the last five or so years: HTML. Every single high-profile feature addition in HTML (like canvas, video, audio) was unprefixed from the start. If browsers ever prefixed any of the JS APIs, it was without any request by the spec or its editor, and only until they felt they were stable enough to unprefix -- not until some arbitrary spec stability milestone. Canvas was actually a WebKit proprietary feature that was always unprefixed in WebKit, but was reverse-engineered and standardized in something close to its original unprefixed form. This by itself proves that prefixes are not necessary to iterate a successful feature. You can just stick with the original implementation, flaws and all, making only slight changes so that compat is basically preserved.

The difference is in the editorial process. HTML development has been overseen solely by Hixie since 2004 or so (although the W3C only admitted it in 2007). If there's any dispute, he resolves it by fiat. Once something is implemented, he makes sure the spec stays stable so that implementers don't have to change, unless the flaws turn out to be so bad that implementers are willing to change.

CSS development is balkanized and bureaucratic by contrast. Development is in the form of dozens of tiny specs edited by different people, many of whom have little time to spend on standards and are unable to keep up with feedback. They don't coordinate as much as they should, so we wind up with effort being wasted on multiple solutions to the same problem. Disputes sometimes occur in lengthy mailing-list discussions with no clear resolution.

CSS issues can be left open for many months with no resolution -- not because no one's looked at the issue, but because no one is willing or able to make a final decision. For instance, has been open since October 2011 with no resolution (it's marked a duplicate of a still-open bug). This despite the fact that browsers that implement transforms all do the same thing.

The recurring debate about prefixes, with similar arguments being presented every few months for years, is another example of the same problem. Resources are being wasted on permanent discussions like this that are constantly being reopened, because there's no finality. There's too much effort spent on trying to reach consensus on individual minor issues and not nearly enough effort spent on just making a decision and stabilizing things.

Prefixes are bad because they fuel this propensity toward indecision. Yes, maybe the initial draft will be flawed. Too bad. The web platform is flawed. Take your best shot at the initial draft, respond rapidly to early feedback while you can still iterate, and set it in stone once there's widespread implementation. The first priority needs to be to get the functionality out there, stable and interoperable.

Authors can work around flaws -- heaven knows they're used to it. If all browsers implement the same flaws, they can deal with it. What's a much greater pain to deal with is if the design keeps iterating and they don't get interoperable support for any version of the feature at all for an extra couple of years.

What the CSSWG needs is one person, or a few like-minded people who cooperate closely, who can invest the time necessary to take over CSS development by themselves. HTML and DOM specification is in a drastically better place than CSS because it's largely run by Hixie together with a small handful of people who are on the same page as he is. Things get done with no bickering, and more pragmatism than perfectionism. Unfortunately, there's no one who has the time and ability to take over CSS right now. And if there were, it would be politically tricky, because all the implementers are heavily involved in the CSSWG (unlike the late and unlamented XHTMLWG). But that's what needs to happen. Prefixes are a distraction.

(I say all this as someone who was paid by Google to work on HTML/DOM-related specifications and tests for 2011, and am now working on CSS specifications and tests for Mozilla. The difference is striking.)

> I think this is a special form of the “Chrome should sunset > prefix versions of standardized properties” point I’ve > argued, and I can only say it makes sense to me along the same > lines. That said, it’s unclear what other WebKit ports should > do/evangelize. There’s pretty clearly diminishing returns, > highly correlated to distribution (as always).

I'm talking about doing it for all prefixed properties, standardized or otherwise, and not sunset - sudden. s/-webkit-/-goog-/g

Your chance to do this is short-lived. Doing it in a years time will take sites that worked for a user and break them. I can see you not wanting to do that.

My assumption is that Chrome for Android currently has a number of users which is basically a rounding error, but in 2 years time it will have a massive % of users. Other webkit ports don't have the same low initial cost to prefix-change and high future leverage. Both are key to this thought experiment.

If doing this was going to save vendor prefixes from otherwise certain demise, would you do it?


I think you're missing a key point about how CSS and HTML differ: you can't (practically) prefix HTML elements in the same way you can CSS. To prefix thing, you'd be adding nesting which might influence styling and will certainly cause incompatibilities down the road. CSS is different in that you have "last wins" combined with graceful failure, where HTML will retain the effects of vestigial but un-recognized elements.

Perhaps this has some of the follow-on effects you cite, but it's clearly no apples/apples.


by alex at
by Kevin at
The most thorough, well-argued article on the subject yet.

"prefix squatters" - he he

What astonishes me most about this debate is how little the fact gets mentioned that Apple is using the prefix mechanism essentially as an escape hatch from the WG. Prefixes exist to make room for experimentation in proposed future standard properties, not to allow vendor-specific proprietary features. But that is exactly what Apple is using them for – an escape hatch from the W3 process for features they at least evidently they never intend to standardize.

In that position, it is hard to see how Mozilla can avoid implementing these properties with their -webkit- prefix. Of course that’s crazy, because it breaks the purpose of the prefix system in exactly the way you described. Mozilla is damned if they do and damned if they don’t.

The real problem is Apple obstructionism, and apparently it is also the elephant in the room.

As for Lea’s and PPK’s approaches to prefixes, those are the same damned-if-they-do-and-damned-if-they-don’t kind of reaction to the problem from the webdev perspective: dealing with lots of prefixes is a huge pain for webdevs. But the reason they have to is because the -webkit- prefix has become something other than what the prefixes in CSS were supposed to be.

And Apple is the culprit.

Apple are now what Microsoft used to be – even if maybe with less calculated intent. Is that enough to divert everybody from jumping on their case to get in line? Why are people going for these absolutely crazy coping approaches that fail to recognize the core problem – why attack the prefix system instead of indicting its (ab)use as a ruse for vendor fragmentation of the web platform?

It’s just baffling.

Argh. Too much editing.
alex, you can do it just fine if you use attributes instead of elements. E.g., you could have or such. The way to be compatible across all UAs would then be

(hope that doesn't get eaten). Sure, it's ugly, but workable. It's been suggested. I think the HTML spec at one point had language encouraging implementers to introduce attributes, not elements, as extension points if they wanted to extend anything.

Besides, it illustrates the point that no prefixing mechanism is necessary at all. Whether or not prefixing was possible, it didn't happen, and it was still a success. Thus prefixes are not necessary for successful experimentation by vendors.

Aristotle: All engines have totally non-standardized prefixed properties. Gecko is no exception. There's a whole list of them here:

Since both sides of this debate make claims to “what developers think/act”, we thought we’d lay out the Sencha opinion on -webkit prefixed effects: why we use them, and why we don’t want other vendors squatting on them. And incidentally, we're fans of CSS as a technology.

But first a little background.

Here at Sencha, our frameworks haven’t focused on progressive enhancement: in our opinion, it’s not very appropriate for apps. A grid that degrades to a poorly laid out table is not generally useful, not for developers, not for users. Our community’s users expect their web apps to look and behave exactly the same, whether they’re in IE6 or Chrome 17. This has not been easy to achieve. It’s not just a matter of adjusting to the well known problems such as IE6’s broken box model, but also working around a multitude of other browser quirks (such as the extensive bugs in IE’s VML implementation for our web charting.) Suffice to say, as a cross-platform framework company, we put a lot of time behind abstracting browser inconsistencies.

When it came to developing Sencha Touch in late 2009, we took a slightly different tack. Our primary goal was to create a web framework that could provide a native-quality application experience.

Quite quickly, we figured two things out. First, most smartphone hardware on the market simply didn’t have the power to run high quality experiences in their browser. Second, many mobile browsers (Blackberry OS 5, Windows Mobile 6 CE etc.) lacked the JavaScript engine or the CSS support that we needed to create compelling user experiences. With these two constraints, we decided that our initial version of Sencha Touch 1 would target just the built-in browsers for both Android and iOS. Luckily, at the time, those two browsers were responsible for the vast majority (90%+) of all mobile web traffic in the U.S. (as measured by ad requests Our interpretation was that other platforms were delivering such a bad experience that few people were using them for regular web browsing.

The biggest benefit of targeting just these two browsers was that we could take full advantage of the huge set of -webkit visual effects - which were then mostly available only on webkit based browsers. Gradients, transforms, transitions, border-radius, and CSS masks were indispensable in creating the richest experience possible. Even though they were technically experimental, most of them had standards track documents that meant that we could rely on some form of the capability being a standard at some stage for other browsers, if and when they arrived on volume mobile platforms.

Using WebKit effects reduced the size of our download package (far fewer images), allowed for easily themed applications, and drastically increased the performance and smoothness of our animations. In particular, CSS 3D transforms were hardware accelerated on iOS, which delivered noticeably better frames per second when compared to JavaScript-based animations. Without WebKit effects, we simply wouldn’t have been able to deliver the quality of product that we needed.

Subsequent to our release of Touch 1.0, there have been a bunch of new mobile browsers from RIM, Mozilla, Opera and Microsoft. We’ve added support for RIM and announced our intention to add support for Windows Phone. As a leading implementor of “WebKit” only mobile frameworks, we’re often asked when we’ll add support for these browsers. Here’s how we think about this.

For us, “supporting a browser” is not just a matter of adding multiple vendor prefixes or doing feature detection. Every single browser we support - even the supposedly generic WebKit ones -- have had major differences in the correctness and performance of features, which makes the “use feature detection” approach advocated by many fairly useless. We have browser specific code for Android 2.2, 2.3, and 4. We have code just for the Kindle Fire and code just for the Blackberry Torch. Our list scroller implementation for Android Gingerbread is based on scroll position animation and our list scroller for Android 4 is based on CSS transforms. This attention to detail, and our browser-specific code, is needed to create the most compelling experience possible. It’s why people use frameworks rather than try to code to the naked browser.

In addition, we’re a developer’s developer, so we care about supporting the browsers that our developers care about developing to. Today, that means Android, iOS and Blackberry. Soon it will be Windows phone. This means that a lot of -ms is going to start showing up in our CSS files, and it also means that we’ll be replacing webkit-specific effects that do not look like they are headed to standards track. The two major effects that are only are truly useful but have no standards track document yet are background-clip: text and CSS masks. (There is an aspiration to move these effects in to a general FX spec at some point in the future, but we would have much preferred that Apple or Google submit standards track documents for these much, much sooner.) These are now supported in both Firefox after a fashion as well as Webkit. These effects are useful for theming icons and other small graphics that can be delivered as custom fonts. For Windows Phones, we’re looking at the prospect of using image based theming, fonts or SVG masks. But we hope IE implements CSS masks soon too.

On the other hand, we see only minor demand from our developers that Sencha Touch work on Firefox Mobile or Opera Mobile because each of these has much lower levels of usage on smartphones. But this isn’t the only reason that we don’t support them, it’s because in our opinion, the quality of the implementation of the effects that we need to use is often much poorer in these browsers (although we’d also cast stones - big ones - at the Android 3 browser). If Mozilla decides it’s going to expropriate -webkit prefixes and masquerade as an iOS browser, we can see a requirement for us to figure out a different way to detect that it’s Firefox and disable those effects.

At a higher level, we agree that it’s very odd behavior for Mozilla to cry wolf about a webkit-only monoculture when their implementations of the effects that we and other developers are most excited by have been dilatory and underwhelming. And, we’re not worried about a WebKit-only monoculture, it’s clear that IE10 has a pretty good shot at overturning WebKit as the best browser on Windows. At the very worst we’re looking at a duo-culture.

So afterall that context, here’s what we’d like to see.

First, no prefix squatting. It’s a terrible idea and will make developers go through contortions to route around it. Daniel Glazou’s proposal that it’s ok to squat only in the smallest possible way, may not be a terrible stop gap, but we’d still prefer “no squatting period”

Second, a much stronger effort from the browser makers to move experimental effects into standards track. At most, there should be a 6 month delay between first ship and an Editor’s draft at the very least. Even now there are a ton of effects that remain outside standards track. Just two more examples, Webkit text decoration effects should be integrated into CSS Text. And CSS Masks - which arrived in Webkit in April 2008!! - should have long since been put into a track document.

Third, more aggressive pruning of non-viable standards track features or even whole standards track documents. For the longest time, the CSS Text spec was a peculiar species of speculative fiction. I can point to other living dead spec documents. It’s not very helpful when we have to read transcripts of meetings and long discussion threads just to figure out what we can count on and what we can’t. And waiting for something to hit Candidate Recommendation status is not realistic.

Fourth, more aggressive pruning of experimental features that have been rejected as ‘a bad idea’ by the CSS Working Group. There needs to be a “negative standards doc” listing things that “ain’t going to happen”. It’s been very clarifying for us for WebSQL to be declared a dead end (although we personally liked its functionality quite a bit.) Once a feature hits the negative standards track, browser makers should have 6 months to remove it from their edge versions.

In any case, this is the take on the prefix kerfuffle from the perspective of a mobile framework developer. Enjoy.

Michael: Thanks so much for the insight. Updated the post to draw attention to your incredibly valuable addition to the discussion.
by alex at
"To hear Tantek et. al. tell it, non-WebKit-based browsers would be prevalent on mobile if only it weren’t for those damned browser prefixes causing users of other browsers to receive different experiences!"

Of course Tantek claims no such thing.

"Speaking of IE…I respect those guys a lot, but the logical leap they’re asking us to swallow is that the reason people return Windows Mobile phones is that some CSS doesn’t work."

Of course Microsoft says no such thing.

"Appeals to a lack of manpower to implement must never block others and shouldn’t block standardization, so please stop making them."

No-one is making them, as far as I know. (Although Apple is making a lack-of-manpower argument for why they haven't standardized their new -webkit features.)

Please try to abstain from straw-man attacks.

Your point that Webkit-prefix-dependent mobile sites are not the biggest problem faced by non-Webkit mobile browsers is both immediately obvious and not relevant.

Your plea to give evangelism a chance ignores Opera's efforts in this area, which have been going on for years, supported by a significant staff.

You may be unaware that Apple's Webkit people have declared that they will never drop support for -webkix-prefixes. I applaud your efforts to make that happen in Chrome; that would be excellent.

by Robert O'Callahan at

You know I respect you greatly, but I'm simply laying out the implied arguments in the (disconnected) appeals that the various parties are making. If the claim of the squatters isn't that webkit prefixes are making it difficult to prevent attrition, what is it? I haven't hear that clearly enunciated. Or is the goal of preventing attrition -- from the perspective of a product -- something other than keeping users to the exclusion of other browsers which they might pick? What bit did I get wrong?

As for manpower, certain CSS WG representatives make these appeals on a regular basis.

And on the point of evangelism, I'm not claiming that web developers will do anything other than what they see is in their own interests. Evangelism has the ability to accelerate that; i.e. if a browser is becoming more popular, evangelism can have an impact on developer behavior. It has for us on Chrome for the desktop and I know full well that it did for FF too. I'm not making the (unsupportable) claim that evangelism alone can solve things.

As for what Apple's WebKit people have said, that's the entire reason why I'm trying to distinguish products from engines. I know that Gecko doesn't really have this split, but Safari and Chrome already ship with different flags. That means that non-Safari ports can absolutely go their own way and add diversity to the ecosystem. Please don't claim that what Apple says about Safari must necessarily affect other WebKit-based browsers. It just ain't so.

To summarize: you are calling my arguments straw men on the basis of misinformation and mischaracterization. At least you're not alone in that. There is evidently some fault to me for not writing more clearly.

by alex at
i wanted to write a long post, but @Michael Mullany just nailed it. Completely agree with every word there.

>> If Mozilla decides it’s going to expropriate -webkit prefixes and masquerade as an iOS browser, we can see a requirement for us to figure out a different way to detect that it’s Firefox and disable those effects.

+1. Firefox looses customers because it (was) not innovating fast enough, and many "supported" under moz prefix features were extremely buggy (and transitions still are, for example).

by c69 at
To be clear, Mozilla isn't frustrated because they aren't receiving some sites cool 3d-css transition effect in mobile firefox. I'm more frustrated that we receive win-mo sites from 2000 instead (i.e. they are neutering the already neutered mobile sites). We're only just now turning on hardware accelerated layers/transforms on mobile, because... well frankly its been a lot of work to get them running correctly on the slew of different android hardware/software combos out there. Same reasons Chrome has opted to not even try to run there. We're close to having nice fast transitions and webgl (canvas is a different beast as well) on at least some subset of phones.

I'm frustrated to see prominent webdevs advocating UA sniffing as a method of doing feature detection though. Once hw accelerated layers are on in FF mobile, there will likely still be hardware white/blacklists. Turning off the feature because the UA contains "firefox" will likely leave out users on newer, higher end phones where performance would be great. i.e. UA sniffing as a method of disabling effects is not generally a good idea. Feature detection (and feature performance detection if we need it) are better and more surefire ways to fix things and won't require you to go through by hand and update them with each release.

More importantly, completely ignoring Gecko or Webkit or anything else out right now, it will help ensure that when Engine X comes out, built by Joe-Schmo in his basement, and it performs 10,000,000 times better than anything else on the market, it actually has a chance to compete as well without first having to advocate to 10,000 sites so they recognize his engine, or (more likely) resort to spoofing someone else's UA as well as spoofing their proprietary css.

by DigDug2k at
Hi DigDug2k (which I have to assume isn't your actual name, leaving me unsure of your affiliations):

First, some data: we accelerate layers just fine on Chrome for Android. Yes, it was a lot of work, yes it required huge effort. But it performs well; as does fast scrolling. What FF does in these cases is a question of investment for the Mozilla organization to speak to.

But to your main point: Brendan explicitly called out visual glitches as a serious issue in his comments on my plus post:

To suggest that Mozilla isn't interested in fixing these visual issues as an issue related to market penetration requires an extraordinary step away from the plain meaning of these statements (and Tantek's in the referenced interview). Perhaps there are additive motives too, but they have not dominated the discussion so far.

As for the idea of someone creating a new system; I think you're vastly under-estimating the number of people and amount of time it takes to create a successful web renderer. I didn't say "good", I said "successful". As I try to point out in the post, product and platform are different. A big-bang event may happen for some new code-based, but nobody sneaks up on the web and converts billions of users overnight to new browsers. It just doesn't happen.

by alex at
alex: Just because it is difficult don't mean it should be made worse. In fact, one of the goals of HTML5 is to reduce amount of the reverse engineering needed for it.
I would encourage not scoffing at the idea of people making browsers in their basements. Have you forgotten where webkit came from?
by dbt at
dbt: I didn't scoff at it. I work on a browser derived from KHTML...and yes, I remember KHTML (and its codebase) back in the days when it was a tiny little bit of the KDE project...the plucky little engine that could. I remember being excited by the work that George and Co. were doing and eagerly trying out the 2.x Konqueror era browsers. Back in '00-03 I kept checkouts of KTHML around so I could support it with my DHTML projects and so I could dig in and understand what worked (and didn't) and why. It was the engine I loved but which nobody used.

Lets play the intervening time forward: to get to where it is today took something on the order of a hudred million dollars in aggregate direct investment (probably more), integration with dozens of OSes and embeddings, and more man-hours of some of the smartest browser engineers in the world than I care to consider.

You can trace a similar history for Mosaic (the codebase that turned into MSHTML). Far from scoffing, I'm suggesting that there's a huge difference between development and success as measured by distribution. Part of that process is the work of compatibility engineering (a key part of the difference between today's WebKit and the KHTML of yore).

To imagine that there's some other path to broad distribution is to go all-in on the "build it and they will come" fallacy that is so common in Open Source (and I've spent nearly my entire career -- such as it is -- in Open Source). They might come, but probably not. Our mental models of the world need to accommodate how un and under-informed users acquire technology too.


by alex at