Eric Meyer of A List Apart, CSS wizard and fan of vendor prefixes, interviews Tantek Çelik, Mozilla’s web standards lead, on Mozilla’s controversial plan to support -webkit- prefixed properties.
Tantek precipitated the current crisis in Web Standards Land during a public meeting of the W3C CSS Working Group, in which he noted the predominance of WebKit-only mobile sites, thereby creating a browser monoculture. Tantek discussed Mozilla’s solution — having Firefox Mobile pretend to be like Webkit and support a few -webkit- CSS properties — which inflamed many in the standards community, especially when representatives from Opera and Microsoft immediately agreed about the problem and announced similar plans to Mozilla’s. The following discussion was conducted via EtherPad, instant messaging, e-mail, and telephone calls.
Let’s start with the basics. What exactly are the Mozilla, Opera, and Internet Explorer teams planning to do?
I can’t speak for the Opera and Internet Explorer teams. Mozilla is currently analyzing mobile web sites for a couple of problematic behaviors—sites that are sniffing for a WebKit user agent string, and only sending high-fidelity mobile content accordingly; and sites that are using only or primarily -webkit- prefixed properties.
Based on that analysis, we are planning on implementing a UA string for Firefox Mobile that passes such UA-sniffing—ironically, this is similar to how WebKit added “like Gecko” to its UA string when Safari launched—and implementing specific -webkit- prefixed properties on a case-by-case basis, when justified by the data collected.
You’re not going to just universally map -webkit- to -moz- ? The plan is to only support a limited subset of all -webkit- properties?
Right. Our goal here is to minimize the number of other vendor-prefixed properties that we have to support to only those that are justified by the data, and that will make a difference to Firefox Mobile web users. The data we have so far does not justify blanket support of all -webkit- properties.
In addition, we are considering only supporting the -webkit- prefixed version of a property if and/or when we also support the unprefixed version. That will provide web developers with a standards-based option instead of using prefixed properties.
But as of now, we don’t know which properties that will be. Or do we?
We don’t have a specific list as of now. We’re being very deliberate about this, and scrutinizing our data accordingly to make sure that we have data-driven justification—that we only support what the data justifies supporting—and efficacy, which means making sure that adding such support does make a difference to Firefox Mobile users.
I assume that list will change over time. This seems like it’s going to generate even more confusion for developers, since you’ll be supporting the -webkit- prefix on some properties and not others. How do you expect developers will keep up with who’s supporting whose prefixes on which properties?
Vendor prefixed properties were never supposed to be something developers could depend on. They were, and are, for experimental implementations and technologies in progress from iterations of CSS working drafts in the process of standardization. I expect developers to keep up with unprefixed properties and the implementations that support them. That’s what developers can depend on.
That doesn’t seem realistic, though. If developers stuck to what they can depend on—the unprefixed properties—we wouldn’t be in this situation.
In fact, developers sticking to what they thought they could depend on is why we are in this situation—some prefixed properties were pitched as dependable and then supported as such without advancing the standards accordingly.
Will Mozilla maintain a list of which prefixes are supported on which properties?
Mozilla will continue documentation of what properties Firefox supports, with any recognized prefixes, on developer.mozilla.org.
Okay, so that’s what you plan to do, but how about why you plan to do it? What’s the goal of your plan?
Mozilla’s goal is to open up the WebKit-specific part of the web to other vendors in the same way that, years ago, Mozilla and Opera had to be practical about what IE-proprietary or IE-only technologies to support. We’ve raised the problem of both a WebKit mobile web monoculture; and also the insufficiency of evangelism to fight it, despite numerous evangelists at Mozilla, Opera, and Microsoft working with web developers to publish standards-based cross-browser content.
With so many evangelizing the right thing, why has it been insufficient?
In the past 10+ years, web standards evangelism has been quite effective, raising awareness and adoption of valid HTML+CSS, progressive enhancement, unobtrusive scripting, microformats, et cetera. However, despite Mozilla’s and others’ evangelism efforts over the past year, the WebKit-specific mobile web is growing faster than we can evangelize, especially in contrast to WebKit-specific evangelism, both implicit and explicit.
I think it is a fair question to ask: what went wrong here, how did we end up with a WebKit mobile web monoculture despite at least some standards evangelism to the contrary? I’m not sure it was any one thing, I think there were several contributing factors that together created the conditions for the emergence and reinforcement of this particular monoculture.
First, the innovations in WebKit helped raise expectations of what was possible on the web platform—which, to be clear, was and still is a very good thing, as advancing the potential of the open web platform is a goal that we all share.
Second, the widespread WebKit adoption in iPhone, Android, and BlackBerry. This should have been a warning sign; that is, when multiple vendors all use a single implementation, there is a high likelihood of a monoculture emerging.
Third, we’ve seen strong evangelism of -webkit- features by Apple and Google, most notably as part of “HTML5” presentations and demo sites. Some of those “HTML5” sites have subsequently been updated with multiple vendor-specific prefixes for experimental CSS features (for more cross-browser demonstrations and coding). However, the implied message of early WebKit-only versions still echoes today.
Fourth, there have also been years of talks in nearly every web design/development conference where speakers, excited to discuss and demonstrate the latest cutting edge, showed sites and code built with -webkit- prefixed properties. This provided implicit, if not explicit, encouragement to target and code primarily or only for WebKit, especially on mobile sites.
Lastly, 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, so that all browser engines could support them without prefixes, including WebKit, and provide web developers a standards-based option they can depend on.
You said you’re doing this for Firefox Mobile users. So this plan is only in your mobile product, and not in the desktop browser?
The UA string for Firefox Mobile is already different than Firefox Desktop, so yes, that part mentioned earlier is specific to the mobile product. As far as implementing particular -webkit- properties, we’re currently weighing the option of supporting them only in mobile, thus limiting exposure, versus providing a consistent Firefox/Gecko platform for web developers that they can depend on.
Since the goal here is to provide a consistent experience for all mobile users, it seems pretty likely you’d eventually decide to provide a consistent experience for all Firefox users, doesn’t it? Thus causing this strategy to spread from mobile to desktop.
The problem we’ve found is specifically with mobile web sites that have been coded for WebKit-only. Since there’s much more browser diversity on the desktop, there’s a lot less WebKit-only coding happening there. This is where the efficacy requirement comes in—if something doesn’t actually help the user, there’s no reason to implement it. So we could implement this across the Firefox platform, but there’s much less of a point to it if doing so doesn’t make the desktop experience better for users. We still have to consider the impact on developers, though, and that might be enough. We may try things in beta builds to get feedback.
Along the same lines, this doesn’t seem like something that will stay limited to a few properties here and there. It seems more like once the door is open, eventually you’ll get to the point of just treating -webkit- as if it were your own prefix. Or even if Mozilla doesn’t, then Opera or Microsoft will do it at some point and subsequently you’ll be forced to follow suit. True, or no?
I think that’s dependent on whether we can open up the WebKit mobile web monoculture or not. History has shown that Mozilla and others succeeded with opening up the IE web monoculture with limited implementation of a few IE-only features such as innerHTML and XMLHttpRequest, both of which have been subsequently standardized with the W3C. There was no blanket implementation of IE-only features in Firefox. Mozilla has a solid track record here of very deliberate and case-by-case pragmatic implementation of features for web compatibility.
But suppose, say, Opera goes ahead and universally supports -webkit- for reasons similar to those when they had their UA string default to Internet Explorer for a while. Wouldn’t that force Mozilla onto the same path? And if not, why not?
If another mobile browser supports -webkit- universally, I don’t see how that impacts the situation, because the dominant mobile browser engine, WebKit, already supports -webkit- universally.
Peter-Paul Koch has said quite forcefully that “there is no WebKit.” You see it differently, obviously.
It doesn’t matter that Peter-Paul Koch says “there is no WebKit”—what matters is that web developers believe and act as if there is a WebKit. They are coding and shipping mobile sites accordingly, by sniffing for WebKit UA strings, and by using only -webkit- properties. That effect is measurable. Denying it doesn’t make it not so.
And by developers doing so, they’re giving a reduced or, in the worst case, broken experience to users of non-WebKit browsers like Mozilla, Opera, and Explorer.
Right. We’re seeing downlevel or “feature-phone” ultra-minimal and reduced functionality experiences being sent by mobile web sites to non-WebKit mobile browsers.
In at least some of those cases, you fully support what they’re doing, except they’ve hidden it behind -webkit- prefixes?
Yes. Current versions of Firefox support -moz- prefixed versions of CSS3 gradients, transforms, animations, et cetera. We’re working actively with the CSS Working Group to rapidly advance the respective specifications and drop vendor prefixes on such stable features. That way we can all help the web platform move forward with standards, rather than handfuls of vendor prefixes.
How often is a site truly broken, though? If a site is different but still functional, that’s kind of what we expect on the web already. It seems like your real objection is that your browser’s rendering is less spiffy, not that users are being locked out. Is this really a threat to the adoption and use of non-WebKit browsers?
They’re often broken. These downlevel mobile sites are different and significantly less functional. 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.
The promise of vendor prefixes was that implementations could be tested in the wild and problems corrected before behavior was formalized. That paid off handsomely with gradient syntax, for example, where totally incompatible syntaxes were tried out, and eventually a unified syntax was found. This plan seems like it imperils that ability—that, once vendors start supporting each others’ prefixes, we may as well drop prefixes altogether. Is that a reasonable conclusion?
Sometimes there’s an expectation in technologies that they’ll be perfect, without any flaws or bumps. Of course, such expectations have no bases in experience so it’s not clear where they come from. CSS vendor prefixes are no different in this regard. They’ve actually been quite successful—many browsers experimented with iterations on various features for years, eventually standardizing what works.
Mozilla, in particular, has an excellent track record of trying things early with a -moz- prefix, and when standardized, shipping a standard, unprefixed property as well as dropping the experimental -moz- prefixed version. There has been pain along the way sometimes, too: for example, how long it took border-radius to get standardized, which it is now. However, the WebKit mobile web monoculture is probably the first time we’ve seen a serious problem with vendor prefixes. Should we give up on vendor prefixes now, despite their imperfect but impressive track record?
There have been calls to replace vendor prefixes with “universal” prefixes, such as -x- or -beta-. What’s your take on that idea?
Experience has shown in other standards efforts that when there is a beta or experimental prefix, like -x-, that everyone does end up supporting them forever in addition to the unprefixed version. For example, check your email headers—you’ll see lots of X-* headers. Or the fact that browsers have to support image/x-png in addition to image/png for PNG images.
On the contrary, with CSS vendor prefixes, Mozilla has shown it is possible to drop -moz- prefixed properties and move the web forward. I believe at least one other browser vendor has been able to eventually drop their vendor prefixed properties after they’ve shipped the standard unprefixed versions.
Why couldn’t “universal” prefixes be dropped the same way vendor prefixes have been? What’s the difference?
Universal prefixes become seen as dependable across browsers, and thus the network effects reinforcing their use and support are stronger—perhaps strong enough to require supporting them indefinitely for compatibility, like the aforementioned X-* mail headers and content types.
There is a similar risk when multiple browsers support -webkit- prefixed properties. This risk could be mitigated and perhaps even overcome if multiple browsers support the equivalent unprefixed properties, and we encourage web developers to instead use those moving forward. However, that won’t fix the WebKit-specific mobile sites that have already shipped.
So this is focused on fixing the problem now, at risk of creating a similar problem in the future. Aren’t you just deferring the pain?
It’s certainly a complex problem with many variables and many actors. The combination of patching past problems and enabling a dependable path for future development provides a good balance of helping users and developers. We’re basing our approach on study and collecting data, and expect to evolve and iterate it as such.
No approach is without risk, but doing nothing at all, or pretending there is no problem, is riskiest of all because it merely lets the WebKit mobile web monoculture worsen. The last time we had a web monoculture, it set the open web back for years.
Daniel Glazman, co-chair of the CSS Working Group, put out a call for action in response to your plan. Do you have any suggestions for what we can do to improve the situation?
As web developers, there are few key things we can do.
First, stop doing “WebKit”-specific UA-sniffing and content-serving, especially on mobile.
Second, stop only using -webkit- prefixed properties, and either use the unprefixed property where it’s standardized or “stable” per the Working Group; or, if it isn’t stable, use every vendor’s prefixed property where they’ve announced or shipped support.
Third, help evangelize corrections for any sites you see which are doing WebKit-specific UA-sniffing and/or only using -webkit- prefixed properties. Similarly, help evangelize corrections for any webdev sites which are promoting, even implicitly, the use of WebKit UA-sniffing and/or use of only -webkit- prefixed properties.
Most importantly, set a good example. Use web standards first and foremost in your sites, articles, and talks. When discussing or demoing experimental features or standards-in-progress, whether in one browser or many, be up front with warnings, and make it clear what’s shiny today may break tomorrow.
No seriously, no one.
They don’t pull the right hand edge about either changing the width.
“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.
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.
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.
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.
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”…
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.
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”:http://tantek.com/CSS/Examples/boxmodelhack.html due to IE’s “different” method of interpreting the box model?
Or am I missing something?
“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?
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.
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).
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).
@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.
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.
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.
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.
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.
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.
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.
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?
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.
@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.
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”:http://www.sminfosoft.com
“Technology News”:http://update-technologynews.blogspot.in/
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.
cone crusher http://www.xiazhouchina.com/2011/0910/7.html
Jaw Crusher http://www.xiazhouchina.com/2011/0910/2.html
mobile crusher http://www.xz-crusher.com/2011/1207/17.html
Jaw Crusher http://www.xiazhou2.com/2011/1118/211.html
Impact Crusher http://www.xiazhouchina.com/2011/0910/3.html
stone crusher http://www.xiazhouchina.com/2011/0916/22.html
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?
I have read this article and it is Very helpful