Before anyone starts moaning about incompatibility, let's face it: developers start to rely on new features the moment they're added. Differentiating between different implementations is pointless, since CSS's design means you can specify a property multiple times and your browser will only use the one it understands. The current system also excluded other rendering engines who web developers didn't consider.
So this is a huge win for us, the developers.
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.
>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.
>"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".
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.
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.
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.
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.
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.
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.
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.
"So this is a huge win for us, the developers."
There's a contradiction here, and I'm not being cute. Your argument is not the only argument to be made, and personally, as a developer, I preferred the old way.
Yep, there are negative externalities, and that always has to be weighed, but I think it was a reasonable approach to allow developers to weigh the use of cutting edge features against their own communities, needs, and goals. That calculation would change depending on how many browsers were offering a proposed recommendation and the browser proportions of your viewers. Lots of interesting stuff was posted around the web, including here, taking advantage of these things. On the other hand, there's virtually no community for whom it would be reasonable to ask to make config changes to view a site, so you you simply can't use cutting edge features. Experimental site designs will be harder to show off and we'll have less public consideration of the implications of new recommendations since there's much less joy in putting together projects that few people will see.
Actually, HN is exactly the sort of place where people might be willing to do so. Things are posted here which require specific browsers or about:flags changes in Chrome, what would change?
Showing off demos leveraging experimental browser features that don't happen to be CSS features has often been done with requests to make config changes, because the "put it behind a config flag until it is ready" is pretty standard for everything other than CSS (and, actually, browser vendors have also done it for plenty of experimental implementations of CSS, whether or not the features themselves are standard or vendor-prefixed experimental extensions.)
Having experimental features available to developers creates pressure for all browsers to move forward. Without that we won't know what is important to developers because they'll be stuck using what the browser maker's deign to make "official".
Just playing devil's advocate here ...
The 'yay no vendor prefixes!' crew seem to have very short memories on what it was like before vendor prefixes..IE Waiting a LONG time (years) for a CSS feature to be 'recommended' by the w3c.
Vendor Prefixes were the best of a bad situation, I think they will be missed quite quickly.
I'm all up for this movement, but the W3C will need to move a lot quicker if this is to happen. Otherwise innovation will just grind to a halt again like it did before.