Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

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

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

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.

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.

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.

Good luck with that.

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.

I say again: good luck with that.

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

Try telling that to enterprise IT.

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.

also it sucks.

That's also where the anti-trust lawyers come in. And you should be grateful for them.

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.

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.

Reply on news.ycombinator.com