Hacker News Reader

Comment by cpeterso | Hacker News Reader

The good news is no -blink prefixes! Blink, like Mozilla, will avoid shipping vendor-prefixed features:

  Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to 
  ship experimental features to web developers. This approach can be harmful to 
  compatibility because web content comes to rely upon these vendor-prefixed 
  names. Going forward ... we will instead keep the (unprefixed) feature behind
  the “enable experimental web platform features” flag in about:flags until the 
  feature is ready to be enabled by default.

View on HN

Finally!

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.

"Let's face it: developers start to rely on new features the moment they're added."

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

>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

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?

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

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

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 guess you don't remember Netscape.

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

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

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

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

Hmm, isn't it true though, for example, that without that we'd have had to wait a long time to get simple things like border-radius that were supported in all the browsers but hidden behind vendor 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 ...

Well, hopefully things might get through quicker. But that is indeed a problem.

Yes exactly.

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.

Yes! Prefixes are damaging. We're hiding things behind flags instead, which gives savvy developers the chance to experiment without the risk that sites will begin to depend on those experiments.

I, for one, can't wait to cut 20% of the code in my stylesheets.

In the meantime, you can use LESS mixins to reduce duplication. This library is pretty handy: http://lesselements.com/

The parent was likely referring to them being in the stylesheet at all, rather than the way they are managed. Any stylesheet compiler is still going to have the vendor prefixes in the compiled stylesheet.

In practice you won't actually be able to drop them from the compiled stylesheet for a very long time, of course.

Chrome has a very quick release cycle, so I don't see why not?

Webkit is used by Safari (desktop and iOS) which is still a huge portion of internet users.

right but since those "new" things won't work in chrome the hope is that devs won't implement them anywhere else.

Since every developer will want it to work in Chrome, this effectively kills vendor prefixes once and for all. It doesn't make sense for Microsoft or WebKit to continue to include them.

Sorry if I'm dense, but unlike mozilla? are mozilla css extensions not "prefixes" in this context? https://developer.mozilla.org/en-US/docs/CSS/CSS_Reference/M...

or can someone explain to me the difference?

I wonder if that's where the name came from: something any decent web developer would be ashamed to put in a vendor prefix.

they probably mean how fast it would render the page.

So the user would have to enable experimental flags (which will happen approximately never) to see advanced features? And that's supposed to be good for developers? So things like -webkit-box-reflect will no longer be supported in Chrome?

That sounds far worse to me, so I can't even use the new features as they arrive.

I couldn't care less if they add -blink, it takes minutes to push that through a modern CSS codebase. At least I can use the features where they exist.

Reply on news.ycombinator.com