7 ms·

Pre-fix the web: Webkit-only solutions hurts the open web

81 points by dave1010uk 15y ago

jakubw 15y ago
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-".
___Calv_Dee___ 15y ago
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).
- gcp 15y ago
  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.
  - ___Calv_Dee___ 15y ago
    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.
  - politician 15y ago
    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.
    - wwweston 15y ago
      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").
dmethvin 15y ago
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? 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. tantek: I think if you're working on open standards, you should propose your features before you implement them and discuss that here. smfr: We can't do that. sylvaing: We can't do that either. tantek: We're going to push you to do that sooner and sooner. jdaggett: If you're proposing something that's going to be put on a Web page, how is that proprietary? http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html 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.
- macspoofing 15y ago
  >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.
- rmc 15y ago
  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-".
  - dmethvin 15y ago
    "A lot" isn't really true, here is some quantification: https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility 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.
blibble 15y ago
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...
- dmethvin 15y ago
  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.
  - blibble 15y ago
    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...
    - gcp 15y ago
      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.
mileszs 15y ago
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.
sp332 15y ago
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.
- khuey 15y ago
  Except it's not guaranteed to break, because vendors aren't consistent about dropping prefixes.
- condiment 15y ago
  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.
- eli 15y ago
  OK, so it breaks and my corners go back to not being properly rounded. I can live with that.
jorisw 15y ago
So where are all these sites with only -webkit- prefixed CSS? I don't know any.
- gcp 15y ago
  Try impersonating the UA of a mobile device. This is where the competition nowadays happens.
tomjen3 15y ago
The entire prefix thing is just silly. Do whatever the standard say it should do and be done with it.
- eli 15y ago
  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?
  - EGreg 15y ago
    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/ http://www.quirksmode.org/
  - angersock 15y ago
    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!
    - gcp 15y ago
      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?
  - tomjen3 15y ago
    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?
politician 15y ago
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
- dmethvin 15y ago
  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-".
  - politician 15y ago
    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.
ori_b 15y ago
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.
huxley 15y ago
According to Mozilla's own research[1]: 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% Is it really that serious an issue if it only crops up in 1.12% of mobile sites (where webkit has the overwhelming marketshare). [1] https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#Data_on_vendor-specific_prefixes https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#D...
- starwed 15y ago
  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!
halayli 15y ago
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.

81 points by dave1010uk 15y ago

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-".

___Calv_Dee___ 15y ago

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).

gcp 15y ago
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.
- ___Calv_Dee___ 15y ago
  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.
- politician 15y ago
  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.
  - wwweston 15y ago
    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").

dmethvin 15y ago

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? 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. tantek: I think if you're working on open standards, you should propose your features before you implement them and discuss that here. smfr: We can't do that. sylvaing: We can't do that either. tantek: We're going to push you to do that sooner and sooner. jdaggett: If you're proposing something that's going to be put on a Web page, how is that proprietary? http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html 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.

macspoofing 15y ago
>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.
rmc 15y ago
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-".
- dmethvin 15y ago
  "A lot" isn't really true, here is some quantification: https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility 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.

blibble 15y ago

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...

dmethvin 15y ago
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.
- blibble 15y ago
  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...
  - gcp 15y ago
    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.

mileszs 15y ago

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.

sp332 15y ago

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.

khuey 15y ago
Except it's not guaranteed to break, because vendors aren't consistent about dropping prefixes.
condiment 15y ago
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.
eli 15y ago
OK, so it breaks and my corners go back to not being properly rounded. I can live with that.

jorisw 15y ago

So where are all these sites with only -webkit- prefixed CSS? I don't know any.

gcp 15y ago
Try impersonating the UA of a mobile device. This is where the competition nowadays happens.

tomjen3 15y ago

The entire prefix thing is just silly. Do whatever the standard say it should do and be done with it.

eli 15y ago
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?
- EGreg 15y ago
  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/ http://www.quirksmode.org/
- angersock 15y ago
  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!
  - gcp 15y ago
    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?
- tomjen3 15y ago
  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?

politician 15y ago

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

dmethvin 15y ago
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-".
- politician 15y ago
  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.

ori_b 15y ago

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.

huxley 15y ago

According to Mozilla's own research[1]: 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% Is it really that serious an issue if it only crops up in 1.12% of mobile sites (where webkit has the overwhelming marketshare). [1] https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#Data_on_vendor-specific_prefixes https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#D...

starwed 15y ago
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!

halayli 15y ago

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.