6 ms·

Edit: The previous title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly" Looks like the webkit prefix tags are creating

Edit: The previous title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly" Looks like the webkit prefix tags are creating the new IE6. As usual, it's the web developers fault for not updating their CSS prefixes. http://css.dzone.com/articles/why-webkit-new-ie6-trap-vendor http://css.dzone.com/articles/why-webkit-new-ie6-trap-vendor Mozilla, Opera and Microsoft have been complaining about this and Opera had already implemented support for the webkit prefixes(before switching to webkit/Blink entirely) and Firefox-OS will probably follow.

afs35mm 12y ago
I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. Why should we be developing to the lowest common denominator? I think we should also watch out for link-bait SEO headlines such as "Why Webkit is the New IE6 (The Trap of Vendor Prefixes)"...
- ntakasaki 12y ago
  The problem isn't that developers should be developing for the lowest common denominator. It is that the prefixes are not being dropped by websites even after other browsers start implementing the feature, or it's that they continue to use the webkit prefix for new websites.
- masklinn 12y ago
  > I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. No. It tried to solve two different needs: proprietary stable APIs and unstable/in-flux specs. And the abuse of the latter forced browsers to drop the use-case entirely and hide features behind flags because developers could not be trusted to act responsibly, so it definitely didn't solve that problem. > Why should we be developing to the lowest common denominator? That's not developing to the LCD, that developers deploying half-specified and unstable APIs in production.
  - tomjen3 12y ago
    Why do you blame developers? The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature) and for MS for developing a browser at a glacial pace.
    - masklinn 12y ago
      > Why do you blame developers? Because the fault lies with them and no one else, no matter how in denial you are. > The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature) That doesn't even make sense, standards work is not "you shipped some random unspecified and mostly broken pile of shit and some other bloke was convinced to half-implement something which kinda looks similar if you squint so let's just call it standandard :shipit:"
      - tomjen3 12y ago
        Do you have any backup for your arguments?
        ntakasaki 12y ago
        http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-we... Co-Chairmain of the web standards group: http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW http://www.glazman.org/weblog/dotclear/index.php?post/2012/0... Mozilla on the issue. http://alistapart.com/article/the-vendor-prefix-predicament-alas-eric-meyer-interviews-tantek-celik http://alistapart.com/article/the-vendor-prefix-predicament-...
tomjen3 12y ago
I disagree. If the tags had been standalized then we would be using them. Unfortunately the standards commity dropped the ball on this one because they are unable to act fast enough.
- masklinn 12y ago
  > Unfortunately the standards commity dropped the ball on this one because they are unable to act fast enough. These are features which changed semantics and syntax multiple times over the course of their standardisation, it's not like standards guys were slow because they found it fun > If the tags had been standalized then we would be using them. Webkit browsers have all supported unprefixed box-sizing since the release of Safari Mobile 5.1 in March 2012. 2 years later… https://github.com/search?l=CSS&o=desc&q=-webkit-box-sizing&ref=advsearch&s=indexed&type=Code https://github.com/search?l=CSS&o=desc&q=-webkit-box-sizing&...
  - Smudge 12y ago
    That query means nothing. Most of those results include the non-prefixed version as well. The prefixed one is there for backwards compatibility.
    - masklinn 12y ago
      > That query means nothing. That query means developers by and large don't care and just cargo-cult through. > The prefixed one is there for backwards compatibility. Backwards compatibility with what, fucking Chrome 6? How many of these sites have been tested for backwards compatibility in Chrome 6? I'd bet it's somewhere around "none whatsoever".
      - tomjen3 12y ago
        No reason to remove them when they are there.
        masklinn 12y ago
