Hacker News new | comments | show | ask | jobs | submit login

So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes.

All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.

Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience".

Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.




>So what happens when someone introduces a new whiz bang css feature that Chrome handles badly? Something you might, as a developer, want to disable in Chrome, but leave in for everything else? Or any other browser since they're all prone to introducing flakey implementations of CSS sometimes.

>All this means is we'll have to go back to the old ways of sniffing out browsers, and I fail to see how that's better.

The situation is no different just now, because -webkit- applies to Safari, Opera and many mobile browsers, not just Chrome. :/

>Nor do I look forward to a deluge of websites prompting me to fiddle with a config to "get the full experience". Most web developers have very little sway when marketing or clients demand certain things, and this is likely to be something they demand.

"Use a modern browser [actually, Chrome] to get the full experience" is not an uncommon sight these days.


I was being polite. I'm talking about IE specifically.

>"Use a modern browser [actually, Chrome] to get the full experience" is not an uncommon sight these days.

Yup, and it's sucky. It's no different to "this site is optimised for Internet Explorer".


>I was being polite. I'm talking about IE specifically.

Well, this won't help you here anyway. By the sounds of things, features won't be enabled by default until they're ready. Things currently aren't unprefixed until they're ready. The only way to avoid IE if the feature is unprefixed is UA sniffing.

No change.

>Yup, and it's sucky. It's no different to "this site is optimised for Internet Explorer".

It's quite different, actually. Chrome is just quick at implementing web standards, they aren't dictating things and people aren't relying on proprietary APIs.


Hardly. Having a site that has buggy coding which has been tweaked to look good in IE's buggy rendering is a far cry from "our site uses cutting edge web-standard features that your browser does not support, please use a more up to date browser for a better experience". Night and day different.


No different. Were you not around when IE was the "cutting edge" and had all the newest features?


I do, quite well. Proprietary features are miles away from cutting edge web-standards. Being locked into only one browser that works correctly is very, very much different from being able to chose from among many modern browsers (in the typical case).

More so, as I said that particular problem was not nearly as bad as people targeting the rendering of their site to the particular quirks of one particular browser. That was horrible, but it's not even remotely the same problem we face today.


Ugh, I remember that time, having exactly those arguments. IE having all sorts of non-standard features, so other browsers should probably copy its quirks/bugs also.

To answer your sort-of question, that time was overshadowed when it became obvious that IE6 (and later IE7) was the absolute worst choice. And that's a reputation Microsoft is still trying to clean, years later.


I guess you don't remember Netscape.


> So what happens when someone introduces a new whiz bang css feature that Chrome handles badly?

You file a bug report on the Chrome (and/or Blink) issue tracker, and it gets fixed.

> Something you might, as a developer, want to disable in Chrome, but leave in for everything else?

Then you use user-agent sniffing to disable it, if you must. The same as you'd do for any flaky implementation of a generally-used feature in a browser. That's not really the notional purpose of vendor-prefixing, anyway (which is about not using the unprefixed name space for things which might later end up with a different standard semantics, not about making it easier for developers to avoid buggy implementation of cross-browser common features).

> All this means is we'll have to go back to the old ways of sniffing out browsers

Or only use features that are well supported across common browsers if you want to avoid browser sniffing.


and it gets fixed

You had me until that. I've had legit, simple, reproducible bugs sit in browsers for years when they're on "new" features that aren't standardized, yet somehow, every other browser that implements the same feature doesn't have the bug.

Browser vendors use the "not-standardized yet" claim to avoid fixing bugs, while still shipping those features, in my experience.


Indeed. Here's one example that's been open since Chrome 3: https://code.google.com/p/chromium/issues/detail?id=29502

Another issue with Chrome is that percentage widths are rounded or truncated to the nearest pixel, so creating three 33.3% divs won't fill 100% of the space. It makes a fluid grid difficult to create. I reported this one with the built-in bug reporter, so I don't have an issue link.


> Here's one example that's been open since Chrome 3

I'm not sure that pointing out a "known WebKit bug" (as stated in the linked issue) affecting Chrome for which the Chromium team has a patch that apparently hasn't been implemented upstream is the best example of a problem with the "post on the Chrome/Blink tracker and get the issue fixed" approach, given that that approach was offered as an approach to take to deal with issues arising after Chrome splits from WebKit specifically to stop being constrained by WebKit from making changes.


That is a bug in WebKit and they've submitted patches upstream even...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: