Because the users would complain that Apple or Google broke all these websites with the latest update.
Backwards compatibility is tricky.
Backwards compatibility is tricky.
More reading: https://groups.google.com/a/chromium.org/forum/#!topic/exper...
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.
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".
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.
Because you want the functionality that it gives.
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).
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.
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.
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.
Actually, that would result in users getting annoyed, complaining to the browser manufacturer, and switching browsers.
The goal is to discourage browser-specific content in a way that doesn't result in users switching browsers.
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.
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.
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.