7 ms·

WebKit Isn’t Breaking the Web. You Are

89 points by bootload 15y ago

TeeWEE 15y ago
The problem to begin with is that browser makers where adding their own baked prefixes. They where not following the spec and opened the door for designers to use them. My opinion is that final browser builds should not support these prefixes. Its too easy to say that developers are breaking the web. Actually browser makers are. Webkit is the new IE6. Cool features but they are extending the standard with their own baked goodies.
- zobzu 15y ago
  might be voted down, but that's pretty insightful. just remove the inflamatory "webkit is the new IE6" and its actually very accurate.
  - jan_g 15y ago
    I don't think it's accurate at all. Browser vendors aren't 'extending the standard with their own baked goodies', but are merely prefixing those CSS properties that aren't yet finalized, but are part of the standardization process. There's no parallel with IE6 at all, in my opinion.
    - TeeWEE 15y ago
      IE6 sucks now. But when it came out it was one of the advanced browsers out there. And it was the first browser to support shadows and opacity. - Shadows with: filter: Shadow(Color=#999999, Direction=135, Strength=5); - Opacity: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader (src='image_name.png', sizingMethod='scale'); It even has support for javascript in css: left: expression(15+((e=document.documentElement.scrollLeft)?e:document.body.scrollLeft)+'px'); And I remember you could even give your scrollbars colors. How is this different from webkit shipping browser with cool new features now? Similar to microsoft right? They also wanted to show how cool their browser was back then. If Microsoft never shipped IE6 with these extensions we would have a lot less issues a few years ago.
- ugh 15y ago
  Not following the spec? Using prefixes is following the spec. That’s how it’s supposed to work.
deleted 15y ago
[deleted]
shadowflit 15y ago
As an outsider looking in, it seems like the whole prefix thing is approaching the problem from the wrong direction. Why do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable. Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others. 1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2... 2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.
- jballanc 15y ago
  If only it were this simple. The problem is that not only are these implementations not formalized, but also there is often dispute over how they should be standardized. Border radius, for example, is "-webkit-border-bottom-right-radius" in Webkit but "-moz-border-radius-bottomright" in Firefox. If you look at competing ideas for standardizing things like gradients, you'll find even more disagreement. This is why prefixes are needed.
  - zalew 15y ago
    Wouldn't naming conventions solve the problem? f.ex. -{vendor}-{object}-{property}-{positions vertical-horizontal}-{additional}: {some-value-syntax-also} In the end, everyone would just drop the prefix. Generating parsing it would be also way easier.
    - 15y ago
jballanc 15y ago
The real problem with CSS is that it hasn't evolved. Solutions like SASS/SCSS or LESS resolve this issue quite neatly. Instead of needing to know or look up the peculiar browser-specific declarations for things like border-radius, you simply say "rounded(5px)".
- zalew 15y ago
  All these solutions are only a wrapper around the real problem, which by all means in the end has to be solved.
  - jballanc 15y ago
    No, the real problem is that CSS (as it currently exists) has no means for abstraction. These approaches solve that. Take an analogy: in the not too distant past, some microprocessors had divide instructions, others did not, but you didn't see people bracketing division instructions with platform-specific conditionals. For the most part no one cared because if you wrote "x / y" in your code, that was merely an abstraction that some compiler would break down into a series of shifts and adds or a divide, depending on the platform.
    - zalew 15y ago
      If less & co would automatically abstract css vendor-specific features just like Jquery abstracts javascript DOM access methods, you'd be right, but as far as I can see on the main page http://lesscss.org/ http://lesscss.org/ you still have to declare it by hand, so it doesn't work that way. Using less doesn't make styling widely compatible out of the box. Looks like what we need is less-like frameworks to evolve into cross-platform abstraction layers.
      - JeremyBanks 15y ago
        Sass's Compass' CSS3 module "Provides cross browser CSS3 mixins that take advantage of available pre-spec vendor prefixes." http://compass-style.org/reference/compass/css3/ http://compass-style.org/reference/compass/css3/
azakai 15y ago
It's debatable whether WebKit did or didn't do anything wrong. If vendor prefixes appeared only in developer version of the browser, instead of stable releases, we wouldn't be in this situation - and developers would still get preview access to new browser features for testing, to prepare for when they become standardized. Instead, the major WebKit browsers include vendor prefixed stuff in stable releases. Since WebKit won in mobile (and is on the way to winning overall), it isn't surprising we got to where we are now, with all other browsers planning to implement WebKit prefixed features.
- kalleboo 15y ago
  If WebKit didn't include vendor prefixes in stable releases, we'd still be here 6 years after they first implemented it putting PNG files in the corners of all our divs. The problems are the standards aren't there. The standards organization is just way too slow.
  - TeeWEE 15y ago
    I totally agree. W3C is slow. But standards are like politics. You cannot blame W3C for 1 of the 10 parties not agreeing with the spec. And once we got it we are bound to it. This is the reason native is always better then web. Once the technology is available one party will provide an api and it will be available in the next version of the OS. Native is a free market approach, may the best man win. But propietary. Web is like socialism. Everybody gets the same but the whole system doesnt drive innovation.
- masklinn 15y ago
  One of the problems is, vendor prefixes have both "beta" and "proprietary" meanings. And there's no way to disambiguate from the property's name. And browser vendors will ship proprietary extensions, whether you like it or not.
- magicalist 15y ago
  Mobile Firefox includes vendor prefixes, and has from the beginning. All the new Web API stuff will be prefixed where appropriate. That's exactly what standard operating procedure calls for (whether right or wrong) and what mobile WebKit has mostly done (and we're really talking Apple here, at least for the first year or two and a bunch of major CSS spec drafts). In other words, you didn't actually say what actions may or may not have been wrong.
