4 ms·

This collection of vendor-specific hacks is an excellent demonstration of the failure of the Web standards process.

bpatrianakos 13y ago
I disagree and believe there is more upside to this than downside. You certainly can't say that the fact that different browsers and devices handle favicons differently is a standards issue. If you were to try to standardize this then we'd end up with either a very large and complex standard (close to what we unofficially have now) or a lack of innovation. Innovation isn't the exact right word I'm searching for but what I'm getting at is that forcing vendors to use set sizes and naming conventions would detract from some of the small but important UI and even hardware differences in devices and browsers. iOS had the retina display with mobile safari first, then came Microsoft's metro interface which brought tiles and going forward we're probably going to see many more devices and browsers that handle some aspects of web resources differently and for good reason. We can't expect the web standards committees to be able to account for all of these advances as fast as they come about and I'd argue that's exciting and good. Furthermore I'd say web standards already do take care of this in the most elegant way I can think of. The <link> tag is totally standard and future proof when it comes to favicons. I don't see anything wrong with adding a link tag with standard attributes to support multiple devices here. The purpose of a favicon is to associate a small image with a website or URL in general. Not all sites need the apple-touch icon or windows tile but some do. What we're seeing here is an attempt to target specific browsers on specific devices for very specific cases. By and large the standard desktop browser favicon has never changed. When you take all that into consideration I think its actually quite reasonable for these different methods of specifying favicons to exist. I'll grant you that adding all that in your markup is ugly and having to think about which devices you want to target is a pain especially once you've decided on it and then have to start thinking about which markup to use and in what order. Still, this isn't a case where vendors are using proprietary markup to capture more of the market or doing anything "evil". It's more a case of using an existing standard to take advantage of a specific device capability. Standardizing the way web/markup languages are handled is good but trying to standardize favicons in this context seems like an awkward way of trying to standardize how a device and/or browser and/or OS handles its UI and is not good. Edit: I can't think of a good way we can standardize this but I am curious if there's anyone out there that has a decent idea for how we can standardize how we specify favicons for the plethora of devices we have now and will continue to see going forward.
evmar 13y ago
Historically, the web standards process was theorized to work like: 1) vendor introduces new feature, tagged with vendor name to not pollute the namespace (e.g. -webkit-foo, or msapplication-TileColor from the OP) 2) once feature becomes popular enough to warrant its permanence, vendors agree on some new standard name for the agreed-upon behavior 3) ??? 4) everyone uses the new standard name The problem with this idea is that step 3 is missing. Browsers can't drop their -webkit CSS support because old pages rely on it, and new pages still use -webkit to work on old browsers. The original name is effectively permanent so there's little incentive to even take step 2, because all that produces is two names for the same thing (e.g. you use an attribute with "apple" in the name to choose the Android icon). In recognition of the failure of this process, Blink (and other browsers) is using a different approach, where new features are not namespaced; instead, they'll require users to individually opt-in to nonstandard features, under the idea that it's hard for an idea to become permanent if it requires each user to individually configure their browser: http://www.chromium.org/blink#vendor-prefixes http://www.chromium.org/blink#vendor-prefixes I am a little skeptical that this will only result in going too far the other way -- new features will wither because you can't experiment with them enough to get enough mass behind them to standardize them -- but at least it's not retreading the known broken path.
- ftwinnovations 13y ago
  5) wait another 7 years for IE to implement it, with their own "twist". 6) wait another 5 years for IE to properly implement it.
  - leokun 13y ago
    I haven't tested nor cared how something appears in IE in years. Since like 2009. I have worked on major frontends for a couple of big companies all this time and recently a startup. IE is the new opera. IE needs to make sure that everything works. It may have large marketshare, but it's the market that's irrelevant to anything I've worked on (IT and business related tools and control panels).
    - 13y ago