skybrian 12y ago
It seems to me that vendor prefixes worked as intended. It allowed the HTML specs to be changed (for the unprefixed versions). True, browsers need to support some pre-standardization variants for now, but this will fade. It doesn't seem like a huge burden for browsers to support older websites for a while, and it doesn't affect new websites.
matthewmacleod 12y ago
Yes. This is down to lazy, short-sighted developers, and it makes me insanely irritated. It's ridiculously easy to make sure you include all appropriate browser-specific and generic prefixes for almost all experimental CSS features. If you use something like Compass, it's even done for you, totally transparently. Lazy developers ruin it for everybody, again. What a surprise.
mikelat 12y ago
> Looks like the webkit prefix tags are creating the new IE6. This bothers me. Webkit isn't some ancient browser that is has remained stagnant for years until google/apple decided to do something about it. Nobody spends hours debugging their perfect layouts in webkit. Webkit isn't holding the entire web back. It's just a poor comparison. I browse mobile web in mostly firefox mobile, and I don't think I've ever seen a mobile site broken on FF but working on Chrome. In fact at least Google has taken some steps to recitfy it, and they've stated they're putting experimental CSS properties behind developer flags. If we're talking about the fact that old people don't update old browsers then Microsoft is one to talk with IE7, IE8, IE9, and IE10.
- untog 12y ago
  The comparison is apt, just not entirely. It isn't a comparison of IE6 vs Webkit, it's of developer reactions to them. For a long time, IE6 ruled the roost, so developers used IE6 as their development target. Browsers that moved beyond it, or implemented things differently (often correctly) were ignored. On mobile, webkit rules the roost. Developers use it as their development target. Browsers that move beyond it or implement things differently (by using non-webkit prefixed CSS) are ignored.
  - mikelat 12y ago
    I mentioned in another comment that when I think of IE6, I think of the hours spent fiddling with the HTML/CSS that works in FF/Chrome but not in IE6 because of browser bugs that were never fixed and standards not followed. It's why I think it's a bad comparison.
- wwweston 12y ago
  Most of my professional time these days is spent on mobile/tablet websites for a major automobile manufacturer. And there are days when we absolutely do obsess over layout and other issues introduced by mobile safari itself. On the release of iOS 7, we actually probably burned a month working with a bug that we never found a solution to (which, fortunately, was fixed with iOS 7.1). That last part underscores that we're fortunate browser makers are issuing regular updates (a big difference from IE). On the other hand, with some of those updates come new bugs and (particularly on Android) fragmentation. Consider that by 2006 there were enough people/resources documenting IE6's quirks that it was pretty rare to run across a bug that someone didn't have a good idea of how to fix/workaround. In 2014 when you run across a mobile bug (particularly one from a recent release, of which there are many), it may well be that nobody knows how to solve your problem, and in some cases nobody seems to even know how to tell you to duplicate it across devices/emulators (http://stackoverflow.com/questions/23142762/how-to-identify-factors-that-will-help-reproduce-web-rendering-bugs-for-android http://stackoverflow.com/questions/23142762/how-to-identify-... ). And of course, like IE, many developers code webkit-only, even iOS only (and I know why: at the level of ambition people often have for mobile websites and with the difficulty involved in testing more than a few devices, it can sometimes seem like the only way to get things out the door). IE6 was no picnic, but there are times I think to myself I'd rather be working on the 2006 desktop web than the 2014 mobile web....
Cthulhu_ 12y ago
I disagree that the webkit tags are creating the new IE 6, after all (IIRC) they're prefixed because the standards behind them aren't yet finished. On the one side I want to make a ramble about why it takes so long for those standards to finish and unprefixed CSS3 and beyond is possible, but on the other hand - without actual real-life use, how can you find all the edge-cases and practical application to create a complete standard?
- talmand 12y ago
  Many of these properties no longer require the prefix for most browsers. For these properties having the webkit prefix only, without the non-prefix property to cascade to, is a problem. I recall many demos, examples, and live sites not displaying as expected in Firefox because the developer decided to use only the webkit prefix. If the webkit team were to start removing the webkit prefixed properties then those sites would have even more broken views.