cheald 15y ago
The problem isn't Webkit, or even web developers targeting webkit. The problem is that we have a de facto standard for rounded corners on the web, and it's still not an accepted standard. The W3C designs and approves CSS draft specs on a schedule that makes IE development cycles look speedy. The web moves faster than that now. The first CSS3 draft for the backgrounds and borders module was published in 2001. ELEVEN YEARS LATER it's still not a finalized standard. And the problem is developers? I've been using -moz and -webkit and -o vendor prefixes for years now, with virtually no variation or change. Why don't we have a standardized border-radius yet? By the time the W3C actually settles on a standard, the industry will be twelve draft specs ahead of them in production for all practical purposes. I really, really dislike the idea of non-webkit vendors implementing support for webkit prefixes. Stick to your own prefixes. Don't break the rules to make up for lazy or bad developers. That's a huge part of why IE was such a pain in our collective asses for so many years. When you coddle lazy or bad developers, you end up breeding an entire crop of developers who end up creating terrible legacy systems that will plague us for years to come. Just say no. If you have to do something, go ahead and implement the draft spec. Developers: Use Sass or LESS or similar. Start worrying about presentation and stop worrying about implementation. Until the W3C gets its act together, use tools that help you do the right thing with the least amount of effort. Everyone wins.
- yuhong 15y ago
  CSS3 Background and Borders is a candidate recommendation, which means in most recent browsers it can already be used unprefixed.
  - cheald 15y ago
    And it reached that Candidate Recommendation status nearly one year ago, only ten years after it was first introduced. I'm picking on border-radius because it's an easy target, but the fact remains that large pieces of CSS3 remain in "working draft" statuses. Microsoft went all cowboy and gunked up the web with their "standards be damned, we'll do it live" approach to IE, and since then, other browser vendors have been extremely spec compliant in an attempt to avoid the same sort of mess that IE got us into, but they're hogtied by a standards body that takes longer to work out border-radius than it takes for most web companies to be born, flourish, and die.
