7 ms·
WebKit is moving away from prefixes
- gkya 10y agoI 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?
- univerio 10y agoBecause the users would complain that Apple or Google broke all these websites with the latest update. Backwards compatibility is tricky.
- toomanythings2 10y agoBackwards 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.
- takeda 10y agoTotally 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.
- takeda 10y agoI 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.
- jsprogrammer 10y agoThe 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".
- toomanythings2 10y agoYou 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.
- coldtea 10y ago>Why do I want stuff that is "supposed to go away" in my code? Because you want the functionality that it gives.
- lysp 10y agoThat's his point - The functionality should be there in the first place.
- coldtea 10y agoThen he wouldn't have said "I'd rather just "not have it in the first place".
- jsprogrammer 10y agoBut without prefixes, I wouldn't need to change anything and could still get the functionality.
- 10y ago
- cpeterso 10y agoMozilla 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). https://bugzilla.mozilla.org/show_bug.cgi?id=1170774 https://bugzilla.mozilla.org/show_bug.cgi?id=1170774
- will_hughes 10y ago> 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.
- ryandrake 10y agoIf 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.
- endgame 10y agoI like that approach: http://www.daemonology.net/blog/2016-04-11-write-opinionated-workarounds.html http://www.daemonology.net/blog/2016-04-11-write-opinionated...
- will_hughes 10y agoThere'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 https://i.imgur.com/SL88Z6g.jpg
- ryandrake 10y agoThere 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.
- MikeHolman 10y agoThat 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?
- coldtea 10y ago>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.
- pcwalton 10y agoThat'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.
- cperciva 10y agoThis 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.
- MichaelGG 10y agoWhy aren't these properties hidden under a feature/config flag or otherwise gated?
- quanticle 10y agoThat's exactly the policy that Webkit is adopting from now on.
- rictic 10y agoIt 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/ https://infrequently.org/2015/08/doing-science-on-the-web/ More reading: https://groups.google.com/a/chromium.org/forum/#!topic/experimentation-dev/GsPtuFt8XqA https://groups.google.com/a/chromium.org/forum/#!topic/exper...
- aiiane 10y agoHarm 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.
- TeMPOraL 10y agoThe 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.
- paulddraper 10y agoThat story would have been better if it had a real mistake.
- Ericson2314 10y agoIt'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.
- kuschku 10y agoAnd 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"
- mynewtb 10y agoYou Won't Believe How Fast Your Computer Is With This New 'Native' Technology.
- Ericson2314 10y agoYeah I'd love to see the Vulkan approach taken.
- timothya 10y agoIt'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.
- aiiane 10y agoTechnically, web developers should never had to have worried about writing code with prefixes - prefixed properties were never intended to be used for production apps. :)
- sdegutis 10y agoThe 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.
- digi_owl 10y agoAnd 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...
- ry_ry 10y agoWe 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.
- 10y ago
- dyscrete 10y agoWould 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.
- Raticide 10y agoPotentially yes, this is why prefixes were created. But in practice I haven't run into any issues like this since the IE6 days.
- treve 10y agoNot 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.
- Illniyar 10y agoThe 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.
- notatoad 10y agoYou 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.
- rattray 10y agoThis struck me as a very concise, well-written description of a change. Good description of what happened, why, and what it means for you.
- robocat 10y agoI 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).
- RubyPinch 10y agoI 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!
- robocat 10y agoObviously 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.
- grey-area 10y agoThis 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.
- demarq 10y agoDoes 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.