Comments on The Vendor Prefix Predicament: ALA’s Eric Meyer Interviews Tantek Çelik

27 Reader Comments

Back to the Article
  1. No seriously, no one.

    They don’t pull the right hand edge about either changing the width.

    Copy & paste the code below to embed this comment.
  2. “We’re seeing downlevel or “feature-phone” ultra-minimal and reduced functionality experiences being sent by mobile web sites to non-WebKit mobile browsers.”

    This discussion is pretty sad, because obviously Mozilla is pissed off about not being able to enter the phone/tablet market because the web is more fun on an iPhone or Android device.

    If they care about the web, they’ll make demos that worked in all browsers.

    Copy & paste the code below to embed this comment.
  3. There are man reasons to use prefixes and many reasons to not use prefixes. I think the big issue is with the extreme delay of the CSS Working Group on pushing these widely used features into official specs. This wouldn’t be an issue if border-radius and gradient could be used un-prefixed and what is the hold up here? The CSSWG is forcing a monoculture by not ratifying these features everyone uses in a quick and efficient manner. Tantek Çelik hit the nail on the head with this one:

    ??all of the above has been exacerbated by how long it has taken the CSS working group to standardize some of these innovative -webkit- prefixed properties??

    However I am disappointed it has come to Mozilla and others cross honoring vendor prefixes from WebKit. This encourages these bad development practices and ruins it for those of us who carefully consider the use of prefixes for rendering performance, syntax differences, hardware acceleration, or whatever other reason a developer might want to exclude Gecko, Trident, or any other layout engine from acknowledging a property.

    Fantastic interview and this clears up a lot of the misconceptions going around the web. While I don’t agree with Mozilla’s decision some great points were made here on both sides. A very real issue that needs to be addressed. Thank you.

    Copy & paste the code below to embed this comment.
  4. Great piece guys. Thanks for publishing it.

    I’m increasingly worried with recent online conversations, such as this, that we are in danger of returning to the trenches of the browser wars all over again.

    I’ve noticed a lot of glib comments (on other sites) that this is nothing to worry about as webkit is universal, so what’s the problem?  I get Tantek’s point about Webkit and I also see PPK’s too.

    I think the “old guard” is doing a good job in promoting their view of the future-friendly web, but, I feel a lot of the newcomers are still not “getting” it.  That when problems arise, the dangerous fall-back of UA-sniffing or only supplying certain prefixes are employed, to the detriment of all other platforms.

    Hopefully this will spark a rallying around web first, mobile/desktop second, browser third.

    Copy & paste the code below to embed this comment.
  5. What do you expect when the same evangelists that promote standards, promote 0-portfolio CSS “geniuses” that do nothing but create experimental stuff like pink gradient goodies signing “sorry, didn’t have time to test in FF or IE”.
    If these people had only one past work experience in a normal enterprise or a governmental institution, they’d understand what cross-browser and accessible really means and how we’re busting our behinds everyday making sure things work for everybody.

    Copy & paste the code below to embed this comment.
  6. Gentlemen. Mozilla.
    Clients I have to satisfy are 3 and 4 letter majors, and they want the fast flippy slick stuff i show them in -webkit. So when it fails in firefox, they blame ME not firefox, and act as though they deserve a “fix” immediately.

    These are V.P. of whatever people that want the screendance… not the excuse, and they are not going to talk to you. So…

    YOU DONT GET THAT “DATA” —its in a closed door NDA driven scenario. Its been years now. Talk - talk - talk. Modernizr? jquery? please dont patronize me. Canvas is not required to do much of these basic things. And the problem is escalating in touchscreen mobile for the GPU access is buried in CSS call tricks.

    You speak as if “data collected” is the decision driver. I can tell you right now that you dont know what you have done to us else you would have corrected these issues last year… and you will never be in rooms where serious business is underway.
    Hence your evidence to decision lag is baked-in.

    If you dont feel our pain then you are not bothering to… its there and getting more intense by the DAY not the month. What we get is yet another incremental version number and more of the same pain… and some VP of interactive wanting to know when the ( This is an actual quote )  “Firefox problem is finally gonna be done yet”...

    Copy & paste the code below to embed this comment.
  7. Miles Cheverton said “Nobody looks at sites in different browsers. No seriously, no one.”

    I do. And professional web designers do, or should do.

    So do consumers. My wife had IE6 at work, Safari on her iPhone and Opera on the home computer. If she needed to use her bank website, or find the dentists phone number, or check her eBay auction, or check the news she’d do so on different browsers depending on whether she was at work, on the bus or on the phone.

    Is Miles really suggesting that everyone has either one single device on which they access the Web, or have multiple devices, each running exactly the same version of exactly the same browser? Sure, some people will fall into each of those categories, but not everybody as he suggests.

    Copy & paste the code below to embed this comment.
  8. So, maybe I’m missing something here, but what happens when Mozilla takes a different interpretation of how a _-webkit_ property should be implemented?

    Let’s imagine for a moment that this goes through, and Mozilla starts to implement certain _-webkit_ properties—say, _-webkit-flashbang: true;_, for example. WebKit implements the property by causing the screen to alternately flash blue-green, blue-green, blue-green. Awesome. Mozilla, on the other hand, implements the same property, but causes the screen to alternatively flash black-white, black-white, black-white instead. Seizure-inducing.

    The way it stands now, a designer could use _-webkit-flashbang: true;_ for WebKit users only, knowing that they would get a blue-green flash, and Mozilla visitors would get nothing (unless the designer also included _-moz-flashbang: true;_, which presumably would fire a black-white, seizure-inducing flash). If Mozilla supports _-webkit-flashbang: true;_ (incorrectly, remember), Mozilla visitors will end up foaming at the mouth and thrashing about. And because the Mozilla implementation of _-moz-flashbang: true;_ is also seizure-inducing, there’s no way to override the incorrect behavior (aside from, perhaps, using _flashbang: false;_, which would break things later on down the line). Designers would have no choice but to stop using _-webkit-flashbang: true;_ if they cared about their visitors. And because they have to stop using it, the CSS Working Group looks at _flashbang_ and decides it has no place in the spec, when, in reality, it’s not being used due to poor implementation.

    To put it another way, remember “all the hoops we had to jump through”: due to IE’s “different” method of interpreting the box model?

    Or am I missing something?

    Copy & paste the code below to embed this comment.
  9. “all of the above has been exacerbated by how long it has taken the CSS working group to standardize some of these innovative webkit prefixed properties”

    Since the CSS Working Group also contains representatives from Mozilla, Opera and Microsoft, what have they been up to in the CSS WG all these years? This -webkit dominance couldn’t have happened suddenly overnight. What’s been holding up the WG, and what have browser vendor representatives done in the Working Group to alleviate these holdups? Are the holdups because of roadblocks by non browser vendors?

    Copy & paste the code below to embed this comment.
  10. If firefox mobile is going to support -webkit vendor prefixes, it should happen via an opt-in rather than automatically. I’d take the tradeoff of one more meta tag for the slimmer CSS file.

    Copy & paste the code below to embed this comment.
  11. Mike, one thing that’s been holding up the WG are things like Apple employees saying they’ll edit a spec and then just disappearing for months at a time before popping up, saying “I’m working on it” and disappearing again.  Another thing that’s been holding things up is Apple refusing to submit some of the -webkit properties for standardization at all (presumably because they have patents covering the behavior and would have to license the patents if the property were actually standardized).

    Copy & paste the code below to embed this comment.
  12. I never liked prefixes. I try to avoid them as much as possible on real projects. This article clearly is another reason to keep on doing so. It was meant for experiment. I am perfectly happy with the fact that IE6 is gone. All the other browsers support enough standard CSS to make beautiful, lightweight web sites, accessible to all. Don’t need all that extra make-up (sic).

    Copy & paste the code below to embed this comment.
  13. @andyford
    > I’d take the tradeoff of one more meta tag for the slimmer CSS file

    while a slim CSS file is nice to have, gzip compression is readily available everywhere nowadays, and it often renders that advantage negligible.

    Copy & paste the code below to embed this comment.
  14. Reluctantly I agree with Tacek, but I think there could be more done to encourage developers towards using unprefixed properties/all available prefixes. For instance the CSS validator on w3c has an accept prefixes as valid mode - this could be made a lot more sophisticated, alerting users when a feature has been standardised and the unprefixed version is available, and also alerting them when they are not using all prefixes that are available. Webkit developer bar, firebug and ie developer bar could also ship similar functionality to generate warnings when insufficient/overzealous use of prefixes is made.

    Also, I think these problems are exacerbated by the fact that W3C work on large all-encompassing specs. If the spec changed incrementally, adding one feature at a time rather than adding many features at once, then the time taken to standardise and unprefix experimental features could be vastly reduced.

    Copy & paste the code below to embed this comment.
  15. Natural selection in the digital world also have place.
    Problems of websites are usually converted into the problem of users who can not open these sites correctly.
    Browsers need to compete with each other, but it is desirable to do everything exactly the same as competitors.
    The main thing is that the site would worked everywhere.

    Copy & paste the code below to embed this comment.
  16. Perhaps I’m wrong, but it seems to me that the history of this issue boils down to this: One browser was more capable than the others, and developers built sites that took advantage of that. As time passed, other browsers became equally capable, but developers (who are creatures of habit) continue to develop using methods that favor the first browser.

    I can’t help but take a step back and wonder why the browser makers aren’t *talking to the web developers*.

    This is a PR problem, not a technical one.

    Instead of making software changes with unpredictable repercussions in response to either out-dated or ill-informed practices by developers, why not instead spend that effort on a PR campaign aimed at those developers. I’m not suggesting they all take out ads in .net magazine, but rather spread the word through conferences and interviews and participating in communities.

    Copy & paste the code below to embed this comment.
  17. Tim, Opera and Mozilla have both been contacting web developers who are abusing -webkit prefixes.  Opera has a 20+ person team dedicated to doing such outreach.  If you actually read the minutes of the CSS working group meeting in question, you’ll see that such outreach efforts have failed: most of the time the web developers flat out refuse to fix their pages.

    Furthermore, Mozilla has been advertising their support for the various features involved a good bit.  It doesn’t have the PR reach of Apple and Google, of course…

    But again, Google is creating sites that only work in WebKit and it’s not that the Google employees involved don’t know other browsers exist or don’t know the other browsers have the same capabilities.  They’ve been explicitly contacted and told that.  They just don’t care at all about making their site work in the other browsers.

    Copy & paste the code below to embed this comment.
  18. I’m in complete agreement with Tim. This is a PR outreach problem where the pundits/evangelists need to talk to developers. This is not an issue of bad practices, but we do need to reiterate, and remind everyone that the mobile space is not a on-browser-to-rule-them-all ecosystem, and that like the PC browser space, there are alternative browsers, and people need to develop in a multi-browser environment.

    This is not a case of lazy developers (which I’ve seen mentioned around the web). If things are being published that are broken in other web browsers, that’s one thing, but the idea of using a particular browser’s “vendor prefixed” features, is another, and follows the ideas of progressive enhancement, where if a feature is available to a particular browser, you can send an enhanced experience.

    The idea of the lazy developer who doesn’t go in and update their codebase every time another browser vendor gets on board with a new feature is ludicrous, and shouldn’t be part of the discussion. It’s arrogant, and doesn’t add any value to the conversation. Think of all the developers, who _can’t_ just go in and update a codebase, because that would require discussions with account teams, clients, change orders, regression testing, and money. What world do you people live in, that a developer can just go in and arbitrarily update the codebase anytime they want?

    If people want to call out Apple/Webkit for going down their own path with no regard for the rest of the web, then by all means, write an open letter to Apple, put an ad in the NY Times, and start a campaign, but don’t blame developers. Look to the pundits/evangelists who’ve said yes, these things are good to go, and you can use them in production, or to the iPhone/iPad/Apple evangelists who take the position that there is no other browser other than Mobile Safari.

    I can’t believe the other browser vendors would even consider the idea of supporting -webkit- prefixes - that’s ludicrous! Talk about a broken web…

    Many of the browser vendors are on a fast release cycle now, but the W3C is on slow grind. Perhaps if the W3C WGs could get on a faster track themselves (and I don’t mean as fast as the browser vendors) they would be able to mitigate issues like this.

    Copy & paste the code below to embed this comment.
  19. Doesn’t this move just contribute to the so called webkit monoculture? You are reinforcing that developers should use that prefix. Plus you’re basically substituting -webkit- for -x- even though you say that -x- is a problem. And to make it even WORSE you say you’re only doing it for mobile. I get that it’s a slippery slope but there are just too many contradictions here.

    Copy & paste the code below to embed this comment.
  20. So much effort to combat lazy developers and their lack of forethought.

    Vendor prefixes are fine to allow developers to test out the latest CSS features but this smacks of closing the barn door after the horse has bolted. Surely we should be educating rather than firefighting a problem that shouldn’t exist in the first place?

    And wouldn’t Mozilla’s time be better spend rolling out proper non-prefixed CSS support?

    Copy & paste the code below to embed this comment.
  21. I highly respect Mozilla, but this is by far the worst idea they’ve ever had. It’s like Iowa renaming itself to Hawaii in order to boost tourism. If you want developers to target your browser, BE A BETTER BROWSER.

    But in reality Mozilla isn’t the problem—it’s the standards committees. Not just for CSS, but for JS too. They move at a snail’s pace, endlessly debating rather than listening to what developers actually want. This is why prefixes have been nice - they bypass the committees, find out what works and what developers like, and then feed it back into the standards.

    Copy & paste the code below to embed this comment.
  22. @bluedreamer and @mpage et al

    Have you even read the articles and the other comments?

    How can Mozilla, Opera and MS “roll out” non-prefixed CSS support for features that Apple are *not even submitting* to the W3C?

    And how can they do it for features that are submitted, but nothing happens, because *Apple* purposefully drags their feet in the standardization process?

    And how can the W3C “get on a faster track” when it is *Apple* representatives at W3C that are slowing the process down? The W3C is just a meeting place for browser vendors and a few other interested parties. If a browser vendor does not play ball, there is nothing the W3C can do.

    Copy & paste the code below to embed this comment.
  23. Great post. I was checking continuously this blog and I’m impressed! Extremely useful info specially the last part :) I care for such information a lot. I was looking for this particular information for a very long time. Thank you and good luck.

    “Web Design Company”:
    “Technology News”:

    Copy & paste the code below to embed this comment.
  24. We all knew it was coming and now its here making waves in the Bollywood film fraternity. Yes, everyone in tinsel town is talking about Director Samir Karnik’s Yamla Pagla Deewana which can also be called as Dharmendra, Sunny and Bobby. Yep, the Deols are back in full swing after their 2007 family drama Apne, which went on to become a box office success. The first look of Yamla Pagla Deewana got tongues wagging and expectations rode sky high. This is a story of two conmen from Banaras. Dharam Singh and Gajodhar Singh [Dharmendra and Bobby Deol], who discern nothing apart from eating, drinking and cheating upon people who trust them. But their life takes a turn when an honest NRI from Canada, Paramveer Singh Dhillon [Sunny Deol] comes into their life and claims that he is the elder brother of Gajodhar. Soon, Dharam and Gajodhar gel well with Paramveer into their game plan and make use of him to fool people and cheat upon them to an even greater extent. Gajodhar falls in love with a girl from Punjab Sahiba [Kulraj Randhawa] but Sahiba’s brother (Anupam Kher) does not approve of this match. It is at this point that Paramveer comes to the rescue of Gajodhar and comes out with a plan to win over the girl and his brother.The movie has it all, from great action scenes to nostalgic music to some seriously slapstick drama. Some of the colloquial funny dialogues will make you fall off your seat. One would be amazed and awe-struck to see Dharam paaji hop and groove at 75. His acting like always has been timeless classic. Sunny Deol looks firm and handsome with his tough looks and headstrong acting. Bobby on the other hand plays a cool customer with a sense of humor. Actress Kulraj Randhawa who plays Bobby’s love interest does a decent act.

    Copy & paste the code below to embed this comment.
  25. cone crusher
    Jaw Crusher
    mobile crusher
    Jaw Crusher
    Impact Crusher
    stone crusher

    Copy & paste the code below to embed this comment.
  26. bq. Tantek said: When users see a substantially worse experience in a different browser on the site on the same device, they blame the browser, not the site, nor the device.

    Really?  When my wife, who could care less about browsers or web standards, goes to a broken mobile site, she first blames the site, then the phone.  The idea that she could download a different browser for her iPhone hasn’t even occurred to her.

    I’m a web developer, and I find myself doing the same thing: blaming bad functionality on the site not having a mobile version or a badly-implemented mobile version, not the existence of vendor prefixes.

    How much further down the HTML5 road do we have to go before the CSSWG wakes up and smells the coffee?

    Copy & paste the code below to embed this comment.
  27. I have read this article and it is Very helpful

    Copy & paste the code below to embed this comment.
  28. Sorry, commenting is closed on this article.