WebKit Isn’t Breaking the Web. You Are
webmonkey.com
webmonkey.com
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 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.
[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.
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.
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.
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.
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.
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.
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.
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.)
And browser vendors will ship proprietary extensions, whether you like it or not.
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.
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.
The success of an engine lauded for its cleanliness and conciseness and architecture (khtml) over the sprawling mess of engines that preceded it.
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.
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.)
That's why "the rush".