WebKit is moving away from prefixes
webkit.org
webkit.org
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.
I'm planning a party for that date.
https://support.microsoft.com/en-us/lifecycle#gp/Microsoft-I...
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.
Backwards compatibility is tricky.
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.
More reading: https://groups.google.com/a/chromium.org/forum/#!topic/exper...
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.
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.
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.
-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).
this solution is trying to reduce the reliance on experimental features, not increase it!
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.