Microsoft Complains That WebKit Breaks Web Standards 373
Billly Gates writes "In a bizarre, yet funny and ironic move, Microsoft warned web developers that using WebKit stagnates open standards and innovation on the Web. According to the call to action in its Windows Phone Developer Blog, Microsoft is especially concerned about the mobile market, where many mobile sites only work with Android or iOS with WebKit-specific extensions. Their examples include W3C code such as radius-border, which is being written as -WebKit-radius-border instead on websites. In the mobile market WebKit has a 90% marketshare, while website masters feel it is not worth the development effort to test against browsers such as IE. Microsoft's solution to the problem of course is to use IE 10 for standard compliance and not use the proprietary (yet open source) WebKit."
I have an idea... (Score:4, Interesting)
Why don't they use webkit themselves? Then they can spend their time, money, and energy on putting their crappy microsoft experience on top of it?
Sorry... using logic again.
Re:Microsoft is right (Score:5, Interesting)
For all of our very valid gripes about IE breaking standards back in the day, their proprietary tags did not directly lead to a stagnation of innovation (the stagnation came from their overwhelming market share), which is what Microsoft has claimed here. Standards weren't moving fast enough, and the back-and-forth between IE and Netscape in the early days led to a lot of innovation and forward movement. The standards just had to catch up afterwards, but it really was better for everyone that the standards were dragged forward, rather than being allowed to hold up progress.
A similar issue is at play here today. The standards aren't moving fast enough to adapt to the growing needs of web developers, so browser developers are being forced to put in ways to do those things as they work together to create a standard. But as most of us who have used -webkit- prefixed CSS know, the prefixed attributes should be treated as betas, since they are designed to be obsolesced after a standard implementation of that feature exists. That's why any developer worth their salt who wanted to use these features has been writing code like...
-webkit-border-radius: 4px;
-moz-border-radius: 4px;
-o-border-radius: 4px;
border-radius: 4px;
...for the last few years, such that they could enjoy the border-radius feature immediately in the browsers where it was available, but their code would gracefully upgrade to newer browsers that implemented the standard version later (quick note: I intentionally chose a simple example, but there are more complicated examples where not all of them would use "4px" or whatever, but that doesn't change the point).
Microsoft is complaining about the lazy developers who only ever wrote -webkit-prefixed code, or else they're complaining about the fact that they never got around to implementing a stand-in feature like this in the meantime, meaning that it's only with their most recent versions that they're finally starting to support features that have been in the other major browsers for a number of years.
Re:Microsoft is right (Score:2, Interesting)
Developers are only developing sites for Webkit.
Bullshit. What we are doing is making use of the webkit extensions and then gracefully degrading for IE. Like we have always done. Webkit is huge in mobile but not on the desktop so there is no way we are only developing for it. That's the stupidest thing I've read all day. The system is working correctly as is and MS are just running their mouths to be doing it. Fucking hypocrites with idiots like you believing their shit.
Not sure if this is a problem (Score:5, Interesting)
The funny thing is that MS pushed this type of non standard HTML by convincing web developers that it was more important to HTML to create consistant application interfaces rather than flexible content delivery and sales interface technology. So they pushed the idea of fixed screen sizes, fixed elements, and the like that only IE could, at the time, deliver. CSS and HTML5 depreciated the IE technology, but the damage was done. A generation of web developers were trained to look at web pages as fixed entities, not flexible markups. Even today I have to use some web pages that will only on IE because MS has convinced the MBAs that this is the most efficient way to do things.
So now we are at a place where Webkit and Gecko rule the world. Designers are writing web pages to work well on Chrome, Firefox, and Android, which fortunately for apple will make it work on Mac and iOS as well. MS, being the entitled rich kid, is whining that consumers are ignoring IE. Of course IE is being ignored. It is doesn't run on anything that consumers choose to use. The only people who use IE are corporate types that are forced to use IE. If I have a new social app, am I going to cate that it does not run on IE. No, I am going to care that it does not run Android. If MS wants it to run on IE, they have the resources to add the functionality to IE. Otherwise who cares?
Don't blame the browsers (Score:4, Interesting)
I wish people would stop offering the "well Microsoft used to do this so who are they to complain" excuse. Not only is the internet a different place, but so is Microsoft. They tried very hard to become as standards-compliant as they are now, and it took the risk of breaking existing websites along the way, despite the compatibility mode they offered. But the fact is, they made that decision. I still don't care about using IE, but I still give credit where credit is due.
Where the problem lies is mostly with the W3C. This is who we should be blaming. This is 2012, and all that ever happens with these people is bickering and squabbling, while the web still stagnates with a technology level of five years ago, and couldn't even decide on a standard for something as basic as rounded corners. This is the Achilles' Heel of the free software world, where everything is treated far too much as a democracy, so every nerd with an over-inflated ego has an idea for how something should be done and they're absolutely certain that theirs is the best way to do it. It not only results in the dozens and dozens of forks of major pieces of software in the free software community, but also results in any kind of standards decisions being delayed for literally years while everyone acts like babies instead of ratifying something already.
I can remember almost ten years ago when I was developing a very graphics-oriented website, and part of what I was being asked to do was to rotate a section of the page by 90 degrees. Except the content on this area was dynamic, containing an avatar and the user's name and stuff. There was no web standard for doing something like this at all, and my only option was going to be using Flash. But since Flash was prone to not line up perfectly among every browser (and I needed pixel-perfect alignment), not to mention was overkill for what I needed, even that was a problem. So eventually, after looking at our statistics, a good 98+% of the users used IE. The rest was Opera or Safari. So I made the decision to implement IE's proprietary DirectX filter extension, which allowed rotation of any HTML object in the page, and would apply this to any content normally inside of this object as well. The resulting effect was excellent.
Over time, I wasn't entirely satisfied with this single-browser solution (which had something to do with the fact that I'd switched to Opera myself!). But web technology still never caught up. So my way around this was to generate this section of the website on the server itself, using Perl and the GD library. I cached the resulting image for every user, only regenerating it when they changed their icon or any of their information. I was able to recreate the original DirectX filter version with 99% accuracy this way. But this was all only because our web host had been kind enough to install GD for me to begin with, since this was before we were running our own server.
The point of this story is, the ability to rotate components in a DOM tree has only recently become possible in HTML5. And HTML5 is still unfinished! Expect to see plenty more browser-dependent extensions over the decade, just like what happened last decade, all because the organization we rely on to give us these standards is dragging its heels and arguing every detail along the way.
Re:Microsoft is right (Score:5, Interesting)
Let's also remind ourselves how Microsoft continues to hurt itself. It continues to have the web browser integrated with its OS and UI.
Here's a similar complaint I have about GNOME.
Many here love and use GNOME2 because GNOME3 with its GNOME Shell just draws anger and rage from users. In order to stay with GNOME2, I elected to go with CentOS because it is stable and mature. But that's when I was faced with a huge problem with GNOME that I couldn't believe. The utter stupidity and betrayal I felt when I came to realize what happened made me lose what little respect for GNOME developers I had at the time. "What's he talking about?!" This:
GNOME2 on CentOS 6.3 cannot run GiMP 2.8.x or above. Why not? Well, it turns out that GTK (Gimp toolkit) was used as part of GNOME2's dependencies. So no matter what a person does to compiled and reconfigure GiMP, he will never get a good user experience under GiMP while using CentOS 6.x. And the fault lies with GNOME2. The application toolkit which was put together and maintained by another project (GIMP in this case) was being used to support a desktop user interface. This means the desktop environment can only support GNOME apps which are 'compatible' with its selection of GTK libraries. This, of course, doesn't happen under Windows or other DEs under Linux or under Mac OS X. Thank you SO frikken much GNOME developers for your little timebomb that was GNOME2. You shat in the corner of the room and moved away to develop GNOME3. People moved away from GNOME3 only to find that they just stepped in the GNOME2 turd you left behind.
Okay, so what does that have to do with Microsoft and HTML and all that? Well, it turns out that by integrating an application (and all its dependent libraries) in the with desktop environment, they have blurred the lines between OS and Application even further and they maintain this behavior even with their new OSes. Why? Well, it served them well in the past though they knew it was anticompetitive. But when they are starting out at the bottom, they need to realize they aren't doing themselves any favors. They need to pull the browser out of the OS to enable people to use multiple versions of Microsoft's own browsers.
The rule which I don't think has ever been stated, where OS and User Interface development is concerned is "DO NOT USE APPLICATIONS LIBRARIES IN YOUR USER INTERFACE CODE!!!" This inherently limits the applications which can run in your OS/UI. The two ways to fix the CentOS/GNOME2 problem is for GiMP to change their code or for CentOS (and Redhat) to update their GNOME2. Neither party is interested in this large task and even if they did, the problem is the same. Microsoft can update their browsers all day long but the problem remains the same so long as you can only have one.
Re:Microsoft is right (Score:5, Interesting)
And nothing says that Microsoft can't translate -webkit- specific prefixes in a compatible manner. Just because it's -webkit-something doesn't mean only Webkit is allowed to use it, but rather that it should be compatible with the Webkit implementation.
A lot of these -webkit- prefixes exist because these are CSS 2 or CSS 3 properties that predated finalization of these standards, and most of them are largely compatible with the final standard if the prefix is removed. Webkit was complying with standards by adding features not yet finalized and prefixing them so there would be no conflict with the final standard. MS is essentially upset that Webkit's presence is sufficiently strong that developers for the first time in many years, don't feel the need to test against Microsoft's platform.
Re:Microsoft is right (Score:0, Interesting)
Also if they want us to test against IE10 an IE10 mobile they need to provide it for Linux and OSX. I'm not going to get a Windows tablet just for testing.
Besides prefixing indicates unsupported/changing features. Prefixes aren't supposed to be permenant features.
http://leaverou.github.com/prefixfree/ - Fixed. (Score:3, Interesting)
http://leaverou.github.com/prefixfree/
Break free from CSS prefix hell!
Only 2KB gzipped
-prefix-free lets you use only unprefixed CSS properties everywhere. It works behind the scenes, adding the current browser’s prefix to any CSS code, only when it’s needed.
Re:Glacial pace (Score:4, Interesting)
The W3C has few resources of its own; the pace of the W3C is largely a function of the efforts of its contributors, who for CSS are mostly browser vendors. In fact, the main reason CSS transitions, animations and transforms progressed very slowly was because the editors of those specs, Apple employees, did not work on them. One of them writes here:
http://lists.w3.org/Archives/Public/www-style/2012Feb/0356.html [w3.org]
"Despite having billions in the bank, we don't have the luxury of full-time W3C editors like Hixie and Tab."
I.e., Apple chose not to invest in standardizing their inventions.
There are other cases, for example -webkit-text-size-adjust, where Apple has shown no interested in standardizing the property at all.
It was a good thing to introduce innovative -webkit-prefixed features. It was a bad thing to not prioritize their standardization.
Note that for various reasons, policy consensus is shifting towards the view that we should try to ship experimental features unprefixed but disabled by default, so Web developers can experiment with them but not use them in production sites. This creates pressure for every vendor to assist in standardization --- a very good thing.