Hacker News new | past | comments | ask | show | jobs | submit login
WebKit is moving away from prefixes (webkit.org)
304 points by om2 on April 26, 2016 | hide | past | favorite | 72 comments

It's nice to see WebKit adopt this approach too. Chrome and Firefox have already had a policy against new CSS properties with vendor prefixes for over three years, so with Safari onboard too now it's becoming easier to imagine a future where web developers won't have to worry about writing code with prefixes anymore. The only potential reason to use them will be compatibility with older browser versions.

Technically, web developers should never had to have worried about writing code with prefixes - prefixed properties were never intended to be used for production apps. :)

Yeah right. web devs (and sadly also other devs) are like magpies, always hunting for that latest shiny to add to their nest.

Border radius with prefixes instead of with images felt elegant and simple and not shiny at the time (relative to what we were replacing).

Yeah. 4 - 5 lines of CSS far out strips 4 corner images and several extra divs, the typical implementation.

Agreed, I would also say it's often not just the devs who build the requirements, hard to say something is impossible / not a good idea to implement when it's everywhere.

And all those hours spent on A List Apart's "sliding door" tutorial for rounded corners

The problem is that "production" can have varying levels of tolerance to cutting edge features depending on who the audience is. Sometimes you know all your people are Chrome users, or IE10 users, or developers with the latest browsers, etc.

And then it stays in production way way beyond the life time of your target audience, and we have ourself a IE6 situation all over again...

We do, it's the IE9 situation!

I was looking at our browser metrics the other day and it's yet to drop below the arbitrary 5% usage figure we use to fully deprecate browser support. We are a public facing site, and not particularly niche.

It's hovering around there, but if a user is still clinging to ie9 it's highly likely they don't have the ability or requirement to upgrade.

When ie9 legacy support drops my biggest headache will be ie10's squiffy flexbox support.

Having to support ie10 isn't the worst thing in the world. I was surprised when it was released because it was the first time I had ever marked up a page and it worked across all 4 browsers almost pixel perfect without any hacks or tweaks.

You should only really need to worry about IE10 if you have users on Windows Server 2012 baseline, whom should have likely already upgraded to R2 or more recent. Lifecycle support jumps to 11 on most OSes, yay!


