Comments for Misdirection
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! ^^
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.
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.
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.
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.
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.
Regards
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.
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.
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).
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'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.
Regards
"prefix squatters" - he he
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.
(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: https://developer.mozilla.org/en/CSS/CSS_Reference/Mozilla_Extensions#Proprietary_Mozilla-prefixed_properties_(do_not_use_on_Web_sites)
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 http://www.slideshare.net/admobmobile/ad-mob-mobilemetricsapr10). 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.
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.
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.
>> 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).
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.
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: https://plus.google.com/113757927151929258451/posts/Q6vgGzmtNEG
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.
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.
Regards
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.