[toomanythings2]

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.

[will_hughes]

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

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.

[pcwalton]

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

[hudell]

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)

[pcwalton]

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.

[toomanythings2]

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.

[gue5t]

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

[netheril96]

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

[endgame]

I like that approach: http://www.daemonology.net/blog/2016-04-11-write-opinionated...

[will_hughes]

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

[ryandrake]

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.

[cpeterso]

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

https://bugzilla.mozilla.org/show_bug.cgi?id=1170774

[kalleboo]

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

[kuschku]

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

[digi_owl]

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

[cperciva]

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.

[coldtea]

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

[MikeHolman]

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?

[pcwalton]

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.

[jsprogrammer]

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

[toomanythings2]

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.

[coldtea]

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

Because you want the functionality that it gives.

[gkya]

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.

[jsprogrammer]

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

[coldtea]

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

[lysp]

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

[coldtea]

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

[takeda]

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.

[takeda]

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.