If only :(

IE10 is a non-trivial portion of our desktop traffic, not to mention Trident's hateful mobile incarnation, which still turns up from time to time.

IE9 is the highest available on Vista, and Vista is still in extended support until April 11, 2017.

I'm planning a party for that date.

The problem is not the tolerance to cutting edge, it's that the original point of prefixed properties was they were unstable and could be changed slightly or completely. Once you've shipped to production that's dead, there's no guarantee you'll update it.

I was not even aware that safari is a exception here. I just did not use prefixes since about beginning 2015.

And still Chrome requires us to use -webkit-animation even today.

Chrome hasn't required a prefix on animation since Chrome 43. (mid-2015)

Should always use an auto-prefixer anyway, but your point is still valid.

I don't understand: If there is a spec that says, hey, this prefixed stuff will get removed sooner or later, use the non prefixed variant along with the prefixed so that it does not hurt you, and some people use only the prefixed variants, why would the browser vendors be bothered to not break their code, and keep stuff that needs to be removed, around?

Harm reduction. As it turns out, it's really easy to stick your fingers in your ears and go "the spec says X so tough cookies", but in the real world decisions tend to be made based on actual user impact, and the impact of killing the prefixed variant for some things would be rather large because there are a lot of developers that made decisions which didn't match the intent of the spec.

The flip side of this approach is that this way bugs get enshrined in standards and stay with us forever. As the apocryphal story story goes, by the time the author of Make discovered his coding error he already had ~10 users, so he decided not to bother fixing it - and now, 39 years later, we still have to be careful to use only TABs and not spaces before commands in our Makefiles.

That story would have been better if it had a real mistake.

Because the users would complain that Apple or Google broke all these websites with the latest update.

Backwards compatibility is tricky.

It looks like there may be better options for experimenting without the risk of getting locked in. I believe that Chrome is trying something along these lines: https://infrequently.org/2015/08/doing-science-on-the-web/

More reading: https://groups.google.com/a/chromium.org/forum/#!topic/exper...

Why aren't these properties hidden under a feature/config flag or otherwise gated?

That's exactly the policy that Webkit is adopting from now on.

Backwards compatibility doesn't apply here because, by definition, prefixed properties are supposed to go away and the intention of them is to go away. Only dumb developers continue to use such things once a standard property is available so it's their own fault if they don't do that.

> Only dumb developers continue to use such things once a standard property is available

There are a LOT of sites which once they get deployed, almost never get touched again. Either because they have no developers available or due to lack of time/interest.

So, what was a good way to achieve X at the time the site was developed is no longer be great five years later.

If they can't be bothered to fix their code, then those web sites surely wouldn't mind if browsers eventually started popping up a dialog that says "This web site content may be abandoned or no longer supported by [domain]. Proceed with caution!" upon loading outdated code. That would be one way to handle this and direct user complaints to the right party.

> That would be one way to handle this and direct user complaints to the right party.

Actually, that would result in users getting annoyed, complaining to the browser manufacturer, and switching browsers.

But if the site used prefixed css, it's possible that no other browser would render the site properly anyway (many sites these days are made with just chrome/safari in mind)

Yes. What users do upon encountering such a site is to switch to Chrome or Safari.

The goal is to discourage browser-specific content in a way that doesn't result in users switching browsers.

The only developers who make sites that work just in Chrome or Safari are rank amateurs. No professional would do such a thing. Professionals understand that a web site must work for all visitors and I have never heard of any web site that would do otherwise. To me, this is only an internet rumor and not based in reality.

The only exception would be when one particular feature is needed to display one specific, unique element. Off the top of my head, I can't think of what that would be.

It would be great if we could also make media like books, music, and movies completely unusable five years after publication.

And eventually the user will ditch the browser instead of the website if the website solves any real problems for them.

There's a big difference between changing compiler tools, and showing stuff to end users who likely have no idea what the hell is going on, and we'll just have more of these[1] situations. (Even if it's a fake comment, it's close enough to real responses from people)

Most of the sites in the world are run by people who have little to no understanding of the internet beyond the most basic "series of tubes" aspect.

If you're going to break something because you don't want to support backwards-compatibility any longer, break it in the least obnoxious way possible.

[1] https://i.imgur.com/SL88Z6g.jpg

There will always be non-technical users. The trick is to focus their frustration on the parties they should be frustrated with. Take for instance those screens browsers present when you try to visit a website with dodgy security. These are universally awful user experiences and users likely have no idea what the hell is going on, but browsers do it anyway for the users' benefit and for the long-term health of the web. When users encounter these warnings, they don't think "Oh jeez, Firefox sucks so much" they think "I better get the hell out of here and not visit this web site anymore".

I'd argue that more strict adherence to standards and rejection of old, deprecated code is better for users because it's better for the long-term health of the web as a platform. The effort spent maintaining a mess of unnecessary backwards-compatibility (particularly with things meant to be temporary from the start) is effort that would be better spent providing actual value for users in the form of quality improvements, better performance, and features.

Mozilla has reluctantly begun implementing some -webkit- prefixed APIs and CSS properties (i.e. mapping the prefixed name to the standard unprefixed name) to improve compatibility for mobile websites that assume all mobile browsers are some version of WebKit (including Blink).


Aaaand we're back to the good old days of "Mozilla 3.0 (compatible; IE)"

Firefox Mobile has many cases where it even uses Chrome's UA already.

Meaning we have come full circle, only being barely better off as webkit is open source...

This comment was flagged away, probably due to the reference to "dumb developers". Please don't use such language here; it's inappropriate and not welcome on Hacker News.

I've vouched for your comment because I think you were making an important point, but please choose your words more carefully in the future.

>Backwards compatibility doesn't apply here because, by definition, prefixed properties are supposed to go away and the intention of them is to go away.

Only it doesn't work like that. Once it's there and used, it's there -- and whether it was meant or not, nobody gives a flying duck about.

That is the ideal world. But a lot of web developers don't do this. And who is going to get blamed when websites that used to work (and work in other browsers!) suddenly stop working after a browser update?

That's all well and good, but in practice what happens is that the users of browsers complain and then switch to another browser because sites are broken.

The problem with prefixes is that they are supposed to go away.

Why do I want stuff that is "supposed to go away" in my code?

I'd rather just "not have it in the first place".

You are right. The vendor prefixes are there to introduce new properties that they hope will be implemented in the standard. All those prefixes can change or disappear altogether and without notice.

However, this is a way for a browser vendor to test their code in real life. If it fails, they can change the prefix and try again till they get it right. You can't do that once it's standardized. In fact, there are a number of properties that have been implemented incorrectly and still exist today but were eventually fixed in the non-prefixed property.

But a developer is to then remove the prefixed property. Not complain about it and blame others for their decision to use it in the first place.

>Why do I want stuff that is "supposed to go away" in my code?

Because you want the functionality that it gives.

The Web was certainly working before that functionality, which should be considered beta feature anyways, and you could've waited till it was standardised. If we'll support each and every lousy developer on the world, things will surely get more complex and dirty. And no user will ditch a browser for some css not working, they'll use the other browser temporarily for that website. Throughout this thread people consider users as lousy, nagging, complaining, brain dead people that jump from one browser to another, but this is not the case. They're as smart as each and every dev here, they just don't know programming. I guess what's going on is that devs and amateurs make lousy stuff and go singig the song of the infedele users because they don't want to fix their things.

But without prefixes, I wouldn't need to change anything and could still get the functionality.

Not exactly, as the functionality is experimental and subject to change. That was the whole point of the prefixes.

Syntax and behavior of css changed between proposals and early drafts of a new feature and the final result.

So without prefixes you'd have a single "XXX" CSS name that might get deprecated altogether (eg the name ends up XXY) or be defined to have different behavior (e.g. it remains XXX, but not it also makes the element bold rather than just italic).

That's his point - The functionality should be there in the first place.

Then he wouldn't have said "I'd rather just "not have it in the first place".

Totally agree. IMO they probably would be better off if they left the original behavior, but every time prefixes are used (whether they work or not) browser would just display a watermark in a corner saying that website is using experimental features that are not standardized yet and could appear broken.

I see this is not a popular opinion, could someone at least mention why?

An experimental feature is experimental, it might change it might disappear. I think my suggestion is still better than not being able to see its effects by default. A note in the corner also is less annoying than a message popping up when page is about to be viewed.

It's sad. Finally, after ~2 decades of the Web (very analogous to OpenGL btw), we've finally learned that having layer 1 (browser or driver) and layer 2 (graphics program, website) both hack around mistakes in the other leads to developer pain and chaos. So we all wish we had been strict as you propose from day 1.

Now for better or worse, people still don't want to suddenly "break" the things that were actually broken all along. But thankfully we also don't want to add any more leniency with new features. So this is basically an example of the browsers declaring "no new hacks" and promising to slowly clean up the hacks that exist.

And then in a few years someone will say "web browser are too complicated and strict, let's build something better for beginners on top of it"

You Won't Believe How Fast Your Computer Is With This New 'Native' Technology.

Yeah I'd love to see the Vulkan approach taken.

The arguments sound good, and there is obviously a lot of frustration that led to this, but:

Will this mean that new features will take even longer to come out? What about features that aren't standardized, or in very early stages, heck, safari has lots of css properties that aren't even close to being implemented (such as -webkit-overflow-scrolling ).

Taking this route, either a browser can't implement something that isn't standardized, or when it is standardized, it'll be incompatible with a future standard (think flexbox and it's thousand implementations).