- bzbarsky 12y ago
  They're initially prefixed because the standard is not finished. Many of them are _still_ prefixed because WebKit has a policy of never removing prefixed features, even if they implement the unprefixed one. So people feel no compunction about using the prefixed stuff in production, and since they only test in WebKit they don't notice when they're using the -webkit-prefixed version even though every single browser (or every browser except WebKit, in some cases) supports the unprefixed standard version.

afs35mm 12y ago

I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. Why should we be developing to the lowest common denominator? I think we should also watch out for link-bait SEO headlines such as "Why Webkit is the New IE6 (The Trap of Vendor Prefixes)"...

ntakasaki 12y ago
The problem isn't that developers should be developing for the lowest common denominator. It is that the prefixes are not being dropped by websites even after other browsers start implementing the feature, or it's that they continue to use the webkit prefix for new websites.
masklinn 12y ago
> I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. No. It tried to solve two different needs: proprietary stable APIs and unstable/in-flux specs. And the abuse of the latter forced browsers to drop the use-case entirely and hide features behind flags because developers could not be trusted to act responsibly, so it definitely didn't solve that problem. > Why should we be developing to the lowest common denominator? That's not developing to the LCD, that developers deploying half-specified and unstable APIs in production.
- tomjen3 12y ago
  Why do you blame developers? The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature) and for MS for developing a browser at a glacial pace.
  - masklinn 12y ago
    > Why do you blame developers? Because the fault lies with them and no one else, no matter how in denial you are. > The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature) That doesn't even make sense, standards work is not "you shipped some random unspecified and mostly broken pile of shit and some other bloke was convinced to half-implement something which kinda looks similar if you squint so let's just call it standandard :shipit:"
    - tomjen3 12y ago
      Do you have any backup for your arguments?
      - ntakasaki 12y ago
        http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-we... Co-Chairmain of the web standards group: http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW http://www.glazman.org/weblog/dotclear/index.php?post/2012/0... Mozilla on the issue. http://alistapart.com/article/the-vendor-prefix-predicament-alas-eric-meyer-interviews-tantek-celik http://alistapart.com/article/the-vendor-prefix-predicament-...

tomjen3 12y ago

I disagree. If the tags had been standalized then we would be using them. Unfortunately the standards commity dropped the ball on this one because they are unable to act fast enough.

masklinn 12y ago
> Unfortunately the standards commity dropped the ball on this one because they are unable to act fast enough. These are features which changed semantics and syntax multiple times over the course of their standardisation, it's not like standards guys were slow because they found it fun > If the tags had been standalized then we would be using them. Webkit browsers have all supported unprefixed box-sizing since the release of Safari Mobile 5.1 in March 2012. 2 years later… https://github.com/search?l=CSS&o=desc&q=-webkit-box-sizing&ref=advsearch&s=indexed&type=Code https://github.com/search?l=CSS&o=desc&q=-webkit-box-sizing&...
- Smudge 12y ago
  That query means nothing. Most of those results include the non-prefixed version as well. The prefixed one is there for backwards compatibility.
  - masklinn 12y ago
    > That query means nothing. That query means developers by and large don't care and just cargo-cult through. > The prefixed one is there for backwards compatibility. Backwards compatibility with what, fucking Chrome 6? How many of these sites have been tested for backwards compatibility in Chrome 6? I'd bet it's somewhere around "none whatsoever".
    - tomjen3 12y ago
      No reason to remove them when they are there.
      - masklinn 12y ago

skybrian 12y ago

It seems to me that vendor prefixes worked as intended. It allowed the HTML specs to be changed (for the unprefixed versions). True, browsers need to support some pre-standardization variants for now, but this will fade. It doesn't seem like a huge burden for browsers to support older websites for a while, and it doesn't affect new websites.

matthewmacleod 12y ago

Yes. This is down to lazy, short-sighted developers, and it makes me insanely irritated. It's ridiculously easy to make sure you include all appropriate browser-specific and generic prefixes for almost all experimental CSS features. If you use something like Compass, it's even done for you, totally transparently. Lazy developers ruin it for everybody, again. What a surprise.