crazygringo 13y ago
Exactly. Reading the whole document, and realizing I already knew every single piece of information in it, almost made me want to cry. The fact that I've spent so much time accumulating knowledge that, in the end, is such garbage. But at least I've had the luxury of accumulating it slowly, over what has been, by now, almost 20 years. I can't even imagine showing this page to someone getting started in web development. They'd think the whole thing was designed by insane people.
javajosh 13y ago
>an excellent demonstration of the failure of the Web standards process After reading the wikipedia article, it appears that IE is the only browser that doesn't support the W3C standard. It's high time to stop supporting the monstrosity that is IE. All webapps and websites should be built for standards-compliant web browsers, and prompt the user to install one if they are on IE, and simply refuse to work otherwise. The success of the web standards process is in users hands, and what users do is in developers' hands.
- cmircea 13y ago
  Good luck with that.
  - javajosh 13y ago
    Why is it so unlikely? The simple fact is that demand for the internet is inelastic. There is no good reason to not install Firefox. It is open-source, standards-compliant, more secure, as fast (if not faster) than IE. All it takes is for companies to say no - you have to spend 5 minutes installing a different browser (and you'll be glad you did). Time to grow some balls.
    - joseph_cooney 13y ago
      Try telling that to enterprise IT.
      - javajosh 13y ago
        Let's say Google said it. "If you want to use Google, then you need to stop using IE." There would be some complaining, but they'd get it done. That's where the "balls" part comes in: you have to tell your users, that you just don't support their platform. Happens all the time, but for some reason browsers are treated specially and we all live in fear of losing the IE market share.
        bobbydavid 13y ago
tagawa 13y ago
Failure? There may be problems with the Web standards process but I don't think it could be classed a failure.

I disagree and believe there is more upside to this than downside. You certainly can't say that the fact that different browsers and devices handle favicons differently is a standards issue. If you were to try to standardize this then we'd end up with either a very large and complex standard (close to what we unofficially have now) or a lack of innovation. Innovation isn't the exact right word I'm searching for but what I'm getting at is that forcing vendors to use set sizes and naming conventions would detract from some of the small but important UI and even hardware differences in devices and browsers. iOS had the retina display with mobile safari first, then came Microsoft's metro interface which brought tiles and going forward we're probably going to see many more devices and browsers that handle some aspects of web resources differently and for good reason. We can't expect the web standards committees to be able to account for all of these advances as fast as they come about and I'd argue that's exciting and good. Furthermore I'd say web standards already do take care of this in the most elegant way I can think of. The <link> tag is totally standard and future proof when it comes to favicons. I don't see anything wrong with adding a link tag with standard attributes to support multiple devices here. The purpose of a favicon is to associate a small image with a website or URL in general. Not all sites need the apple-touch icon or windows tile but some do. What we're seeing here is an attempt to target specific browsers on specific devices for very specific cases. By and large the standard desktop browser favicon has never changed. When you take all that into consideration I think its actually quite reasonable for these different methods of specifying favicons to exist. I'll grant you that adding all that in your markup is ugly and having to think about which devices you want to target is a pain especially once you've decided on it and then have to start thinking about which markup to use and in what order. Still, this isn't a case where vendors are using proprietary markup to capture more of the market or doing anything "evil". It's more a case of using an existing standard to take advantage of a specific device capability. Standardizing the way web/markup languages are handled is good but trying to standardize favicons in this context seems like an awkward way of trying to standardize how a device and/or browser and/or OS handles its UI and is not good. Edit: I can't think of a good way we can standardize this but I am curious if there's anyone out there that has a decent idea for how we can standardize how we specify favicons for the plethora of devices we have now and will continue to see going forward.

evmar 13y ago

Historically, the web standards process was theorized to work like: 1) vendor introduces new feature, tagged with vendor name to not pollute the namespace (e.g. -webkit-foo, or msapplication-TileColor from the OP) 2) once feature becomes popular enough to warrant its permanence, vendors agree on some new standard name for the agreed-upon behavior 3) ??? 4) everyone uses the new standard name The problem with this idea is that step 3 is missing. Browsers can't drop their -webkit CSS support because old pages rely on it, and new pages still use -webkit to work on old browsers. The original name is effectively permanent so there's little incentive to even take step 2, because all that produces is two names for the same thing (e.g. you use an attribute with "apple" in the name to choose the Android icon). In recognition of the failure of this process, Blink (and other browsers) is using a different approach, where new features are not namespaced; instead, they'll require users to individually opt-in to nonstandard features, under the idea that it's hard for an idea to become permanent if it requires each user to individually configure their browser: http://www.chromium.org/blink#vendor-prefixes http://www.chromium.org/blink#vendor-prefixes I am a little skeptical that this will only result in going too far the other way -- new features will wither because you can't experiment with them enough to get enough mass behind them to standardize them -- but at least it's not retreading the known broken path.

ftwinnovations 13y ago
5) wait another 7 years for IE to implement it, with their own "twist". 6) wait another 5 years for IE to properly implement it.
- leokun 13y ago
  I haven't tested nor cared how something appears in IE in years. Since like 2009. I have worked on major frontends for a couple of big companies all this time and recently a startup. IE is the new opera. IE needs to make sure that everything works. It may have large marketshare, but it's the market that's irrelevant to anything I've worked on (IT and business related tools and control panels).
  - 13y ago

crazygringo 13y ago

Exactly. Reading the whole document, and realizing I already knew every single piece of information in it, almost made me want to cry. The fact that I've spent so much time accumulating knowledge that, in the end, is such garbage. But at least I've had the luxury of accumulating it slowly, over what has been, by now, almost 20 years. I can't even imagine showing this page to someone getting started in web development. They'd think the whole thing was designed by insane people.

javajosh 13y ago

>an excellent demonstration of the failure of the Web standards process After reading the wikipedia article, it appears that IE is the only browser that doesn't support the W3C standard. It's high time to stop supporting the monstrosity that is IE. All webapps and websites should be built for standards-compliant web browsers, and prompt the user to install one if they are on IE, and simply refuse to work otherwise. The success of the web standards process is in users hands, and what users do is in developers' hands.

cmircea 13y ago
Good luck with that.
- javajosh 13y ago
  Why is it so unlikely? The simple fact is that demand for the internet is inelastic. There is no good reason to not install Firefox. It is open-source, standards-compliant, more secure, as fast (if not faster) than IE. All it takes is for companies to say no - you have to spend 5 minutes installing a different browser (and you'll be glad you did). Time to grow some balls.
  - joseph_cooney 13y ago
    Try telling that to enterprise IT.
    - javajosh 13y ago
      Let's say Google said it. "If you want to use Google, then you need to stop using IE." There would be some complaining, but they'd get it done. That's where the "balls" part comes in: you have to tell your users, that you just don't support their platform. Happens all the time, but for some reason browsers are treated specially and we all live in fear of losing the IE market share.
      - bobbydavid 13y ago

tagawa 13y ago

Failure? There may be problems with the Web standards process but I don't think it could be classed a failure.