marizmelo 15y ago
Why do we have those prefixes in the first place? Ok, ok, test new functionalities is a good thing, but create bad practices among developers it is not. All the problems with IE began when they (M word) started their with own implementation of javascript, CSS, and even HTML (automatic close for tags is not ok people, developers need to learn). It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you. All the problems involving incompatibilities began with browser vendors trying to "simplify" developers life giving their own version of the "standard". If a new functionality is not part of the standards yet it must be a reason. Why not respect that and avoid all sort of complications? Why the rush? Force organizations to release early pieces of work will generate bad industry standards. Do not like the way how one standard is defined? You will have to swallow. - by brazilian team couch Zagallo
- Yaggo 15y ago
  > It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you. You realize that browser vendors are members of W3C and thus essentially creating the standards [for their commercial interests]? For example, the browsers have CSS transforms today because Apple proposed them back in 2007. (Wow, that's half a decade ago; time passes fast.) > Why the rush? Because without the "rush" by browser vendors we would be writing XHTML 2.1.14 without any fancy HTML5 stuff.
  - cheald 15y ago
    And CSS transforms are still in the "working draft" stage. It's been a half-decade and they aren't a full part of the standard yet. That's why "the rush".
  - marizmelo 15y ago
    Creating confusion among developers just because you want to release "fancy HTML5 stuff" doesn't seem to me as a good idea. Why not first implement these new features on your own browser as "developer version only", and prove that they work and do benefit users and the web in general? I believe that is the way you establish credibility and acceptance of a particular feature. I am not against the release of all these amazing things, but I am against the way they are currently doing it. If the proposed features do not have defined and W3C-agreed set of names and properties associated with those features, they should not be released to end users. I don't want to see something like "only for IE" in applications and websites anymore. The problem is still small for now, but it can become huge if this bad practice doesn't stop.
lhm 15y ago
Is there someone gathering statistics on css prefix usage in the wild? I think it would be interesting to see some real data on this.
rplnt 15y ago
Will wide -webkit prefix support stop sites like google.com from sniffing and blocking users? Probably not. And that is even bigger problem than forgetting to add some vendor specific prefixes. Worst thing about it is that it's all "politics". Want people to use your browser? Block other browsers and they will eventually switch. Microsoft did this, now Google does this. It's just that this time no one seems to care.
Yaggo 15y ago
Dev^H^H^HPeople are lazy. Preprocessor tools exist but installing and running them is always extra work unless 100% integrated into workflow. What if there was one common "-experimental-" or "-x-" prefix instead of multiple vendor prefixes? Browsers would parse them all and throw away the ones they don't support/undestand.
- lmm 15y ago
  If you do that then if two browsers implement a new property incompatibly it becomes impossible to write a site that works in both (see gradients, where the "function call" syntax is different in different browsers).
  - Yaggo 15y ago
    The browser can still ignore a property if its value cannot be fully parsed (e.g. invalid gradient syntax).
    - lmm 15y ago
      Yes, my point is at the moment I can set -moz-gradient and -webkit-gradient (or whatever the actual property name is) using the different syntax for each, and have my page work in both.
  - Zarel 15y ago
    What about one common prefix in addition to vendor prefixes? Then you could write "-x-border-radius: 2px" in the majority of times where the property was compatible, but you'd still be able to write "-webkit-border-radius: 2px 4px; -moz-border-radius: 4px 2px" where it's implemented differently.
willvarfar 15y ago
This talks exclusively about webkit in a mobile world; webkit is also Chrome, and so has taken over the desktop world too. The success of an engine lauded for its cleanliness and conciseness and architecture (khtml) over the sprawling mess of engines that preceded it.
Flenser 15y ago
Won't webkit drop the prefix once things are standardised and then sites will either be broken or have to drop the prefix to o, thereby working in all browsers?
- lmm 15y ago
  No. Apple isn't going to break existing sites out of purism. Webkit will be supporting -webkit- for decades, and so will everyone else, just as with every nonstandard tag that's ever existed.

89 points by bootload 15y ago

The problem to begin with is that browser makers where adding their own baked prefixes. They where not following the spec and opened the door for designers to use them. My opinion is that final browser builds should not support these prefixes. Its too easy to say that developers are breaking the web. Actually browser makers are. Webkit is the new IE6. Cool features but they are extending the standard with their own baked goodies.

zobzu 15y ago
might be voted down, but that's pretty insightful. just remove the inflamatory "webkit is the new IE6" and its actually very accurate.
- jan_g 15y ago
  I don't think it's accurate at all. Browser vendors aren't 'extending the standard with their own baked goodies', but are merely prefixing those CSS properties that aren't yet finalized, but are part of the standardization process. There's no parallel with IE6 at all, in my opinion.
  - TeeWEE 15y ago
    IE6 sucks now. But when it came out it was one of the advanced browsers out there. And it was the first browser to support shadows and opacity. - Shadows with: filter: Shadow(Color=#999999, Direction=135, Strength=5); - Opacity: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader (src='image_name.png', sizingMethod='scale'); It even has support for javascript in css: left: expression(15+((e=document.documentElement.scrollLeft)?e:document.body.scrollLeft)+'px'); And I remember you could even give your scrollbars colors. How is this different from webkit shipping browser with cool new features now? Similar to microsoft right? They also wanted to show how cool their browser was back then. If Microsoft never shipped IE6 with these extensions we would have a lot less issues a few years ago.
ugh 15y ago
Not following the spec? Using prefixes is following the spec. That’s how it’s supposed to work.

deleted 15y ago

[deleted]

shadowflit 15y ago

As an outsider looking in, it seems like the whole prefix thing is approaching the problem from the wrong direction. Why do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable. Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others. 1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2... 2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.

jballanc 15y ago
If only it were this simple. The problem is that not only are these implementations not formalized, but also there is often dispute over how they should be standardized. Border radius, for example, is "-webkit-border-bottom-right-radius" in Webkit but "-moz-border-radius-bottomright" in Firefox. If you look at competing ideas for standardizing things like gradients, you'll find even more disagreement. This is why prefixes are needed.
- zalew 15y ago
  Wouldn't naming conventions solve the problem? f.ex. -{vendor}-{object}-{property}-{positions vertical-horizontal}-{additional}: {some-value-syntax-also} In the end, everyone would just drop the prefix. Generating parsing it would be also way easier.
  - 15y ago

jballanc 15y ago

The real problem with CSS is that it hasn't evolved. Solutions like SASS/SCSS or LESS resolve this issue quite neatly. Instead of needing to know or look up the peculiar browser-specific declarations for things like border-radius, you simply say "rounded(5px)".

zalew 15y ago
All these solutions are only a wrapper around the real problem, which by all means in the end has to be solved.
- jballanc 15y ago
  No, the real problem is that CSS (as it currently exists) has no means for abstraction. These approaches solve that. Take an analogy: in the not too distant past, some microprocessors had divide instructions, others did not, but you didn't see people bracketing division instructions with platform-specific conditionals. For the most part no one cared because if you wrote "x / y" in your code, that was merely an abstraction that some compiler would break down into a series of shifts and adds or a divide, depending on the platform.
  - zalew 15y ago
    If less & co would automatically abstract css vendor-specific features just like Jquery abstracts javascript DOM access methods, you'd be right, but as far as I can see on the main page http://lesscss.org/ http://lesscss.org/ you still have to declare it by hand, so it doesn't work that way. Using less doesn't make styling widely compatible out of the box. Looks like what we need is less-like frameworks to evolve into cross-platform abstraction layers.
    - JeremyBanks 15y ago
      Sass's Compass' CSS3 module "Provides cross browser CSS3 mixins that take advantage of available pre-spec vendor prefixes." http://compass-style.org/reference/compass/css3/ http://compass-style.org/reference/compass/css3/

azakai 15y ago

It's debatable whether WebKit did or didn't do anything wrong. If vendor prefixes appeared only in developer version of the browser, instead of stable releases, we wouldn't be in this situation - and developers would still get preview access to new browser features for testing, to prepare for when they become standardized. Instead, the major WebKit browsers include vendor prefixed stuff in stable releases. Since WebKit won in mobile (and is on the way to winning overall), it isn't surprising we got to where we are now, with all other browsers planning to implement WebKit prefixed features.

kalleboo 15y ago
If WebKit didn't include vendor prefixes in stable releases, we'd still be here 6 years after they first implemented it putting PNG files in the corners of all our divs. The problems are the standards aren't there. The standards organization is just way too slow.
- TeeWEE 15y ago
  I totally agree. W3C is slow. But standards are like politics. You cannot blame W3C for 1 of the 10 parties not agreeing with the spec. And once we got it we are bound to it. This is the reason native is always better then web. Once the technology is available one party will provide an api and it will be available in the next version of the OS. Native is a free market approach, may the best man win. But propietary. Web is like socialism. Everybody gets the same but the whole system doesnt drive innovation.
masklinn 15y ago
One of the problems is, vendor prefixes have both "beta" and "proprietary" meanings. And there's no way to disambiguate from the property's name. And browser vendors will ship proprietary extensions, whether you like it or not.
magicalist 15y ago
Mobile Firefox includes vendor prefixes, and has from the beginning. All the new Web API stuff will be prefixed where appropriate. That's exactly what standard operating procedure calls for (whether right or wrong) and what mobile WebKit has mostly done (and we're really talking Apple here, at least for the first year or two and a bunch of major CSS spec drafts). In other words, you didn't actually say what actions may or may not have been wrong.

cheald 15y ago

The problem isn't Webkit, or even web developers targeting webkit. The problem is that we have a de facto standard for rounded corners on the web, and it's still not an accepted standard. The W3C designs and approves CSS draft specs on a schedule that makes IE development cycles look speedy. The web moves faster than that now. The first CSS3 draft for the backgrounds and borders module was published in 2001. ELEVEN YEARS LATER it's still not a finalized standard. And the problem is developers? I've been using -moz and -webkit and -o vendor prefixes for years now, with virtually no variation or change. Why don't we have a standardized border-radius yet? By the time the W3C actually settles on a standard, the industry will be twelve draft specs ahead of them in production for all practical purposes. I really, really dislike the idea of non-webkit vendors implementing support for webkit prefixes. Stick to your own prefixes. Don't break the rules to make up for lazy or bad developers. That's a huge part of why IE was such a pain in our collective asses for so many years. When you coddle lazy or bad developers, you end up breeding an entire crop of developers who end up creating terrible legacy systems that will plague us for years to come. Just say no. If you have to do something, go ahead and implement the draft spec. Developers: Use Sass or LESS or similar. Start worrying about presentation and stop worrying about implementation. Until the W3C gets its act together, use tools that help you do the right thing with the least amount of effort. Everyone wins.

yuhong 15y ago
CSS3 Background and Borders is a candidate recommendation, which means in most recent browsers it can already be used unprefixed.
- cheald 15y ago
  And it reached that Candidate Recommendation status nearly one year ago, only ten years after it was first introduced. I'm picking on border-radius because it's an easy target, but the fact remains that large pieces of CSS3 remain in "working draft" statuses. Microsoft went all cowboy and gunked up the web with their "standards be damned, we'll do it live" approach to IE, and since then, other browser vendors have been extremely spec compliant in an attempt to avoid the same sort of mess that IE got us into, but they're hogtied by a standards body that takes longer to work out border-radius than it takes for most web companies to be born, flourish, and die.

marizmelo 15y ago

Why do we have those prefixes in the first place? Ok, ok, test new functionalities is a good thing, but create bad practices among developers it is not. All the problems with IE began when they (M word) started their with own implementation of javascript, CSS, and even HTML (automatic close for tags is not ok people, developers need to learn). It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you. All the problems involving incompatibilities began with browser vendors trying to "simplify" developers life giving their own version of the "standard". If a new functionality is not part of the standards yet it must be a reason. Why not respect that and avoid all sort of complications? Why the rush? Force organizations to release early pieces of work will generate bad industry standards. Do not like the way how one standard is defined? You will have to swallow. - by brazilian team couch Zagallo

Yaggo 15y ago
> It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you. You realize that browser vendors are members of W3C and thus essentially creating the standards [for their commercial interests]? For example, the browsers have CSS transforms today because Apple proposed them back in 2007. (Wow, that's half a decade ago; time passes fast.) > Why the rush? Because without the "rush" by browser vendors we would be writing XHTML 2.1.14 without any fancy HTML5 stuff.
- cheald 15y ago
  And CSS transforms are still in the "working draft" stage. It's been a half-decade and they aren't a full part of the standard yet. That's why "the rush".
- marizmelo 15y ago
  Creating confusion among developers just because you want to release "fancy HTML5 stuff" doesn't seem to me as a good idea. Why not first implement these new features on your own browser as "developer version only", and prove that they work and do benefit users and the web in general? I believe that is the way you establish credibility and acceptance of a particular feature. I am not against the release of all these amazing things, but I am against the way they are currently doing it. If the proposed features do not have defined and W3C-agreed set of names and properties associated with those features, they should not be released to end users. I don't want to see something like "only for IE" in applications and websites anymore. The problem is still small for now, but it can become huge if this bad practice doesn't stop.

lhm 15y ago

Is there someone gathering statistics on css prefix usage in the wild? I think it would be interesting to see some real data on this.

rplnt 15y ago

Will wide -webkit prefix support stop sites like google.com from sniffing and blocking users? Probably not. And that is even bigger problem than forgetting to add some vendor specific prefixes. Worst thing about it is that it's all "politics". Want people to use your browser? Block other browsers and they will eventually switch. Microsoft did this, now Google does this. It's just that this time no one seems to care.

Yaggo 15y ago

Dev^H^H^HPeople are lazy. Preprocessor tools exist but installing and running them is always extra work unless 100% integrated into workflow. What if there was one common "-experimental-" or "-x-" prefix instead of multiple vendor prefixes? Browsers would parse them all and throw away the ones they don't support/undestand.

lmm 15y ago
If you do that then if two browsers implement a new property incompatibly it becomes impossible to write a site that works in both (see gradients, where the "function call" syntax is different in different browsers).
- Yaggo 15y ago
  The browser can still ignore a property if its value cannot be fully parsed (e.g. invalid gradient syntax).
  - lmm 15y ago
    Yes, my point is at the moment I can set -moz-gradient and -webkit-gradient (or whatever the actual property name is) using the different syntax for each, and have my page work in both.
- Zarel 15y ago
  What about one common prefix in addition to vendor prefixes? Then you could write "-x-border-radius: 2px" in the majority of times where the property was compatible, but you'd still be able to write "-webkit-border-radius: 2px 4px; -moz-border-radius: 4px 2px" where it's implemented differently.

willvarfar 15y ago

This talks exclusively about webkit in a mobile world; webkit is also Chrome, and so has taken over the desktop world too. The success of an engine lauded for its cleanliness and conciseness and architecture (khtml) over the sprawling mess of engines that preceded it.

Flenser 15y ago

Won't webkit drop the prefix once things are standardised and then sites will either be broken or have to drop the prefix to o, thereby working in all browsers?

lmm 15y ago
No. Apple isn't going to break existing sites out of purism. Webkit will be supporting -webkit- for decades, and so will everyone else, just as with every nonstandard tag that's ever existed.