mikelat 12y ago

> Looks like the webkit prefix tags are creating the new IE6. This bothers me. Webkit isn't some ancient browser that is has remained stagnant for years until google/apple decided to do something about it. Nobody spends hours debugging their perfect layouts in webkit. Webkit isn't holding the entire web back. It's just a poor comparison. I browse mobile web in mostly firefox mobile, and I don't think I've ever seen a mobile site broken on FF but working on Chrome. In fact at least Google has taken some steps to recitfy it, and they've stated they're putting experimental CSS properties behind developer flags. If we're talking about the fact that old people don't update old browsers then Microsoft is one to talk with IE7, IE8, IE9, and IE10.

untog 12y ago
The comparison is apt, just not entirely. It isn't a comparison of IE6 vs Webkit, it's of developer reactions to them. For a long time, IE6 ruled the roost, so developers used IE6 as their development target. Browsers that moved beyond it, or implemented things differently (often correctly) were ignored. On mobile, webkit rules the roost. Developers use it as their development target. Browsers that move beyond it or implement things differently (by using non-webkit prefixed CSS) are ignored.
- mikelat 12y ago
  I mentioned in another comment that when I think of IE6, I think of the hours spent fiddling with the HTML/CSS that works in FF/Chrome but not in IE6 because of browser bugs that were never fixed and standards not followed. It's why I think it's a bad comparison.
wwweston 12y ago
Most of my professional time these days is spent on mobile/tablet websites for a major automobile manufacturer. And there are days when we absolutely do obsess over layout and other issues introduced by mobile safari itself. On the release of iOS 7, we actually probably burned a month working with a bug that we never found a solution to (which, fortunately, was fixed with iOS 7.1). That last part underscores that we're fortunate browser makers are issuing regular updates (a big difference from IE). On the other hand, with some of those updates come new bugs and (particularly on Android) fragmentation. Consider that by 2006 there were enough people/resources documenting IE6's quirks that it was pretty rare to run across a bug that someone didn't have a good idea of how to fix/workaround. In 2014 when you run across a mobile bug (particularly one from a recent release, of which there are many), it may well be that nobody knows how to solve your problem, and in some cases nobody seems to even know how to tell you to duplicate it across devices/emulators (http://stackoverflow.com/questions/23142762/how-to-identify-factors-that-will-help-reproduce-web-rendering-bugs-for-android http://stackoverflow.com/questions/23142762/how-to-identify-... ). And of course, like IE, many developers code webkit-only, even iOS only (and I know why: at the level of ambition people often have for mobile websites and with the difficulty involved in testing more than a few devices, it can sometimes seem like the only way to get things out the door). IE6 was no picnic, but there are times I think to myself I'd rather be working on the 2006 desktop web than the 2014 mobile web....

Cthulhu_ 12y ago

I disagree that the webkit tags are creating the new IE 6, after all (IIRC) they're prefixed because the standards behind them aren't yet finished. On the one side I want to make a ramble about why it takes so long for those standards to finish and unprefixed CSS3 and beyond is possible, but on the other hand - without actual real-life use, how can you find all the edge-cases and practical application to create a complete standard?

talmand 12y ago
Many of these properties no longer require the prefix for most browsers. For these properties having the webkit prefix only, without the non-prefix property to cascade to, is a problem. I recall many demos, examples, and live sites not displaying as expected in Firefox because the developer decided to use only the webkit prefix. If the webkit team were to start removing the webkit prefixed properties then those sites would have even more broken views.
bzbarsky 12y ago
They're initially prefixed because the standard is not finished. Many of them are _still_ prefixed because WebKit has a policy of never removing prefixed features, even if they implement the unprefixed one. So people feel no compunction about using the prefixed stuff in production, and since they only test in WebKit they don't notice when they're using the -webkit-prefixed version even though every single browser (or every browser except WebKit, in some cases) supports the unprefixed standard version.