Pre-fix the web: Webkit-only solutions hurts the open web(codepo8.github.com)
codepo8.github.com
Pre-fix the web: Webkit-only solutions hurts the open web
http://codepo8.github.com/prefix-the-web/
12 comments
Prefixing just did not work. We should push the standards bodies to drop that nonsense ASAP.
Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution, and in fact circumvents the original purpose of prefixing--you're assuming that all vendors implement the feature identically, in which case why prefix at all?
In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it.
Prefixing isn't a function of the standards bodies, it's a function of browsers that want to implement stuff without worrying about peoples' experiments doing something stupid when the standards body picks the same property name but with different semantics.
edit: here's a scary thought, what if standards bodies picked Microsoft's version of CSS Transforms back in the '90s:
Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution, and in fact circumvents the original purpose of prefixing--you're assuming that all vendors implement the feature identically, in which case why prefix at all?
In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it.
Prefixing isn't a function of the standards bodies, it's a function of browsers that want to implement stuff without worrying about peoples' experiments doing something stupid when the standards body picks the same property name but with different semantics.
edit: here's a scary thought, what if standards bodies picked Microsoft's version of CSS Transforms back in the '90s:
#myObject {
filter: progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand',
M11=1.5320888862379554, M12=-1.2855752193730787,
M21=1.2855752193730796, M22=1.5320888862379558);
}"In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it."
Maybe the right thing to do here is make the prefix optional. That is, let webkit/gecko/ie/etc recognize -webkit/-moz/-ms/-etc prefixes just in case you need to invoke a rule differently for a special snowflake case, but let the non-prefixed rule work when a prefixed rule hasn't been specified.
Maybe the right thing to do here is make the prefix optional. That is, let webkit/gecko/ie/etc recognize -webkit/-moz/-ms/-etc prefixes just in case you need to invoke a rule differently for a special snowflake case, but let the non-prefixed rule work when a prefixed rule hasn't been specified.
That makes it difficult to provide progressive enhancement though. If I use a prefixed property, I have the ability to make sure it works fine without it, and I can assume that in the future, if the semantics of it change when it becomes non-prefixed, it'll either disappear (i.e. if it was a -webkit property being rendered on firefox) or still work (i.e. if it was a -o property being rendered on opera).
If I use an experimental non-prefixed property, how do I make sure future browsers that might implement it differently render it usably?
If I use an experimental non-prefixed property, how do I make sure future browsers that might implement it differently render it usably?
If we allowed the W3C to become a bottleneck like you propose rather than a seal of approval like it is in practice, we wouldn't have CSS transitions in any browser this decade, we wouldn't have AJAX, we wouldn't have canvas, etc. It would be really nice if things could work the way you want, but history has shown time and again that if progress in Web standards is going to proceed at a reasonable pace, it is almost always implemented as a proof-of-concept and then standardized once its utility is recognized. This back-and-forth between shipping code and the standards bodies has evolved as part of the process.
And contrary to your claim that prefixes are just applied blindly, some CSS features have indeed been implemented differently by different browsers — gradients and the flexible box model, to name just a couple. Prefixing is the only reliable way to get the feature before the W3C actually produces a standard with it 10-15 years down the road (I wish that was hyperbole, but it isn't — just look at how long they plugged away at XHTML 2 with no end in sight before everybody got tired of waiting and started implementing HTML5). The point of prefixes is to ensure that the W3C are never faced with a choice between standardizing a CSS feature against their will and breaking the Web.
Although I don't like the bloat from an ideological standpoint, in practice this is the best way we've come up with. But to make reading, writing and maintenance easier, I generally like using a CSS metalanguage with a library like SASS+Compass or Stylus+Nib. That way, you can just write, say, "transition: color .5s linear" and it'll get translated into the appropriate cross-browser code.
And contrary to your claim that prefixes are just applied blindly, some CSS features have indeed been implemented differently by different browsers — gradients and the flexible box model, to name just a couple. Prefixing is the only reliable way to get the feature before the W3C actually produces a standard with it 10-15 years down the road (I wish that was hyperbole, but it isn't — just look at how long they plugged away at XHTML 2 with no end in sight before everybody got tired of waiting and started implementing HTML5). The point of prefixes is to ensure that the W3C are never faced with a choice between standardizing a CSS feature against their will and breaking the Web.
Although I don't like the bloat from an ideological standpoint, in practice this is the best way we've come up with. But to make reading, writing and maintenance easier, I generally like using a CSS metalanguage with a library like SASS+Compass or Stylus+Nib. That way, you can just write, say, "transition: color .5s linear" and it'll get translated into the appropriate cross-browser code.
Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution
A lot of the new CSS stuff doesn't require the vendor prefixes, since those vendors now support the prefix-less version. So you don't need to go "-webkit-border-radius: … -moz-border-radius: …", instead do "border-radius: …". We're at the stage where we need less CSS declarations.
The problem is that some sites only have "-webkit-border-radius:…". They should just drop the "-webkit-".
A lot of the new CSS stuff doesn't require the vendor prefixes, since those vendors now support the prefix-less version. So you don't need to go "-webkit-border-radius: … -moz-border-radius: …", instead do "border-radius: …". We're at the stage where we need less CSS declarations.
The problem is that some sites only have "-webkit-border-radius:…". They should just drop the "-webkit-".
"A lot" isn't really true, here is some quantification:
https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility
Long-standing ones like border-radius are unprefixed but most of the recent ones like transition are not.
And the overhanging problem for non-Webkit vendors is that all that legacy content out there prefixed with -webkit- isn't likely to be fixed until their next design iteration, if ever.
https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility
Long-standing ones like border-radius are unprefixed but most of the recent ones like transition are not.
And the overhanging problem for non-Webkit vendors is that all that legacy content out there prefixed with -webkit- isn't likely to be fixed until their next design iteration, if ever.
It's a problem only in that other vendors want the sites to work with their browser. For really popular sites Mozilla hardcodes workarounds, it's very unfortunate. There's a fine line between sticking to spec and bad user experience so sometimes the vendors are forced to do things they'd prefer not to.
From my perspective the market should work things out. If a transition doesn't work in Firefox, those users will complain and the developers will fix it; or they won't and people will stop using the services.
We are to blame on HN because we upvote blog posts when someone releases a css3 flower that only renders in webkit. We are encouraging the behavior, and ultimately it's users that suffer.
From my perspective the market should work things out. If a transition doesn't work in Firefox, those users will complain and the developers will fix it; or they won't and people will stop using the services.
We are to blame on HN because we upvote blog posts when someone releases a css3 flower that only renders in webkit. We are encouraging the behavior, and ultimately it's users that suffer.
Do you have links to those workarounds? As far as I know Mozilla is the only major browser (out of IE, Chrome, Opera, and Safari) that doesn't have site specific hacks/workarounds.
You only need to use prefixes on experimental not-yet-standard features. When the feature is standardized the prefixes are dropped.
If you want to only support standardized features then only support standardized features. That's a decision for individual developers to make. What you are proposing is to strip developers of the ability to test out non-standard features.
If you want to only support standardized features then only support standardized features. That's a decision for individual developers to make. What you are proposing is to strip developers of the ability to test out non-standard features.
> When the feature is standardized the prefixes are dropped.
More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that.
> What you are proposing is to strip developers of the ability to test out non-standard features.
If it's only the developers we're inconveniencing, then sure let's have the W3C dictate that prefixed features are available in preview/beta/canary builds but disabled in builds intended for non-developer release. That would create some healthy pressure to get things standardized quickly, eh?
> If you want to only support standardized features then only support standardized features.
Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.
More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that.
> What you are proposing is to strip developers of the ability to test out non-standard features.
If it's only the developers we're inconveniencing, then sure let's have the W3C dictate that prefixed features are available in preview/beta/canary builds but disabled in builds intended for non-developer release. That would create some healthy pressure to get things standardized quickly, eh?
> If you want to only support standardized features then only support standardized features.
Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.
> More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that.
I think you're misattributing malice here. This isn't a WebKit only issue, this is a first-to-market issue. When some new css or js feature is proposed and vendors implement it with the prefix, some developers rush to hack on it, submit their demos to HN, and then forget about it weeks later. They don't bother to go back and update the css later with other prefixes.
The same issue exists when WebKit isn't the first to market. WebKit doesn't support calc() yet. Mozilla does. Plenty of abandoned webpages will never be updated with other prefixes. But are these serious websites/businesses? Is Facebook or Twitter sticking in -webkit and never bothering to go back?
>Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.
Legacy content would still be broken because sparkle will likely be changed in the process of standardization. IndexedDB has seen some dramatic changes in the course of its development; all those sites that implemented an earlier version will be broken when the standard is finalized. The vendor prefix sends a warning to the developers.
Browser sniffing is a far bigger problem than vendor prefixes. Google is one of the worst offenders, especially in mobile where they send UAs not equal to iOS or Android to some poorer version.
I think you're misattributing malice here. This isn't a WebKit only issue, this is a first-to-market issue. When some new css or js feature is proposed and vendors implement it with the prefix, some developers rush to hack on it, submit their demos to HN, and then forget about it weeks later. They don't bother to go back and update the css later with other prefixes.
The same issue exists when WebKit isn't the first to market. WebKit doesn't support calc() yet. Mozilla does. Plenty of abandoned webpages will never be updated with other prefixes. But are these serious websites/businesses? Is Facebook or Twitter sticking in -webkit and never bothering to go back?
>Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.
Legacy content would still be broken because sparkle will likely be changed in the process of standardization. IndexedDB has seen some dramatic changes in the course of its development; all those sites that implemented an earlier version will be broken when the standard is finalized. The vendor prefix sends a warning to the developers.
Browser sniffing is a far bigger problem than vendor prefixes. Google is one of the worst offenders, especially in mobile where they send UAs not equal to iOS or Android to some poorer version.
Agreed. I'm concerned that this backlash will also slow the adoption of CSS3 features back to the glacial pace we saw with CSS2.x
>Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution
No, it's not, but it isn't going away. Designers and Web Developers want to do more than current standards (and browser implementations) allow for.
No, it's not, but it isn't going away. Designers and Web Developers want to do more than current standards (and browser implementations) allow for.
The alternative – no prefixes – is even more horrible. That would be chaos and disaster.
Webkit’s might is the problem here. Dropping prefixes without having some alternative solution in place is definitely not the solution. That’s why it’s a hard problem.
Webkit’s might is the problem here. Dropping prefixes without having some alternative solution in place is definitely not the solution. That’s why it’s a hard problem.
Internet Explorer 6 was released in 2001. I realize this is not central to the article, but "A lot of products were made in the end 90s that only worked in Internet Explorer 6" bothered me. Perhaps it simply made me feel old, but I'd like to think its some sort of noble sense of historical correctness.
One way to quickly find code that uses -webkit- only CSS properties is to use the GitHub's code search with queries like: language: css +"-webkit-" -"-moz-".
Can't we just convince devs to not use prefixed code? That stuff is experimental, it is guaranteed to break in the future. I know it's hard, but wait for the standard to be standardized, or realize that every time you type "-webkit-" you're making a commitment to fixing your site at some point in the future.
I don't understand the argument against having to revisit the site and fix it in the future.
Web design takes place from the standpoint of what is possible to accomplish with the most-supported features. From that starting point, vendor prefixes only allow developers to improve their product for users of more modern browsers, and in doing so, place a vote of support for the rapid completion of the prefixed feature.
If you decline to use "-webkit-", you put your website at a disadvantage compared to others that do use the prefix, and you still have to return to the site at some point in the future in order to implement the feature once it's widely supported.
I suppose there's an argument to be made for saving a little bit of hassle in the present time, but that's highly situational and since CSS is so easy I don't think it holds muster.
Web design takes place from the standpoint of what is possible to accomplish with the most-supported features. From that starting point, vendor prefixes only allow developers to improve their product for users of more modern browsers, and in doing so, place a vote of support for the rapid completion of the prefixed feature.
If you decline to use "-webkit-", you put your website at a disadvantage compared to others that do use the prefix, and you still have to return to the site at some point in the future in order to implement the feature once it's widely supported.
I suppose there's an argument to be made for saving a little bit of hassle in the present time, but that's highly situational and since CSS is so easy I don't think it holds muster.
OK, so it breaks and my corners go back to not being properly rounded. I can live with that.
Except it's not guaranteed to break, because vendors aren't consistent about dropping prefixes.
the comparison between IE6 and Webkit is unfair: Webkit is completely open-source and under active development, whereas IE6 was propriety and dead.
as a pragmatist I don't see it as an bad thing if Webkit becomes close to 100% of the browser market...
as a pragmatist I don't see it as an bad thing if Webkit becomes close to 100% of the browser market...
Because, hey, monopoly and monoculture, what could possibly go wrong?
If Webkit's codebase defines the "standard" then the decision-making process is no longer open, even if the source code (eventually) is. It is controlled by a small number of people, primarily at Google and Apple, who have their existing products and product plans to consider when adding features and changing behavior.
Think about what that means if you are trying to compete with those two. Forget trying to create a competing code base, they control like 90% of the existing mobile web. But even if you adopt Webkit you're at a huge disadvantage because they're months ahead--you can't just fork the code and go your own way, you also have to adopt whatever they include later because it's the standard.
If Webkit's codebase defines the "standard" then the decision-making process is no longer open, even if the source code (eventually) is. It is controlled by a small number of people, primarily at Google and Apple, who have their existing products and product plans to consider when adding features and changing behavior.
Think about what that means if you are trying to compete with those two. Forget trying to create a competing code base, they control like 90% of the existing mobile web. But even if you adopt Webkit you're at a huge disadvantage because they're months ahead--you can't just fork the code and go your own way, you also have to adopt whatever they include later because it's the standard.
as a pragmatist, I really don't care.
the W3C is completely ineffective.
I kinda wish Gecko and Trident would die, as it would make my life a lot easier (no more silly compatibility libraries, testing in 5 different engines, etc).
what's stopping Mozilla from forking Webkit? remember that Webkit itself was a fork of KHTML...
the W3C is completely ineffective.
I kinda wish Gecko and Trident would die, as it would make my life a lot easier (no more silly compatibility libraries, testing in 5 different engines, etc).
what's stopping Mozilla from forking Webkit? remember that Webkit itself was a fork of KHTML...
Well, WebKit is nice and all. At some point, it was not WebKit, but Gecko that was the shit. Then early WebKit authors made something that was easier to embed and had a license that was friendlier to corporate entities. Apple and Google flocked to it, and improved it even more.
They could do this because they had a standard to work from. They didn't have to source-reverse-engineer Gecko, because they could work from that standard, that described how things worked. They didn't have to fork Gecko (nor would they have wanted to because of the licensing), because they didn't need to do things exactly the same way even where it made no sense. This standard came to be because earlier browser vendors (including Microsoft/IE and Mozilla/Gecko) understood that things would be a mess if they didn't cooperate. They'd been there, and done that.
If you're now proposing to drop the actual standardization process and define the Internet as "whatever WebKit renders", be aware that you're just killing what made WebKit possible in the first place. You could fork WebKit, but you'd still have to emulate it close enough to be bug-for-bug compatible. That's not a way to get a real improvement or independent implementation.
And it wasn't how WebKit came to be, either.
For the companies that are heavily invested in WebKit (Apple, Google), it's a wet dream: it ensures they can never be eclipsed by something even better. Imagine if we had done that for Gecko (it's open source too, after all!): Mozilla could have sat on their asses and wouldn't even really have to have cared about improving it. Luckily people competed with rendering engines, so both WebKit and Gecko keep improving rapidly. And so do IE and Opera.
I can make similar analogies for things like C++, GCC and LLVM. Even if the implementations are open source, having a standard that allows independent ones is tremendously important to prevent stagnation.
I'm not ready to allow C++ to be redefined as "whatever GCC compiles" any more than I am ready to allow the Internet to be redefined as "whatever WebKit renders". Even though yes, this does mean more work keeping things compatible for me as a C++ programmer.
They could do this because they had a standard to work from. They didn't have to source-reverse-engineer Gecko, because they could work from that standard, that described how things worked. They didn't have to fork Gecko (nor would they have wanted to because of the licensing), because they didn't need to do things exactly the same way even where it made no sense. This standard came to be because earlier browser vendors (including Microsoft/IE and Mozilla/Gecko) understood that things would be a mess if they didn't cooperate. They'd been there, and done that.
If you're now proposing to drop the actual standardization process and define the Internet as "whatever WebKit renders", be aware that you're just killing what made WebKit possible in the first place. You could fork WebKit, but you'd still have to emulate it close enough to be bug-for-bug compatible. That's not a way to get a real improvement or independent implementation.
And it wasn't how WebKit came to be, either.
For the companies that are heavily invested in WebKit (Apple, Google), it's a wet dream: it ensures they can never be eclipsed by something even better. Imagine if we had done that for Gecko (it's open source too, after all!): Mozilla could have sat on their asses and wouldn't even really have to have cared about improving it. Luckily people competed with rendering engines, so both WebKit and Gecko keep improving rapidly. And so do IE and Opera.
I can make similar analogies for things like C++, GCC and LLVM. Even if the implementations are open source, having a standard that allows independent ones is tremendously important to prevent stagnation.
I'm not ready to allow C++ to be redefined as "whatever GCC compiles" any more than I am ready to allow the Internet to be redefined as "whatever WebKit renders". Even though yes, this does mean more work keeping things compatible for me as a C++ programmer.
KHTML is as old as Gecko, and Webkit and Gecko are both LGPL.
the killer feature back in the early 2000's was the ability to render most of the pages on the Internet as IE did, so saying that the engines were the product of standards is categorically wrong.
the lack of adoption of Gecko outside of Mozilla is more to do with the fact the source code is a mess, whereas Webkit is very clean and tidy, and as a result very easy to hack on (years ago I wanted to embed Gecko in a project, and ended up using Webkit as it was actually possible to modify...).
the killer feature back in the early 2000's was the ability to render most of the pages on the Internet as IE did, so saying that the engines were the product of standards is categorically wrong.
the lack of adoption of Gecko outside of Mozilla is more to do with the fact the source code is a mess, whereas Webkit is very clean and tidy, and as a result very easy to hack on (years ago I wanted to embed Gecko in a project, and ended up using Webkit as it was actually possible to modify...).
The remarkable thing about Firefox is not how much it compromised on implementing IE-specific features, but rather how much market share it gained in spite of the fact that it didn't compromise on implementing IE-specific features. To name a few off the top of my head: ActiveX, filter:progid:DXImageTransform, CSS "zoom" property, insertAdjacentElement(), etc.
Gecko is now LGPL. Back in 2000 it wasn't.
Having to completely rewrite Firefox for no gain, which would basically destroy Firefox. See Matt Brubeck's answer here: http://www.quora.com/Mozilla-Firefox/Will-Firefox-ever-drop-...
Besides, Gecko is ahead of WebKit in several ways (MathML, Direct2D, etc.); there's no compelling reason to switch.
Besides, Gecko is ahead of WebKit in several ways (MathML, Direct2D, etc.); there's no compelling reason to switch.
On the other hand, there is no one WebKit: http://www.quirksmode.org/webkit.html
IE6 was propriety and dead.
I don't think either propriety vs opensource or dead vs active development are important to the overall question of "is standardizing on a single implementation a bad idea?"
Yes, the fact it had dropped out of active development made it worse to standardize on, but it was already a bad idea.
The same goes for open source. Yes, it can be forked to get away from something bad, but if only one browser/engine becomes standardized on by users and developers, then that engine's team has complete control over what the web becomes regardless of competing implementations are doing.
It creates a HUGE hurdle to pull the web in another direction. People weren't "stuck" with IE6 because it wasn't opensource, they were stuck because the distributor wasn't releasing new versions that also did what the competing products wanted supported.
I don't think either propriety vs opensource or dead vs active development are important to the overall question of "is standardizing on a single implementation a bad idea?"
Yes, the fact it had dropped out of active development made it worse to standardize on, but it was already a bad idea.
The same goes for open source. Yes, it can be forked to get away from something bad, but if only one browser/engine becomes standardized on by users and developers, then that engine's team has complete control over what the web becomes regardless of competing implementations are doing.
It creates a HUGE hurdle to pull the web in another direction. People weren't "stuck" with IE6 because it wasn't opensource, they were stuck because the distributor wasn't releasing new versions that also did what the competing products wanted supported.
And what happens when somebody discovers a zero-day security flaw in Webkit then? Even benign monoculture is bad for the web.
So what? Then the exploit will work with 100% of browsers instead of, say, 40% as it is now.
Not that much of a difference...
Not that much of a difference...
So because we don't have enough browser competition, we should have one browser monopoly?
Your cure is worse than the disease.
Your cure is worse than the disease.
I never said we should have browser monopoly. I said, a 0-day covering 100% of browsers compared to one covering 40-50% of browsers ain't much of a difference.
That said, a single browser engine used is not a browser monopoly.
For one, because a browser is more than the browser engine used. So you can have browsers with the same engine (Chrome, Webkit, Konqueror, ...) competing on the GUI front.
Second, you can even add new rendering features and options ON TOP of the same rendering engine. Webkit has stuff that Chrome does not, even in the browser engine department. It just means that you have the bases covered with ONE codebase, with more compatibility, and you don't have to reinvent any "wheels", ie. things you have to get working the same way anyway, as is the rendering of a DIV, for example. So this also takes care of the "competition" in HTML implementation issue.
Third, a monopoly (when considered a bad thing) implies some way to abuse that power. The use of a single open source browser engine provides none, since no one in particular controls it. Besides, anyone can still write a better browser engine if you want, and even cherry pick parts of the single 99% popular engine.
That said, a single browser engine used is not a browser monopoly.
For one, because a browser is more than the browser engine used. So you can have browsers with the same engine (Chrome, Webkit, Konqueror, ...) competing on the GUI front.
Second, you can even add new rendering features and options ON TOP of the same rendering engine. Webkit has stuff that Chrome does not, even in the browser engine department. It just means that you have the bases covered with ONE codebase, with more compatibility, and you don't have to reinvent any "wheels", ie. things you have to get working the same way anyway, as is the rendering of a DIV, for example. So this also takes care of the "competition" in HTML implementation issue.
Third, a monopoly (when considered a bad thing) implies some way to abuse that power. The use of a single open source browser engine provides none, since no one in particular controls it. Besides, anyone can still write a better browser engine if you want, and even cherry pick parts of the single 99% popular engine.
You're implying that nobody in particular controls WebKit? That is patently false.
And the distinction between a browser engine monopoly and a browser monopoly is irrelevant to this discussion. We're talking about browser engines here.
Furthermore, suggesting that people can add "new rendering features and options" on top of WebKit solves nothing! Those would just have to be prefixed in the same way, or would be incompatible, and we're back to square one.
And the distinction between a browser engine monopoly and a browser monopoly is irrelevant to this discussion. We're talking about browser engines here.
Furthermore, suggesting that people can add "new rendering features and options" on top of WebKit solves nothing! Those would just have to be prefixed in the same way, or would be incompatible, and we're back to square one.
You're implying that nobody in particular controls WebKit? That is patently false.
"When you assume", well, you know the rest...
I only say that neither Apple nor Google (or Amazon, Samsung, QT, KDE, etc) control Webkit now. If all of them control it, thats not a monopoly of control. Plus, it's open source. If you want to toil at it for free, or throw millions of money to take it to the direction you want, you are able to.
And the distinction between a browser engine monopoly and a browser monopoly is irrelevant to this discussion. We're talking about browser engines here.
We're talking about innovation re: browsers, in this particular THREAD (threads can diverge from the main post point, and such innovation can also happen at the browser level. Plus, I ALSO covered the engine monopoly with respect to browser rendering innovation.
Furthermore, suggesting that people can add "new rendering features and options" on top of WebKit solves nothing! Those would just have to be prefixed in the same way, or would be incompatible, and we're back to square one.
Only I didn't say this AS a solution to the prefixing issue --which I didn't address at all.
What I addressed was that a "single browser engine" != "rendering innovation stops", because innovation can happen ON TOP of a single browser engine as well as on top of different engines.
"When you assume", well, you know the rest...
I only say that neither Apple nor Google (or Amazon, Samsung, QT, KDE, etc) control Webkit now. If all of them control it, thats not a monopoly of control. Plus, it's open source. If you want to toil at it for free, or throw millions of money to take it to the direction you want, you are able to.
And the distinction between a browser engine monopoly and a browser monopoly is irrelevant to this discussion. We're talking about browser engines here.
We're talking about innovation re: browsers, in this particular THREAD (threads can diverge from the main post point, and such innovation can also happen at the browser level. Plus, I ALSO covered the engine monopoly with respect to browser rendering innovation.
Furthermore, suggesting that people can add "new rendering features and options" on top of WebKit solves nothing! Those would just have to be prefixed in the same way, or would be incompatible, and we're back to square one.
Only I didn't say this AS a solution to the prefixing issue --which I didn't address at all.
What I addressed was that a "single browser engine" != "rendering innovation stops", because innovation can happen ON TOP of a single browser engine as well as on top of different engines.
According to Mozilla's own research[1]:
[1] https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#D...
how many sites in your mobile Webkit browser crawl use at least one of 'transition', 'transition-timing-function', 'transition-duration', 'transition-property', 'transition-delay' (ignoring prefixes)?
1245 / 30087 = 4.13%
how many use them only with -webkit prefixes (no -moz or unprefixed versions of the properties)?
336 / 30087 = 1.12%
how many use them only with -webkit prefixes and unprefixed (no -moz versions of the properties)?
365 / 30087 = 1.21%
[1] https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#D...
For a long time, reddit's mobile interface was broken in anything other than webkit, entirely because of a single -webkit CSS rule they were using to display the voting arrows.
If just a few really popular sites have broken mobile sites because of this, that's a big problem!
If just a few really popular sites have broken mobile sites because of this, that's a big problem!
While it's important to support cross-browser compatibility, it is equally important to deliver to the user the possible design experience. Unfortunately, this may come as a loss to the functionality of non-supporting browsers but I think in the end, it's worth it. Of course we should strive to enforce compatibility but not at the expense of creating a design of lesser-quality (as a result of being wrapped in cross-browser compatibility).
If the user visits your site with an unsupported browser (which in this case may actually perfectly support the features you want), (s)he's going to have a terrible experience and see a crappy design.
So I think you undermined your own argument completely.
So I think you undermined your own argument completely.
Is it possible to single out a specific browser to provide an enhanced experience? Yes. Is it possible to deliver a lowest common denominator experience to mobile browsers and IE? Yes. Are these options mutually exclusive? No.
Your perspectives are not incompatible.
Your perspectives are not incompatible.
It's absolutely true that those things aren't exclusive, but as somebody who often uses two rare but capable user-agents (Lynx and the browser on an old Nokia S40), I can testify that in practice, a significant number of websites aren't being created with both in mind, and I think a significant number of designers don't really understand what the lowest common denominator really means.
It's very very easy to pay attention to only a handful of user agents, and from what I can see, right now that's trending towards 2-3 desktop browsers + "mobile" (which usually means "the iPhone and maybe one or two Android devices").
It's very very easy to pay attention to only a handful of user agents, and from what I can see, right now that's trending towards 2-3 desktop browsers + "mobile" (which usually means "the iPhone and maybe one or two Android devices").
I think I presented a trade-off rather than undermining my own argument although I didn't really clarify that I guess.
Essentially you either focus 100% to design and implementing the design via any available technologies (cross-compatible or not) or settle for 80% (20% loss of design and vision from effort in ensuring compatibility).
Ultimately it depends how passionate you are about your design. Personally I would rather have 5 people absolutely fall in love with and be moved by my design/interface/experience rather than 100 people being able to simply 'view' it.
Essentially you either focus 100% to design and implementing the design via any available technologies (cross-compatible or not) or settle for 80% (20% loss of design and vision from effort in ensuring compatibility).
Ultimately it depends how passionate you are about your design. Personally I would rather have 5 people absolutely fall in love with and be moved by my design/interface/experience rather than 100 people being able to simply 'view' it.
Can't we just have type="text/css' and type="text/css+webkit"? Wouldn't utilizing MIME types solve this problem for all parties? W3C can continue to be ineffective without vendors subverting its control. Vendors get a namespace in which to stick their ill-thought experiments. Developers get to isolate vendor-specific CSS away from the standard stuff.
edit: clarification, hopefully
edit: clarification, hopefully
If the browsers available to the general public support vendor-specific sheets, the problem won't be solved at all. At some point Firefox and IE will see that there are a lot of pages out there on the web written with "text/css+webkit" and start to interpret them in order to compete. This is the same problem they are faced with today through "-webkit-".
Are you saying that Firefox interprets -webkit- styles? If that's the case then there is no way of solving this problem because the browsers are subverting what is essentially a dependency injection process.
The point behind prefix was to support experimental CSS features and the prefix gets dropped once it's out. This is not Webkit specific, other browsers do the same. It's a pretty bad idea indeed, but I am not sure why you are pointing at webkit only.
The problem is that using prefix-less names means that it needs to be standardized before any experimentation can be done.
Standards that get ratified before any experimental implementations exist tend to be horrible.
Standards that get ratified before any experimental implementations exist tend to be horrible.
The entire prefix thing is just silly. Do whatever the standard say it should do and be done with it.
So... one should never use features that aren't already in the standard?
Sure, that's one approach. But what if you want one of those features?
Sure, that's one approach. But what if you want one of those features?
Honestly I put in css which _does the very same thing_ for each of the major browsers and then once more with no prefix.
So standardize it already. It is a defactor standard, so why haven't the standard organizations made it yet?
So standardize it already. It is a defactor standard, so why haven't the standard organizations made it yet?
Spoken like someone who probably has never had to deal with vendor extensions to OpenGL... :(
Try to fix your standards body and get them to move faster!
Try to fix your standards body and get them to move faster!
The problem of a standards body is that it requires everyone involved to have an interest in having a common standard. When this is the case, they work fine. When this is not the case, you're SOL.
Do you think Apple and Google have an interest in making mobile sites work on Windows Phone, or phones with Opera Mini?
Do you think Apple and Google have an interest in making mobile sites work on Windows Phone, or phones with Opera Mini?
The browser makers should always be compatible with the standard, the new features shouldn't break the expectations of web page creators which they get after reading the standard. http://www.quirksmode.org/
Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution, and in fact circumvents the original purpose of prefixing--you're assuming that all vendors implement the feature identically, in which case why prefix at all?
The W3C meeting discussion on this was very depressing. Rather than trying to collaborate on standards that move the web forward, Webkit contributors want to get a leg up with proprietary extensions and make the others struggle to catch up.
http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h...
And we've just started this developer nightmare; right now it's mainly focused on CSS prefixing. Thanks to Apple refusing to share its touch patents, the W3C is stalled on touch event standards as well.