As an outsider looking in, it seems like the whole prefix thing is approaching the problem from the wrong direction.
Why do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable.
Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others.
1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2...
2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.
If only it were this simple. The problem is that not only are these implementations not formalized, but also there is often dispute over how they should be standardized. Border radius, for example, is "-webkit-border-bottom-right-radius" in Webkit but "-moz-border-radius-bottomright" in Firefox. If you look at competing ideas for standardizing things like gradients, you'll find even more disagreement. This is why prefixes are needed.
The idea behind vendor prefixes is that they are implementations of ideas before conventions have been established. When two vendors implement something simultaneously but pre-spec, it's hard to tell which one will end up being canonical.
Your general convention is probably good, but in 5 years time when n parameters have ended up in your {additional} parameter, people will ask why that, too, doesn't follow a convention. The answer is definitionally that the convention doesn't exist yet, and the vendor prefix is a step on the way to establishing one.
I don't know if it's really a big deal to set up a general convention, and when new features appear, just discuss it with W3C and/or other vendors, and use it. These are the minor kinds of problems that can be solved in theory with a few emails and in practice with a 2 months thread on a discussion board (but still better than a mess)
But it isn't a mess. Finalized names are selected as part of the standardization process. That's exactly what TFA was saying: the standardization process works, but web developers are being exceptionally lazy.
What you're asking for is that the browser engineers should wait until part of the standardization process is done (the naming) before they start on implementation, only to potentially have to rewrite things once a finalized name is selected. Not going to happen.
The problem is those are BS differences that in the end don't matter much.
border-bottom-right-radius vs border-radius-bottomright, please.
Either use some consistent way of naming as you do with other properties, or just pick a f*n name and use it.
If it was some real competing ideas on the RENDERING of the visual effect defined by the property, I could understand, but the mere name of css properties is not the place to be creative. Just discuss it for 1 hour with other vendors, come to a name and USE IT.
If you honestly believe that a naming dispute could be resolved in 1 hour, then I'd wager you haven't been programming very long. As the famous saying goes -- "The two hardest things in programming are: naming, cache invalidation, and off-by-one errors."
This was just the quickest/most famous/easiest example I could think of. The other I referenced is more subtle. For gradients before standardization, Firefox included the type of gradient in the property definition, "background: -moz-linear-gradient(...)", whereas Webkit made it a parameter to the function, "background: -webkit-gradient(linear, ...)".
Webkit Dev (speaking to Webkit Program Manager) -- Hey! I've figured out a way we can give divs rounded corners.
Webkit PM -- That's cool, what do you call it?
Webkit Dev -- Well, for the bottom right it's "border-bottom-right-radius"
Webkit PM -- Cool.
<some time later...>
Webkit PM (to Webkit Dev) -- Hey! I just got off the phone with Firefox PM. He says they've also developed a way to give divs rounded corners.
Webkit Dev -- That's cool! I guess it was a needed feature.
Webkit PM -- Yeah...only problem is the name. They decided to call theirs "border-radius-bottomright".
Webkit Dev -- Oh.
Webkit PM -- Sooo, yeah. If you could just change that name.
Webkit Dev -- But we already GM'd the build with that name in it. To change it we'll have to back out of the GM, requalify the build, change the documentation, send out new seeds, redo internationalization, send it back to QA, and declare a new GM. That will push out the release by 3 weeks, and besides, I have 20 bugs in my current backlog that are completely unrelated to border radii. How important is this?
The real problem with CSS is that it hasn't evolved. Solutions like SASS/SCSS or LESS resolve this issue quite neatly. Instead of needing to know or look up the peculiar browser-specific declarations for things like border-radius, you simply say "rounded(5px)".
No, the real problem is that CSS (as it currently exists) has no means for abstraction. These approaches solve that.
Take an analogy: in the not too distant past, some microprocessors had divide instructions, others did not, but you didn't see people bracketing division instructions with platform-specific conditionals. For the most part no one cared because if you wrote "x / y" in your code, that was merely an abstraction that some compiler would break down into a series of shifts and adds or a divide, depending on the platform.
If less & co would automatically abstract css vendor-specific features just like Jquery abstracts javascript DOM access methods, you'd be right, but as far as I can see on the main page http://lesscss.org/ you still have to declare it by hand, so it doesn't work that way. Using less doesn't make styling widely compatible out of the box. Looks like what we need is less-like frameworks to evolve into cross-platform abstraction layers.
These tools are just the "compiler" in our analogy. You still need the "libc", which in this case would be something like Compass: http://compass-style.org/
With projects like Compass (http://compass-style.org) for SASS/SCSS, those abstraction layers are there. When we made WebPutty (http://webputty.net) with SCSS support, one of the first and most common questions we got was "can I use Compass", so we added it. It's pretty much the standard for abstractions.
Less is not quite there yet, but things like Twitter Bootstrap are well on their way to becoming similar standard abstractions.
> With projects like Compass (http://compass-style.org) for SASS/SCSS, those abstraction layers are there.
That's nonsense, those "abstraction layers" are inserted statically during deployment, they don't improve as browsers improve. When Google or Apple adds a proprietary -webkit- property which may never get standardized, Compass has no way to make that property available to all browsers in sites built at the time the property was solely proprietary as browsers gradually implement it (and it gets standardized) over the next years.
Code that you compiled on a machine 10 years ago is rather unlikely to still run on whatever machine you're using now. That's the way things go. Still, this is CSS's problem, not Compass's. If CSS had better abstraction abilities built in, then you could point your page to a reference set of abstractions that could be updated as browsers improve.
You making things which break is not "the way things go", it's you being incompetent, don't try to pass the blame to somebody else...
> If CSS had better abstraction abilities built in, then you could point your page to a reference set of abstractions that could be updated as browsers improve.
as you're doing here. So now to fix your own personal incompetence there needs to be a centralized authority set which will magically fix your crap as time goes on? How about doing things correctly to start with?
Pages from the very origin of the internet back in 1992 still work perfectly fine today
Yeah, but none of my <marquee> tags work. Which is funny, because that was also a non-standard, browser-specific feature. If that element had been standardized, but as <marquis>, then those pages would still break.
How about doing things correctly to start with?
I thought that's what we were advocating? Using vendor specific prefixes is the same as using a non-standard tag: it will likely break, and will almost definitely not work on multiple platforms. That doesn't seem to me, though, to be an argument against them.
If you want to complain that the standardization process is too slow, and thus people are used to continue using vendor-prefixed tags longer than they should, I'll be right beside you yelling about it. But the solution, it seems to me, isn't to "break" or abolish vendor prefixes. If you want to speed up the standardization process, do what the WHATWG did.
It's debatable whether WebKit did or didn't do anything wrong. If vendor prefixes appeared only in developer version of the browser, instead of stable releases, we wouldn't be in this situation - and developers would still get preview access to new browser features for testing, to prepare for when they become standardized.
Instead, the major WebKit browsers include vendor prefixed stuff in stable releases. Since WebKit won in mobile (and is on the way to winning overall), it isn't surprising we got to where we are now, with all other browsers planning to implement WebKit prefixed features.
If WebKit didn't include vendor prefixes in stable releases, we'd still be here 6 years after they first implemented it putting PNG files in the corners of all our divs.
The problems are the standards aren't there. The standards organization is just way too slow.
I totally agree. W3C is slow. But standards are like politics. You cannot blame W3C for 1 of the 10 parties not agreeing with the spec. And once we got it we are bound to it.
This is the reason native is always better then web. Once the technology is available one party will provide an api and it will be available in the next version of the OS.
Native is a free market approach, may the best man win. But propietary.
Web is like socialism. Everybody gets the same but the whole system doesnt drive innovation.
Mobile Firefox includes vendor prefixes, and has from the beginning. All the new Web API stuff will be prefixed where appropriate. That's exactly what standard operating procedure calls for (whether right or wrong) and what mobile WebKit has mostly done (and we're really talking Apple here, at least for the first year or two and a bunch of major CSS spec drafts).
In other words, you didn't actually say what actions may or may not have been wrong.
Including vendor prefixes in a release build, I said, is arguably wrong. I'm not arguing that it is - I honestly don't know which is better, as not including them has downsides too.
And, as you said, other browsers do this too (but less recently), it isn't a WebKit-specific thing. The only difference is that WebKit won on mobile and has become the dominant web rendering engine there, between Android and iOS (and Blackberry, WebOS, etc. etc., pretty much everyone uses WebKit on mobile).
The only solution to this would be to not have a single implementation dominate the market. But that has already happened on mobile, the question is now how to live with that. (And there is risk on desktop too.)
The problem isn't Webkit, or even web developers targeting webkit. The problem is that we have a de facto standard for rounded corners on the web, and it's still not an accepted standard. The W3C designs and approves CSS draft specs on a schedule that makes IE development cycles look speedy. The web moves faster than that now.
The first CSS3 draft for the backgrounds and borders module was published in 2001. ELEVEN YEARS LATER it's still not a finalized standard. And the problem is developers?
I've been using -moz and -webkit and -o vendor prefixes for years now, with virtually no variation or change. Why don't we have a standardized border-radius yet? By the time the W3C actually settles on a standard, the industry will be twelve draft specs ahead of them in production for all practical purposes.
I really, really dislike the idea of non-webkit vendors implementing support for webkit prefixes. Stick to your own prefixes. Don't break the rules to make up for lazy or bad developers. That's a huge part of why IE was such a pain in our collective asses for so many years. When you coddle lazy or bad developers, you end up breeding an entire crop of developers who end up creating terrible legacy systems that will plague us for years to come. Just say no. If you have to do something, go ahead and implement the draft spec.
Developers: Use Sass or LESS or similar. Start worrying about presentation and stop worrying about implementation. Until the W3C gets its act together, use tools that help you do the right thing with the least amount of effort. Everyone wins.
And it reached that Candidate Recommendation status nearly one year ago, only ten years after it was first introduced.
I'm picking on border-radius because it's an easy target, but the fact remains that large pieces of CSS3 remain in "working draft" statuses. Microsoft went all cowboy and gunked up the web with their "standards be damned, we'll do it live" approach to IE, and since then, other browser vendors have been extremely spec compliant in an attempt to avoid the same sort of mess that IE got us into, but they're hogtied by a standards body that takes longer to work out border-radius than it takes for most web companies to be born, flourish, and die.
> I really, really dislike the idea of non-webkit vendors implementing support for webkit prefixes. Stick to your own prefixes. Don't break the rules to make up for lazy or bad developers.
I sympathize with the sentiment. But you are asking all the non-WebKit browsers to not render the mobile web properly.
Like it or not, WebKit won on mobile. People wrote tons of websites that only render correctly on the iOS and Android browsers.
Other browsers can't change that by not implementing the WebKit prefixes. In fact without implementing them, they make it harder for themselves to gain market share - the only thing that can prevent a single implementation like IE or WebKit from becoming a de-facto standard.
Other browsers can evangelize - go around and ask website makers to write to standards, not to what currently works in WebKit. They are already doing that as much as they can. It isn't making much of a difference.
The web is at enough of a disadvantage WRT native apps as it is. If you disallow the kinds of enhancements that depend on a more intimate relationship with the browser, like -webkit prefixes, you put them that much further behind.
I'm not sure what you mean by "WebKit won on mobile" (maybe you mean in US) but you may be interested to know that the most popular mobile browser is Opera [1]. WebKit still has a majority when you combine iPhone, Android and Nokias but I wouldn't say it's won. The race for the mobile web isn't over yet.
One is browser and one is rendering engine. But yes, this discussion is about the latter. I was just commenting on his post. Still, these stats are very inaccurate in what we're using them for.
If you look at the graph he links to they compare Opera to Android, iPhone, iPod Touch separately despite all being Webkit based. Add them up and you have around 43% well more than the 18% shown for Opera.
If you look at the table you linked to Android plus Mobile Safari also gives 44%. Opera has 22%.
Using these stats, Opera is the most popular mobile browser but WebKit is the most popular mobile browser rendering engine / framework. Whilst WebKit being > 50% of rendering engines definitely counts for something, my point is that non-WebKit browsers account for a very significant chunk of the mobile web.
> I'm not sure what you mean by "WebKit won on mobile" (maybe you mean in US)
Aside from low-end phones in the far east, WebKit dominates in the mobile space.
In the US and Europe, there are basically two smartphone OSes: Android and iOS, everything else is tiny. And Android and iOS both use WebKit. So WebKit won.
> But you are asking all the non-WebKit browsers to not render the mobile web properly.
I don't think that's a fair caracterisation. It's perfectly proper to render a mobile site as you're told do, which is what browsers correctly do right now.
The problem to begin with is that browser makers where adding their own baked prefixes. They where not following the spec and opened the door for designers to use them.
My opinion is that final browser builds should not support these prefixes. Its too easy to say that developers are breaking the web. Actually browser makers are. Webkit is the new IE6. Cool features but they are extending the standard with their own baked goodies.
I don't think it's accurate at all. Browser vendors aren't 'extending the standard with their own baked goodies', but are merely prefixing those CSS properties that aren't yet finalized, but are part of the standardization process. There's no parallel with IE6 at all, in my opinion.
It even has support for javascript in css:
left: expression(15+((e=document.documentElement.scrollLeft)?e:document.body.scrollLeft)+'px');
And I remember you could even give your scrollbars colors.
How is this different from webkit shipping browser with cool new features now? Similar to microsoft right? They also wanted to show how cool their browser was back then. If Microsoft never shipped IE6 with these extensions we would have a lot less issues a few years ago.
Why do we have those prefixes in the first place? Ok, ok, test new functionalities is a good thing, but create bad practices among developers it is not.
All the problems with IE began when they (M word) started their with own implementation of javascript, CSS, and even HTML (automatic close for tags is not ok people, developers need to learn).
It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you. All the problems involving incompatibilities began with browser vendors trying to "simplify" developers life giving their own version of the "standard".
If a new functionality is not part of the standards yet it must be a reason. Why not respect that and avoid all sort of complications?
Why the rush?
Force organizations to release early pieces of work will generate bad industry standards.
Do not like the way how one standard is defined?
You will have to swallow. - by brazilian team couch Zagallo
> It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you.
You realize that browser vendors are members of W3C and thus essentially creating the standards [for their commercial interests]? For example, the browsers have CSS transforms today because Apple proposed them back in 2007. (Wow, that's half a decade ago; time passes fast.)
> Why the rush?
Because without the "rush" by browser vendors we would be writing XHTML 2.1.14 without any fancy HTML5 stuff.
Creating confusion among developers just because you want to release "fancy HTML5 stuff" doesn't seem to me as a good idea.
Why not first implement these new features on your own browser as "developer version only", and prove that they work and do benefit users and the web in general? I believe that is the way you establish credibility and acceptance of a particular feature.
I am not against the release of all these amazing things, but I am against the way they are currently doing it.
If the proposed features do not have defined and W3C-agreed set of names and properties associated with those features, they should not be released to end users.
I don't want to see something like "only for IE" in applications and websites anymore. The problem is still small for now, but it can become huge if this bad practice doesn't stop.
> Why not first implement these new features on your own browser as "developer version only", and prove that they work and do benefit users and the web in general?
Because of the real world needs. For example, Apple has been agressively pushing HTML5 features because they needed to offer alternative for Flash. (CSS effects, <video>, etc.)
Will wide -webkit prefix support stop sites like google.com from sniffing and blocking users? Probably not. And that is even bigger problem than forgetting to add some vendor specific prefixes. Worst thing about it is that it's all "politics". Want people to use your browser? Block other browsers and they will eventually switch. Microsoft did this, now Google does this. It's just that this time no one seems to care.
Dev^H^H^HPeople are lazy. Preprocessor tools exist but installing and running them is always extra work unless 100% integrated into workflow.
What if there was one common "-experimental-" or "-x-" prefix instead of multiple vendor prefixes? Browsers would parse them all and throw away the ones they don't support/undestand.
If you do that then if two browsers implement a new property incompatibly it becomes impossible to write a site that works in both (see gradients, where the "function call" syntax is different in different browsers).
Yes, my point is at the moment I can set -moz-gradient and -webkit-gradient (or whatever the actual property name is) using the different syntax for each, and have my page work in both.
What about one common prefix in addition to vendor prefixes?
Then you could write "-x-border-radius: 2px" in the majority of times where the property was compatible, but you'd still be able to write "-webkit-border-radius: 2px 4px; -moz-border-radius: 4px 2px" where it's implemented differently.
Won't webkit drop the prefix once things are standardised and then sites will either be broken or have to drop the prefix to o, thereby working in all browsers?
No. Apple isn't going to break existing sites out of purism. Webkit will be supporting -webkit- for decades, and so will everyone else, just as with every nonstandard tag that's ever existed.
64 comments
[ 2.8 ms ] story [ 121 ms ] threadWhy do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable.
Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others.
1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2...
2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.
In the end, everyone would just drop the prefix. Generating parsing it would be also way easier.
Your general convention is probably good, but in 5 years time when n parameters have ended up in your {additional} parameter, people will ask why that, too, doesn't follow a convention. The answer is definitionally that the convention doesn't exist yet, and the vendor prefix is a step on the way to establishing one.
What you're asking for is that the browser engineers should wait until part of the standardization process is done (the naming) before they start on implementation, only to potentially have to rewrite things once a finalized name is selected. Not going to happen.
border-bottom-right-radius vs border-radius-bottomright, please.
Either use some consistent way of naming as you do with other properties, or just pick a f*n name and use it.
If it was some real competing ideas on the RENDERING of the visual effect defined by the property, I could understand, but the mere name of css properties is not the place to be creative. Just discuss it for 1 hour with other vendors, come to a name and USE IT.
This was just the quickest/most famous/easiest example I could think of. The other I referenced is more subtle. For gradients before standardization, Firefox included the type of gradient in the property definition, "background: -moz-linear-gradient(...)", whereas Webkit made it a parameter to the function, "background: -webkit-gradient(linear, ...)".
The problem is that neither vendor is willing to solve it in one hour. They want to get their own way. It's simply arrogance.
Webkit Dev (speaking to Webkit Program Manager) -- Hey! I've figured out a way we can give divs rounded corners.
Webkit PM -- That's cool, what do you call it?
Webkit Dev -- Well, for the bottom right it's "border-bottom-right-radius"
Webkit PM -- Cool.
<some time later...>
Webkit PM (to Webkit Dev) -- Hey! I just got off the phone with Firefox PM. He says they've also developed a way to give divs rounded corners.
Webkit Dev -- That's cool! I guess it was a needed feature.
Webkit PM -- Yeah...only problem is the name. They decided to call theirs "border-radius-bottomright".
Webkit Dev -- Oh.
Webkit PM -- Sooo, yeah. If you could just change that name.
Webkit Dev -- But we already GM'd the build with that name in it. To change it we'll have to back out of the GM, requalify the build, change the documentation, send out new seeds, redo internationalization, send it back to QA, and declare a new GM. That will push out the release by 3 weeks, and besides, I have 20 bugs in my current backlog that are completely unrelated to border radii. How important is this?
Webkit PM -- Oh...not that important I guess...
Take an analogy: in the not too distant past, some microprocessors had divide instructions, others did not, but you didn't see people bracketing division instructions with platform-specific conditionals. For the most part no one cared because if you wrote "x / y" in your code, that was merely an abstraction that some compiler would break down into a series of shifts and adds or a divide, depending on the platform.
http://compass-style.org/reference/compass/css3/
Less is not quite there yet, but things like Twitter Bootstrap are well on their way to becoming similar standard abstractions.
That's nonsense, those "abstraction layers" are inserted statically during deployment, they don't improve as browsers improve. When Google or Apple adds a proprietary -webkit- property which may never get standardized, Compass has no way to make that property available to all browsers in sites built at the time the property was solely proprietary as browsers gradually implement it (and it gets standardized) over the next years.
1. That's not even true, you should try out windows once in a while
2. We're not talking about local programs.
> That's the way things go.
No it's not, that's not even a cop-out that's complete, utter and absolute bullshit. Pages from the very origin of the internet back in 1992 still work perfectly fine today: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T...
You making things which break is not "the way things go", it's you being incompetent, don't try to pass the blame to somebody else...
> If CSS had better abstraction abilities built in, then you could point your page to a reference set of abstractions that could be updated as browsers improve.
as you're doing here. So now to fix your own personal incompetence there needs to be a centralized authority set which will magically fix your crap as time goes on? How about doing things correctly to start with?
Yeah, but none of my <marquee> tags work. Which is funny, because that was also a non-standard, browser-specific feature. If that element had been standardized, but as <marquis>, then those pages would still break.
How about doing things correctly to start with?
I thought that's what we were advocating? Using vendor specific prefixes is the same as using a non-standard tag: it will likely break, and will almost definitely not work on multiple platforms. That doesn't seem to me, though, to be an argument against them.
If you want to complain that the standardization process is too slow, and thus people are used to continue using vendor-prefixed tags longer than they should, I'll be right beside you yelling about it. But the solution, it seems to me, isn't to "break" or abolish vendor prefixes. If you want to speed up the standardization process, do what the WHATWG did.
Instead, the major WebKit browsers include vendor prefixed stuff in stable releases. Since WebKit won in mobile (and is on the way to winning overall), it isn't surprising we got to where we are now, with all other browsers planning to implement WebKit prefixed features.
The problems are the standards aren't there. The standards organization is just way too slow.
This is the reason native is always better then web. Once the technology is available one party will provide an api and it will be available in the next version of the OS.
Native is a free market approach, may the best man win. But propietary. Web is like socialism. Everybody gets the same but the whole system doesnt drive innovation.
And browser vendors will ship proprietary extensions, whether you like it or not.
In other words, you didn't actually say what actions may or may not have been wrong.
And, as you said, other browsers do this too (but less recently), it isn't a WebKit-specific thing. The only difference is that WebKit won on mobile and has become the dominant web rendering engine there, between Android and iOS (and Blackberry, WebOS, etc. etc., pretty much everyone uses WebKit on mobile).
The only solution to this would be to not have a single implementation dominate the market. But that has already happened on mobile, the question is now how to live with that. (And there is risk on desktop too.)
The first CSS3 draft for the backgrounds and borders module was published in 2001. ELEVEN YEARS LATER it's still not a finalized standard. And the problem is developers?
I've been using -moz and -webkit and -o vendor prefixes for years now, with virtually no variation or change. Why don't we have a standardized border-radius yet? By the time the W3C actually settles on a standard, the industry will be twelve draft specs ahead of them in production for all practical purposes.
I really, really dislike the idea of non-webkit vendors implementing support for webkit prefixes. Stick to your own prefixes. Don't break the rules to make up for lazy or bad developers. That's a huge part of why IE was such a pain in our collective asses for so many years. When you coddle lazy or bad developers, you end up breeding an entire crop of developers who end up creating terrible legacy systems that will plague us for years to come. Just say no. If you have to do something, go ahead and implement the draft spec.
Developers: Use Sass or LESS or similar. Start worrying about presentation and stop worrying about implementation. Until the W3C gets its act together, use tools that help you do the right thing with the least amount of effort. Everyone wins.
I'm picking on border-radius because it's an easy target, but the fact remains that large pieces of CSS3 remain in "working draft" statuses. Microsoft went all cowboy and gunked up the web with their "standards be damned, we'll do it live" approach to IE, and since then, other browser vendors have been extremely spec compliant in an attempt to avoid the same sort of mess that IE got us into, but they're hogtied by a standards body that takes longer to work out border-radius than it takes for most web companies to be born, flourish, and die.
I sympathize with the sentiment. But you are asking all the non-WebKit browsers to not render the mobile web properly.
Like it or not, WebKit won on mobile. People wrote tons of websites that only render correctly on the iOS and Android browsers.
Other browsers can't change that by not implementing the WebKit prefixes. In fact without implementing them, they make it harder for themselves to gain market share - the only thing that can prevent a single implementation like IE or WebKit from becoming a de-facto standard.
Other browsers can evangelize - go around and ask website makers to write to standards, not to what currently works in WebKit. They are already doing that as much as they can. It isn't making much of a difference.
if the browser has a large market share people will use it 'wrong' aka not just for experimentation.
its like waving with free candy and blaming people for taking it.
[1] http://www.quirksmode.org/blog/archives/2012/01/browser_stat...
If you look at the graph he links to they compare Opera to Android, iPhone, iPod Touch separately despite all being Webkit based. Add them up and you have around 43% well more than the 18% shown for Opera.
If you look at the table you linked to Android plus Mobile Safari also gives 44%. Opera has 22%.
From PPK again: http://www.quirksmode.org/blog/archives/2009/10/there_is_no_...
Aside from low-end phones in the far east, WebKit dominates in the mobile space.
In the US and Europe, there are basically two smartphone OSes: Android and iOS, everything else is tiny. And Android and iOS both use WebKit. So WebKit won.
I don't think that's a fair caracterisation. It's perfectly proper to render a mobile site as you're told do, which is what browsers correctly do right now.
My opinion is that final browser builds should not support these prefixes. Its too easy to say that developers are breaking the web. Actually browser makers are. Webkit is the new IE6. Cool features but they are extending the standard with their own baked goodies.
- Shadows with: filter: Shadow(Color=#999999, Direction=135, Strength=5); - Opacity: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader (src='image_name.png', sizingMethod='scale');
It even has support for javascript in css: left: expression(15+((e=document.documentElement.scrollLeft)?e:document.body.scrollLeft)+'px');
And I remember you could even give your scrollbars colors.
How is this different from webkit shipping browser with cool new features now? Similar to microsoft right? They also wanted to show how cool their browser was back then. If Microsoft never shipped IE6 with these extensions we would have a lot less issues a few years ago.
All the problems with IE began when they (M word) started their with own implementation of javascript, CSS, and even HTML (automatic close for tags is not ok people, developers need to learn).
It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you. All the problems involving incompatibilities began with browser vendors trying to "simplify" developers life giving their own version of the "standard".
If a new functionality is not part of the standards yet it must be a reason. Why not respect that and avoid all sort of complications?
Why the rush?
Force organizations to release early pieces of work will generate bad industry standards.
Do not like the way how one standard is defined?
You will have to swallow. - by brazilian team couch Zagallo
You realize that browser vendors are members of W3C and thus essentially creating the standards [for their commercial interests]? For example, the browsers have CSS transforms today because Apple proposed them back in 2007. (Wow, that's half a decade ago; time passes fast.)
> Why the rush?
Because without the "rush" by browser vendors we would be writing XHTML 2.1.14 without any fancy HTML5 stuff.
That's why "the rush".
Why not first implement these new features on your own browser as "developer version only", and prove that they work and do benefit users and the web in general? I believe that is the way you establish credibility and acceptance of a particular feature.
I am not against the release of all these amazing things, but I am against the way they are currently doing it.
If the proposed features do not have defined and W3C-agreed set of names and properties associated with those features, they should not be released to end users.
I don't want to see something like "only for IE" in applications and websites anymore. The problem is still small for now, but it can become huge if this bad practice doesn't stop.
Because of the real world needs. For example, Apple has been agressively pushing HTML5 features because they needed to offer alternative for Flash. (CSS effects, <video>, etc.)
What if there was one common "-experimental-" or "-x-" prefix instead of multiple vendor prefixes? Browsers would parse them all and throw away the ones they don't support/undestand.
Then you could write "-x-border-radius: 2px" in the majority of times where the property was compatible, but you'd still be able to write "-webkit-border-radius: 2px 4px; -moz-border-radius: 4px 2px" where it's implemented differently.
The success of an engine lauded for its cleanliness and conciseness and architecture (khtml) over the sprawling mess of engines that preceded it.