We could end up worse, to prevent sites from breaking, the standards body will choose a different property name for things browsers implemented before standardization, which means we'll get the same effect as vendor-prefixes but without readily visible names.

You can look at chrome's behaviour for the last couple of years to get an idea of how this might play out. Basically, the big browser vendors are the new standards bodies, and the w3c/whatwg plays catch up with what the browsers are implementing. If three browsers all agree to implement something, it gets implemented without waiting to hear what a standards organization says, and then it gets documented in a standard later on.

This struck me as a very concise, well-written description of a change. Good description of what happened, why, and what it means for you.

Does this mean we can no longer use cutting edge tech in production?

for example border radius gained wide and reliable use in production while it was still a prefix. And that was a good thing, every other way of implementing border radius was a hacky mess.

Would this be a bad thing in the scenario one browser didn't implement the property properly? The webkit implementation could work fine but look awful on IE for example, which then you would simply not include it in IE.

Not really, because the features need to be explicitly enabled. Nobody will use these in production if it requires a user to change a setting in their browser for it to work.

Potentially yes, this is why prefixes were created. But in practice I haven't run into any issues like this since the IE6 days.

I wish they would move towards numbered "feature prefixes" e.g.

-feature555-flex-direction: column;

so that:

1. a browser vendor can introduce a feature and have it used even as an experiment

2. another browser vendor can decide to implement the same draft spec

3. if an incompatible change is made to the spec (flexbox!) then change the feature number

4. they should always be documented per feature (like RFC's).

I don't think browser maintainers want to support -feature1-flex-direction all the way though to -feature555-flex-direction, in fact I don't think they want to support their failed experiments at all, after the experiment is done

this solution is trying to reduce the reliance on experimental features, not increase it!

Obviously not.

The idea is that RFCs get written for each feature and are numbered.

They then get put out to see if they survive in the real world.

Unpopular features can be exterminated (falling back to whatever CSS is set up for browsers that never had that feature).

Most importantly alpha features can be implemented by many browsers, or removed, without confusion.

This is what nightly and beta releases are for. If a feature is ready for production, is ready for no prefix and to be supported indefinitely, as anything released in production must be.

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