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:
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.
Is this really how it works? I know many do go solely with the -webkit or -moz property name to experiment with new features but for any site that's important (not an experiment, needs decent cross browser support) what I see happening is that most developers will do it the right way - they'll use all the available prefixes and end with the eventual standard property name while at the same time ensuring that use of these new features doesn't look completely broken in browsers that don't support the prefixes or non-prefixed version.
It's very rare that I'll see a developer code in such a way that they totally leave out a fallback or code with just one browser in mind. At least not when it comes to any site of importance (these include any site meant for a large audience, non-techies, business, and just generally not a site put together purely for showing off the uses of an experimental feature).
I didn't know Blink was going that route too. I fear that the use of new experimental features will stagnate if Chrome becomes too popular among non-techies.
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).
Lucky you. Investment banking compliance software here. IE8 and little else every-'king-were...
If I ever win the lottery I'm taking out full page ads in the national newspapers asking the general public if they know how stupidly out of date certain banks are internally and asking it it fills them with confidence or not!
>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.
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).
You're going to have lots of fun losing 25% of your customers (more or less depending on regional IE usage), many of them companies with oodles of cash. Heck, here IE usage is 14% while Firefox is 31% and Chrome 47%, according to StatCounter. Not as bad as the US, but still a huge piece of the pie.
Sure, it makes technical sense - IE sucks (well IE 9 and 10 are much better, but still).
It makes NEGATIVE NINE THOUSAND business sense - you've got to be crazy to refuse to support IE 8+.
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.
Someone did a calculation and decided that the business cost of supporting IE was worth the additional customers. It's not about balls, it's about cost benefit analysis. Us developers just hate IE because it's so different than all the other browsers.
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.
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.
I remember this from the the original hacker news thread and still use it. Anything 'real' gets custom rendered icons for each size, but for side projects where the icon quality isn't critical it's very convenient.
Looks useful, thanks for the link. In case its news to you, with iOS7, a few more suggested dimensions have been introduced than what is available on allthefavicons.com at the moment. More details at the cheatsheet.
Don't you always want your favicon at / regardless because everything that grabs favicons automatically will look there, and not parse your /index.html to figure out what the meta tag is?
That's what I thought too, until I did more research on ICO and couldn't come up with an answer for "Why use png in addition to ico?" in the FAQ (well, except for touch devices where ico isn't supported). Notice how that FAQ question is empty.
But if you could submit a pull request with a bulleted list of PNG advantages over ICO, I'd be happy to include it. Seriously.
PNG support was introduced to .ico format alongside Vista in ~2006, you can certainly use it as a multiple-png-only format.
Wikipedia has a description of the file format and it's certainly not the worst i've seen - restricting yourself to only PNG images removes all the mess around skipping bmp headers and paletted colours, you end up with a very short and concise header and binary list format, and it should be trivially implemented from the description.
Of course, i havn't implemented it myself, so it's obvious i'd say that. But i'm curious as to what issues you have with it / what you would change?
Could not believe we should be considering giving so many different favicon sizes from 195px (Opera Speed Dial) down to 16px. Wider SVG support in favicons would be welcome.
I believe SVG still has no support for hinting (or not enough to be worth talking about).
Because of the resolution range, either extremely strong rasterizer hinting (supporting not only pixel-snapping but the complete addition or removal of features and the like) or multiple bitmaps is necessary to avoid getting either blocky output at "high" resolutions or a blurry and unusable mess at low ones. You can see the issue by comparing OSX's actual Pictures folder icons[0] with what you get just by scaling the biggest icon down[1] or the smallest one up[2]. [0] looks good and recognizable at all sizes, [1] is a blurry mess from 32px down and [2] looks terrible above 32px (and not too good at 32px either).
And even at constant resolution, different densities (and thus different physical sizes) require different levels of details: Opera puts 195px in up to 4.5~5cm (as far as I can see by opening Opera, maximizing it and looking at the speed dial screen) where an iPad puts 144px (152 in iOS7) in about 1cm (not measured as I don't have one, if somebody can provide the exact dimensions of app icons it would be great). You can't[3] put precise information in an iPad icon as most users will be unable to see it, whereas a huge icon and nothing else would be a waste of space on Speed Dial.
[3] well you can, and it makes for great easter eggs, Apple's icon designers — amongst others — are known to have great fun with that[4], but I'm sure you get the point
Why don't we have mipmapping on the web? I've never heard anyone suggest it before, but it seems like a good solution to this problem and all the other pixel ratio kinds of problems.
If you mean ability to supply several, potentially hand-crafted images for different sizes — that's exactly what .ico already offers.
If you stick to the precise definition of mippmapping, where they're exact downscalings of one texture, that solves a different problem — efficient downscaling, only sampling O(1) texture pixels per displayed pixel.
On the web CPU isn't the problem; there are 2 other reasons so serve several sizes:
(1) Tiny images (like favicons) don't scale well, you might want manual intervention.
(2) Too large images waste bandwidth => you want negotiation, especially to transmit less to mobile devices.
.ico was a quite elegant solution to (1) actually. I guess all the mess comes from icon resolutions growing enough to turn the problem into (2)...
There several efforts to solve this generally — google "Responsive Images", "srcset".
I'd think progressive JPEG and PNG could have solved (2) well — just stop downloading when you had enough quality — but many people say that's not enough :-(
This is exactly what I do, too. I've got the Bookmarks Toolbar in Firefox with just favicons all the way across. I don't need the text alongside and prefer to remove it to fit more icons instead.
