Daniel Glazman, co-chair of CSS Working Group, informs us non-WebKit browser vendors are considering supporting the -webkit- prefix in addition to their own for some CSS features.
In particular Mozilla, who currently uses the -moz- prefix for experimental features, said “Zero is not an option for us” when talking about how many features they should support with the -webkit- prefix. Daniel calls for developers and evangelists to stop being lazy/negligent and use all the correct vendor prefixes instead of just -webkit-.
Remy Sharp says this is a bad idea because it affects the expectations of developers and will likely make us even lazier about prefixes.
Other folks in this this ain’t good crowd: Rachel Andrew, Bruce Lawson, and Gilles Vandenoostende.
Christian Heilmann says we as developers got ourselves into this mess, so let’s get ourselves out of it.
Aaron Gustafson begs us to at least fix our own stuff and created a petition against other vendors supporting -webkit-.
Eric Meyer is pretty sure we aren’t going to win this battle.
Need help getting the prefixes right? Prefixr, Prefix-free, CSS3 Please, or use a preprocessor.
And what’s your opinion on this Chris?
It’s that of surprise, really.
I wonder how many people that use Firefox as their primary browser are browsing to sites that are broken and unusable because of lack of -moz- prefixes? My guess: hardly any.
And what if Firefox 11 starts supporting -webkit-? Doesn’t that just mean more websites will work better? What’s so bad about that?
I guess the answer is, like Remy suggested, long term and a battle of the minds. If the end result of browser vendors doing this is more sites being lazy about what prefixes they use, that’s a bad thing, and a real possibility.
There is also the possibility that even if vendors do this all this drama doesn’t turn out to be that big of a deal.
If I was pressed to see the future, I’d say: bad idea, don’t do it.
Instead of other browsers all supporting
-webkit-
, why not bolster support for prefix-less code? It seems to make more sense than shoehorning other vendors into another vendor prefix.I completely agree. Support the W3C standard, not more prefixes.
They can’t just “start supporting the standard” in most cases because there is no final standard to support. That’s the whole deal with prefixes. The browser vendors are ahead of standarding, releasing features that aren’t completely standardized yet. That way feedback can be gotten from real web authors, and when they day comes the standard is done (which requires browser implementation btw) they aren’t starting from scratch.
Why didn’t someone come up with the idea of using the same prefix for all browsers? If we got rid of -moz -webkit -o -ms and just used some generic prefix for every browser then there wouldn’t be this problem right?
I agree with Christopher. Why not just
-x-box-shadow
,-x-linear-gradient
, etc? If there are incompatible implementations, just list both and the browser uses whichever one it recognises. Problem solved!Why not then just use
box-shadow
andlinear-gradient
?Because the actual names of the properties are not agreed on yet.
Take this for example:
-webkit-border-top-right-radius: 20px;
-moz-border-radius-topright: 20px;
Yeah, this is a dumb idea for the browser vendors. There have always been bad developers. In the olden days, bad developers made sites that only worked in IE. Mozilla didn’t change their browser to work like IE, they stuck with web standards. Right now they should just stick with their own vendor prefixes, and all of this will shake out once the actual properties are supported without the need for vendor prefixes.
Mozilla changed their browser to work like IE in all sorts of ways. innerHTML support, check. document.all support, check. Sniffing of text/plain content (not to the exten that IE does, but some), check.
Not doing those was not an option if it was going to be usable by actual users.
That’s the situation with the -webkit prefixed properties now. Supporting all of them is not necessary, obviously, but supporting a few very commonly used ones is a must for anyone trying to be a browser on a phone.
Relevant tweets:
I think that one prefix should be given for experimental uses, for example: “-exp-” or something like that, and then for the common ones, remove the browser prefixes; I don’t see why things like text-shadow doesn’t have one, but you need one for box shadow.
Because text-shadow is from CSS2, if I remember correctly. Box-shadow has had vendor prefixes until recently (I believe the current versions of Gecko and WebKit no longer require it) because it was an experimental CSS3 feature. Now that it’s mature, the newer versions dropped the prefix.
It’s bad practice for sites to use a prefixed attribute while leaving out the “real” one, and browser vendors shouldn’t encourage it. People just need to update their crap instead of using Firefox 3.6.
Is there anything that prevents the W3C to move faster? We all agree they are slow, is there a mechanism that can be put in place to speed them up? Maybe a requirement that specs must be set in after 2 years and move on.
Yes, Browser Vendors prevent W3C to move faster.
This issue makes me think back to how -webkit use to do gradients and how -moz use to do gradients.
-moz implemented css gradients in a much more “readable” fashion compared to how -webkit did.
Could a move to using one prefix create laziness in thinking of “better” ways to write CSS as we had with css gradients?
The issue is that we have all these browsers and versions showing one internet. It’s the developers’ responsibilities to ensure web development can exist, else what purpose do they server? Instead of FF and IE pushing for ‘-webkit’ rendering, why not have all the browsers push a ‘-we-still-can’t-figure-this-shit-out-yet’ standardized “experimental/not yet standardized” prefix.
I with the “this isn’t good crowd”. I really have nothing against vendor prefixes, tho I will readily state how much of a pain it east to have to remember 4 different syntaxes for making a gradient or type the same thing over 6 times just to get rounder corners. I am diligent about hitting everything tho.
However, the purpose vendor specific is to be just that, VENDOR SPECIFIC and thus prevent the need for hacking your CSS. It also doesn’t truly solve the true issue at hand. I am not even particularly happy that -web-kit has multiple syntaxes for some proprieties.
We have forgotten the true reason these prefixes are in use; all of these properties are DRAFTS. As such support, rendering, and syntax varies not only from vendor to vendor but from version to version ( in some cases)
It seems to me, that it would take some coordination for moz to copy webkit and I wish I they would put that effort in standardizing the FINAL code instead. This in response for the outcry of using “-exp”. As UAs vary in support and render and interpret things differently having a single prefix is no different from dropping the prefix altogether.
This prefix are for experimental features only, or they should be, if there is concern related to them, I guess that the css community should push forward the css3 standardization.
Hasta ahora, quienes han sufrido el desacuerdo entre los desarrolladores de los navegadores hemos sido los desarrolladores web y los usuarios.
¿Será el tiempo de cambiar esta situación?
¿Y por qué no un único prefijo no privativo para todos los navegadores?
Algo como
-feature-position: center
Y que quienes pongan el trabajo de uniformar la situación sean los desarrolladores de los navegadores.
And now, in google traslate ;-)
So far, those who have suffered the disagreement between developers of browsers have been web developers and users.
Is it time to change this situation?
And why not a single non-proprietary code for all browsers?
Something like:
-feature-position: center
And those who put their work to standardize the situation are the developers of browsers.
I guess I’m the minority, but I don’t have much of a problem with vendor prefixes other than they make my CSS look ugly.
Feel like I remember seeing this suggestion somewhere, but I’d love to see an intermediary prefix (call it -wd [working draft] or -beta or -exp or whatever).
That way, browsers can continue to implement new features in the scope of their own prefix. Once features are well-established enough to be universalized, but not yet developed to be declared in the spec, all browsers can share a beta equivalent. And when they’re (finally) made official, move down the chain.
I don’t think even lazy-but-bleeding-edge developers would mind
-webkit-opacity: x;
-wd-opacity: x;
opacity: x;
Seems like it would follow well the principles of progressive enhancement.
Benevolent dictators do exists, which is why dictatorships aren’t automatically a bad thing.
People comparing WebKit-dominance to the IE6 dark ages are completely missing the point. IE6 was bad because Microsoft sat on their laurels. They demolished the competition and went out of their way to harm web innovation.
WebKit is not Internet Explorer. WebKit receives code from multiple sources and is independently governed. Not only this, but to top it off it is open-source.
Google, Apple and other WebKit contributors love the Internet. Ignoring the vendor prefix issues for just a moment, is it such a bad thing that WebKit is setting the pace for web browser standards? I’d personally prefer this to waiting for the W3C all the time.
I’d personally prefer not to have to use vendor prefixes at all, but for this to happen we’d need the W3C to move 1000 times faster than they currently do.
We have de-facto standards. Do we really need vendor prefixes anymore? The only reason that will force us to use them still for a long time is backward support for the browsers released in these years. Future sucks.
that is great news
great news?
well for me , it aint man.
this will affect the future of web development…
I hope the comments here gets a heads up to CSS Working Group…
we just dont agree
I absolute agree with the Kseso opinion, simplicity.
I for one have no problem using all vendor prefixes + standard rule. Ugly code – yes. Extra lines – yes. Backwards compatibility? Yes. Same way I separate my lame IE filters into separate stylesheets, I use all the vendor prefixes. It’s no skin off my back and it ensures my site will work whether the browser implements prefixes or the standard syntax. It’s not rocket science, people. If you’ve ever had to develop for IE6, this is a cakewalk comparatively. Even though some browsers are on rapid release cycles we shouldn’t assume everybody is updating as they should. Why is there such an uproar about backwards compatibly? Of course they SHOULD use that standard syntax but they don’t. Get off the high horse and just use all the prefixes + standard syntax. PROBLEM SOLVED.
I’d rather go with the standards and use prefixes only when necessary with a gracious fallback if it doesn’t work.
I agree with Garrett’s opinion.
Yes, using vendor prefixes is a bit cumbersome, but not hard. And we get sites that look & work the way we want them to.
And as he said, compared to what we used to endure struggling to support IE6, it’s indeed a cakewalk.
I always think of the man hours wasted implementing a feature set from another vendor.
It’s 2012, two of the main browser engines are open source, yet we haven’t standardised?
A waste of time, energy and resources at all levels of the development chain.
This is a catalyst to snap out of the “tinsel mode” that I had began falling into.
Instead of stuff like:
I’ll go with:
Sure it won’t actually do anything in any (?) browser right now but it’ll actually make my sites feel original by being bad ass old school. I can’t remember the last time I visited a new site and it didn’t use fancy fades, transitions and the like.
The nub is this: Is it worth all the hassle to write that code, have this debate all over the internet and the philosophical pains in your brain just so you can have a rounded corner on your box? Screw it…if this is how it’s going…just have a square edged box!
Rounded corners though
Its great to see some discussion about this as its becoming a bit of an issue as CSS3 matures. Wither it’s a declaration like http://felipe.wordpress.com/2012/02/02/a-proposal-to-drop-browser-vendor-prefixes/
Or a grouping of prefixes into one experimental prefix, that to me sound more like progress than listing out the variation for every statement.
The idea of 5 almost identical lines of code for the same action would be considered sin in any other coding situation, but here its considered cutting edge.
Allowing Moz to read the Webkit prefix will compleatly kill any Moz development in the future, who will add it when they no longer need it. Mozilla have contributed some great stuff through there prefix over the years.
Also.. (I know I’m ranting) unless Opera and Microsoft follow suit then this problem wont have been solved, only confused further.
Will be fun however this develops
Very well said Paul Ferguson, i`m with you on this one!
I do love the “browsers should just do X. there, problem solved.” type comments. Very similar, in their oversimplification to those people (taxi drivers are the classic example) always waxing on about “what would get the economy back on track…”
[disclaimer: I work for a browser manufacturer, but this is my own opinion/view. I’m not an expert in the matter, just calling it as I see it]
The reality is: there IS no simple solution to this mess. Vendor prefixes were a mechanism to allow different browsers to have a go and test their ideas. Different browsers would try different approaches (see the gradients syntax debacles for a good example). Only from the experience gathered from actually implementing these experimental features can the final spec be crafted, to make sure the proposals are actually implementable and workable.
Other times, browsers actually use the vendor prefix mechanism to invent completely proprietary constructs, with no actual intention to bring it to the standardisation table. Yes, in a way, they shielded their proprietary stuff from the web with the white handkerchief of vendor prefix, but they still push it to the wild web.
Then, developers started using these experimental features in production sites (often because standardisation was taking long, since browsers weren’t agreeing on the exact syntax/usefulness). You get a critical mass of sites that then use the prefixed versions…so much so, in fact, that even once a feature is standardised, browsers (yes, even Webkit itself) simply can’t drop the prefixed versions anymore, since they’d be breaking sites that were coded specifically for them overnight. It gets even more complex when a prefixed version has a different syntax from its final version…browsers end up having to support both.
In hindsight (which is always 20/20), browsers should perhaps have used vendor-prefixed stuff only in labs/beta/aurora/whatever builds, NOT in the stable releases. That would have given them the advantage of getting a feature implemented and tested (for feasibility first of all, and then by authors…but admittedly, only those authors brave enough to run labs etc builds). But hey, that won’t give them actual kudos and market advantage, so… that didn’t happen.
And in hindsight, developers should have been wiser than using experimental/unstable CSS in their production sites. They now created so much legacy stuff out there (and are unlikely to now go back to those sites and change the CSS to prefix-less once something becomes stable, because hey, Webkit supports the old -webkit version indefinitely anyway, so what’s the problem?) that the web well has been poisoned beyond salvation.
This almost reminds me of the catch-22 situation we had at the time with the CSS box model debacle, and how this brought about the whole DOCTYPE switching idea as a last-ditch effort to get out of the problem…well, there’s no new markup we can just throw at the problem now. Both browser manufacturers AND developers have painted themselves in a corner with this one.
For those who mentioned things like “Firefox didn’t change to follow IE6″…actually, a lot of the early browser wars time (and particularly more so after Netscape’s demise) was spent reverse engineering some of the secret sauce that IE was doing, for better compatibility (mostly in the JavaScript side, admittedly, but even with some undocumented CSS stuff). Haven’t got references to it off the top of my head, but if needed I can do a bit of digging.
Chris: “I wonder how many people that use Firefox as their primary browser are browsing to sites that are broken and unusable because of lack of -moz- prefixes? My guess: hardly any.”
If you look at a large number of mobile-oriented sites, particularly in the US, they almost exclusively use -webkit prefixes (and they do crazy UA string sniffing and such, which doesn’t help either). And they don’t even consider proper coding practices and fallbacks (trivial examples: white text on a box, then they define a dark gradient with one vendor prefix, but forget to set a regular dark background colour for other browsers at least. end result: white text on white background. lovely…)
Ah, but developers are just coding for the browser engine with the biggest market share, who can blame them? Well, using that rationale, we should have just stuck with targetting Trident over 10 years ago…
Anyway, this rant is getting far too long…
There has been many mistakes along the way since the Web was conceived and I am not going to list them all. I can’t help but quote Winston Churchill on this one.
Success is the ability to go from one failure to another with no loss of enthusiasm.
This is true to both vendors and designers. So yeah, things have gotten a bit out of hand, but again, it’s all about making those mistakes, right. If browsers need to keep vendors then so be it. I prefer to have vendors, it makes this stuff possible NOW as opposed to a few years or months down the line.
I don’t think anyone is talking about what I see as the main reason other vendors are pushing to do this:
If many tech demos work only on webkit, and many sites look better on webkit, then users will prefer to use webkit where everything looks cooler and works better. It’s not about whether sites are totally broken, it’s about a general better experience of the web and yes.. in this respect slight appearance improvements make a huge difference despite what everyone seems to be saying.
Now other browsers are trying hard to implement cutting edge stuff, but everyone’s just using webkit, and as far as staying competitive, they identify a very easy way for them, of their own volition, make their browser appear to be cutting edge without having to get 10000s of web developers to do it.
From a vendor (vendor = someone selling something) point of view, it just makes the most sense and is almost a no-brainer.
I agree that for the web as a whole it’s bad, but let’s see things from the vendor’s point of view to try and find a solution.
“make their browser appear to be cutting edge”
aeh…”appear”? other browsers aren’t going to map cutting edge -webkit stuff to some sub-par simulacrum, but to the exact same cutting edge feature. so nothing to do with appearing to be cutting edge…they’re on the exact same cutting edge (and in many areas, even further ahead than -webkit stuff).
True-ish, I didn’t mean to imply other browsers are inferior. Though if they’re not feeling that way (Even if only practically), why do they want to use a different browser’s prefix?
Damon: “make their browser appear to be cutting edge”
aeh…”appear”? other browsers aren’t going to map cutting edge -webkit stuff to some sub-par simulacrum, but to the exact same cutting edge feature. so nothing to do with appearing to be cutting edge…they’re on the exact same cutting edge (and in many areas, even further ahead than -webkit stuff).
oops, sorry for the double-post.
Damon: it’s not about other browsers feeling inferior (huh?), it’s about making up for the fact that developers don’t even seem aware of the fact that the features they so diligently prefix for -webkit only are actually present, just the same way, in other browsers. Other browsers are patching around developer ignorance/lazyness (talking here about the oh-so-common stuff like transitions, 2D transforms, border-radius, etc)
And it seems to become a self-fulfilling prophecy for devs: they only ever use -webkit prefixed stuff, and then they share their own impression that webkit is so much more cutting edge than other browsers…even though they never bother to actually realise that those exact same cutting edge features are also present in the other browsers…
So i’m really not getting where you’re coming from…
I said this to Patrick on Twitter, but it bears repeating…
“If people think a restaurant (that has good food) actually serves bad food, it’d eventually go out of business regardless. We (me, Patrick, those like us) know IE6 sins of the past are being revisited in -webkit. But perhaps that’s not as obvious to new folks.”
That’s not to say WebKit as a rendering engine is to blame.
But as designers, we are quick to rally behind whatever browser is perceived to be on (though this might just on-par) the cutting edge. Because it makes things simple(r), we crown a king — much like with IE6 — to the exclusion of other browsers.
We thereby paint ourselves into a corner all over again, rather than continuing to develop sites in the spirit of Web Standards — Interoperability. (Note: Yes, I know we’re talking not-yet-standardized CSS here.)
Hopefully I’m not coming across as dogmatic. Personally, I’m fine excluding old browsers if that’s a business decision cutoff that must be made. But what’s a shame to me is that perfectly capable modern browsers aren’t being allowed to render a page to the best of their respective abilities, due to ignorance and/or laziness on the part of designers.
Again, that’s not really any single organization (or person’s) fault. It is simply the current state of web browsers. Having always tried to be inclusive to as many (current version) browsers as possible, it’s a bit surprising to me, that this is even a discussion that’s coming up amongst browser vendors.
Then again, I’m just an outsider (designer), looking in.
I’m tending to agree.
It’s an ironic situation. Everyone loves competition, so you don’t end up with an IE6-esque domination and stifling of innovation.
But at the same time everyone loves a stable, consistent platform to design from….which lends itself a single browser / single rendering engine / single (quick to update) standards base.
There’s three types of features at work here: standards, early adoptions, and experiments.
We should be…. *experimenting* with the experimental features, not making them critical parts of the design or application. Let’s not punish the user for not choosing our browser.
But we shouldn’t be punished because Chrome and FireFox have decided to be earlier adopters, either. A lot of my corporate clients choose not to be early adopters because they ride the “standards” line or the “must look the same in all browsers” bit.
Let’s keep the prefix for the experimental stuff, but come up with another solution for early adoption. maybe add -x- or -w3c- to denote that it’s a widely adopted and pre-approved feature, or let us drop the prefix alltogether.
this move of mozilla is nonsense, now that the web is sort of recovering from the hell of ie6 and legacy mumbo jumbo they tought on supporting
-webkit-
prefix is a move backwards, for me is like we are using tables for layout again.I must have had my head in the sand, as I was completely unaware of this webkit only coding. I just ensure I check css3please regularly and update my CSS accordingly. No hassle, no bother.
I probably wouldn’t have been as interested in SASS and @mixins if it wasn’t for the vendor prefix deabacle – love a silver lining.
@Druid of Lûhn – I thought I loved the -exp idea, except for the implementation across browsers.
i like turtles
I’m all for vendor prefixes going away. I’d love to see a standard of ‘production’ and ‘experimental’ tags that are the same across all browsers. *pipedream*