Some interesting twittering earlier today on the subject of Apple actually being worse than Microsoft for the Open Web. Seems like quite a provocative statement to me, and a concept worth discussing.
Some background: Apple is heavily involved in the W3C and WHATWG, where they help define specifications. They are also well-known for implementing many unofficial CSS extensions, which are subsequently submitted for standardization. However, Apple is also known for preventing its representatives from participating in panels such as the annual Browser Wars panels at SXSW, which expresses a much less cooperative position.
The issue I’m most interested in is the way Apple seems to want to get ahead of the game by implementing methods of doing things with CSS that were not possible before. One might say Apple should make the propositions first, see how a proposal does in discussion with the W3C, and only then come up with an implementation.
The rush to add so many bells and whistles (some of questionable value) without discussion, can be seen as a marketing ploy to make claims of being the first browser to support many new technologies, without disclaiming the fact that they were not the result of discussion with other parties. And this is exactly what has happened.
Marketing claims aside, is there anything wrong with the concept of shipping a browser with non-standard methods of doing things that weren’t possible to before? We all remember how the initial browser wars had Microsoft and Netscape release proprietary methods of doing just that. This was rightly seen as a Bad Thing for the web, since web designers had to either choose one browser to support or try to figure out which features were or were not okay to support.
There are two big differences between the way features were supported then and the way browsers support them today:
- Before, there was no agreed on method on how to implement vendor-specific features, so browsers just added them as if they were standardized features. Now, we vendor-specific extensions are allowed in CSS
- 2. Before, the features had little or no documentation explaining the way other browsers could implement them the same way. Now they are quite extensively defined
There’s currently no official method of introducing vendor-specific HTML elements (only XHTML). When Webkit began adding the Canvas element, it sparked some debate on the subject, with David Hyatt seeming to try his best to find the best solution.
But aside from adding a feature as “properly” as one can, while getting attempting to get it standardized afterwards, what’s a browser vendor to do?
The only other options I can see are waiting to get something standardized (a process that can take years) or releasing a plugin like Silverlight or Gears that may also serve the purpose. Plugin alternatives don’t usually integrate with web pages as well as native solutions, and aren’t much help for CSS properties.
Is Apple’s method bad for the web? I think not. True, it’s on the hasty side and the marketing claims are annoying, but the method encourages competition and from my observations they try to do things by the book as well as they can. Time will tell if the open web will eventually suffer from the many extensions available already, but I’m optimistic that it can only be a good thing.
5 replies on “Apple’s extensions: Good or bad for the open web?”
@Brad
If the prefixed features are there for testing, why aren’t they available on preview builds only ? Why are they delivered into the (world) wild web publicly ?
The JS libraries are completely different : jQuery is completely cross-browsers compatible. We’re talking about incompatible features that browser vendors introduce here.
AFAIK, Apple don’t provide a JS emulation for their new features… do they ?
I’m not against innovation from browsers at all. But I don’t like when vendors make developers work a hassle. I think Apple is doing it the wrong way.
@Alexis
I agree with you on most.
You write SVG, right ? How many times have you been frustrated by the poor support in firefox or safari ? filters, smil, text selection, use elems, … (i agree it’s going better, at last)
As a developer I write for a spec. Implementers should not try to guess what “common developers” will use. Specs are there for that. If they are not fully implemented, what are they good for ? Apple seems to only care about the famous acid tests. Not about true interoperability. The day they catch up with Opera’s implementations, then i’ll consider their new features more seriously.
Exactly. That’s why I think they are evil. 🙂
Will Apple dare to “break the web” and correct their implementations when the drafts will be modified ? Will they remove the prefixed attributes once they deliver non-prefixed ones ?
I hope so.
Of course. I was talking about interop on the web. Not personal apps.
Repeat after me: standards organizations shouldn’t do innovation. What Apple is doing is _exactly_ the right thing. They are throwing some things out into the market and seeing what developers and users like. That’s good. They are correctly prefixing things with a vendor prefix in their custom CSS. If things turn out to be desired and work out well, they can be standardized by the W3C. We saw exactly the same thing with CSS Selector engines (JQuery, Dojo, etc. experimented in the market first, which then was turned into an actual spec at the W3C that is being baked into newer browsers). Please, let’s all stop the “one-true-way” W3C cargo culting.
@David
Nice rebuttal, and longest reply on my blog so far. 🙂
While that recommendation applies to authors who like to make sure their sites work the same for different browsers, the reality is that many designers like using them to enhance their sites for the browsers that support the latest technologies. In addition, I believe all browser vendors want designers to use them at least to some degree, to see if support needs fixing or adjusting.
So I don’t believe these extensions are inherently evil, they just have the potential to be if people are to depend on them too heavily.
I believe the MSDN documentation is intended only for authors who use the technology, not for other implementers. No MSDN documentation I have seen resembles specifications like the few MS has submitted to the W3. Thus making it very hard for (and indeed discouraging) others to recreate the way these extensions works.
I suspect vendors would tell you that the reason for not implementing all the current recs before coming up with new things is that they do not feel that the amount of work involved is worthwhile for the amount of people that would benefit from it. Microsoft sees little need for XHTML, and most other browsers don’t feel a need to fully support CSS2.1 because most authors prefer to see CSS3 features than 100% perfect rendering of barely-used CSS2.1 properties.
While they differ on what they feel users want to see supported, they all ultimately prefer a pragmatic approach over an idealistic one. Supporting MathML may seem logical and helpful, but unless you’re a mathematician, you’re unlikely to either write MathML or interested in seeing it on web pages. Whether or not it’s a W3C recommendation, makes little difference in this regard.
On the other hand, supporting new visual-oriented CSS features is often quite easy to do, and most designers are quite happy to receive them. And generally speaking they degrade well in browsers without support.
(fixed the WCIU “statuses” issue, btw, thanks for noticing that)
Indeed, so do I. But many, or indeed most features we use today started out buggy and unpredictable among browsers one way or another. They have to be implemented for the bugs to become apparent. Often an experimental implementation is better than no available solution at all. If it’s not, just don’t use it until it is more stable.
I certainly agree that we need a proper layout solution in CSS. Considering the amount of work required for browsers to implement a new layout system, they’ve been more hesitant to experiment with this. I think another reason for the delay in this is because it would probably be hard to come up with a method that would still make a page look acceptable in browsers without support.
As mentioned, they may be interoperable today, but once standardized and supported among other browsers this issue will go away.
From my perspective, I like to write apps on my iPod in a language I’m familiar with, and Apple gives me the tools to do things either a little easier or things that weren’t possible before. I just have a hard time understanding the problems with offering those tools in a way that is not incompatible with future solutions, and that explains in detail how other can recreate them.
Oh, it’s also worth mentioning that since Webkit is open source, other implementers can see exactly the kind of code used to recreate the features, in addition to reading the specs. That’s another thing Microsoft can’t say.
When people write safari/iphone-only apps that don’t work at all on other platforms, then they should be blamed for that, not Apple. Most of these are likely to just be games and demos, though, hardly things that close off the web to people.
I totally agree with ppk on this.
About your big differences :
1. The fact that vendor-specific extensions are “allowed” now is only a mechanism to avoid name clashes. That’s all. The prefixes makes no other difference. They are equally evil. W3c says “Authors should avoid vendor-specific extensions”. But Apple promotes theirs.
2. MS extensions have always been well documented in msdn. What other vendors had to reverse-engineer are mainly the quirks, bugs and error handlings.
You claim that Apple’s extensions are “methods of doing things with CSS that were not possible before”. It’s not true. Technologies already existed. Let’s see some of them :
Canvas : SVG, Flash, …
rounded corners : css images, SVG, …
web fonts : css images
css animations : SMIL, javascript libs, …
Don’t take me wrong. I’m not saying these features are useless, nor that the alternatives are standard, better nor elegant. I say they should bother to implement current recommendations (full CSS2.1, full SVG 1.1, projection media type, MathML,… ) before new technologies. Because we developers want interop first. CSS is not versioned for nothing.
And some of these extensions are CSS only. It means it doesn’t add functionality, only style. (or at least that was the intent of CSS) They are just eyes catching sugar for sighted people.
You say “plugin alternatives don’t usually integrate with web pages”. But as a developer, do you prefer to use many unstable, subtly different prefixed properties, one for each vendors ? As a developer, I want one interoperable easy-to-maintain technology for a feature. Apple IS bringing back the horror of browser war, that will bring more UA sniffing and hacks.
And finally (and that’s a personal criticism toward all vendors), things that are cruelly lacking in CSS are neglected. If they want to implement CSS3, please begin with advanced layout and columns. Everyone is begging for that. Hacks for animations is one line of js with jQuery. Hacks for rounded corners or fonts may be ugly but at least interoperable. Hacks to acheive a given layout are so ugly, an interop nightmare and so difficult to maintain. my 2 cents about priorities.
Compare standards support with not (yet) standard support
Safari is indeed the first on non standards. But look where they are on the standards side. far behind. Where’s their haste ?
(btw, these urls don’t seem to take the statuses param correctly)
We all know that Apple has that closed and expensive little toy and they hope people will write more “safari/iphone-only” web apps. (because people WILL use css animations for behavior instead of pure presentational for example).
That has always been MS’s strategy as the dominant vendor. And despite the very bad reputation of IE, it is still the boss on desktops.
Apple is even worst because it can advertise well. It can makes itself shine.
They are so good at marketing that they can make you write that non interoperable features is a good thing !! 🙂
Apparently, Chaals talked about all that in austin. I wished it’ll be published.
cheers
As long as they are ready to drop support (on safari’s next version) for the extensions that don’t make it into a standard (true, not de facto) I have nothing against their hastiness.