[lmorris84]

Can someone who does more UI work than me explain why you would want to future proof css like this in the first place?

Even forgetting the undesired outcome and lack of testing, it's css...if browsers implement this feature, release it when the time comes. Not sure what's to be gained from adding something like this now. Feels like over thinking the issue a little.

[WorldMaker]

Today's browser development preference/"wisdom" is to always include the unprefixed CSS even if you include a vendor prefixed version. The reasoning for this is the realization that maybe vendor prefixes were a bad idea all along. For better or worse, there are a bunch of -webkit prefixed CSS terms that will likely live on the web "forever". So the decision has been (by Edge and Blink [Chrome, Opera], at least) that instead of vendor prefixes browsers should use experimental flags (that are off by default) and unprefixed CSS. (This way devs can still test and evaluate new features, but are much less likely to litter the web in the wild with such experimental features as they'd have to explain to users how to turn the flags on.)

Of course today's wisdom may also be tomorrow's folly and the winds could change again, but I think a lot of us would prefer to forget that vendor prefixes ever happened and not worry about prefixing/autoprefixing/prefix-fixing ever again, so I for one appreciate today's wisdom. Even if we do find weird edge cases in Apple's choices with regards to vendor prefixed CSS.

[Eric_WVGG]

I don’t understand this perspective at all. If transitions and transforms had been introduced this way, it would have taken many years longer for them to bleed into commonplace use. No normal user is going to jump through the hoops necessary to turn experimental flags on.

The blink tag disappeared, table-driven design disappeared, unnecessary vendor prefixes will gradually disappear too. That's a small price to pay for progress.

[WorldMaker]

> No normal user is going to jump through the hoops necessary to turn experimental flags on.

That's the feature, it's not a bug.

It's a technical debt issue for the web. Some of those early -webkit prefixed CSS features changed between when the prefixed version was introduced to Webkit and the final spec. Because enough of the old version exists in the wild on the web, the nonstandard versions effectively have to be supported forever or someone's aunt's favorite website mysteriously breaks.

Ultimately the change here is to trust in the standardization process. We, as the web development community, can solve the root cause problem: standards take too long from proposal to "recommendation". We don't need to use the hack of using experimental/prototypal/unfinished features for years, if we can speed up the process for features the web wants.

The benefit of a little bit of patience (or the usage of smart polyfills) with respect to the latest and greatest features is hope for a better web where we can all spend less time worrying about cross-browser quirks like which vendor prefixes are supported/not-supported and whether or not they use some ancient nonstandard form.

[bhrgunatha]

I also found that very odd.

After all it's just a text file that can be edited and re-deployed rapidly. It's not like a library that needs to be compiled or linked or forcing re-compilation of other dependent software.

Their fix to the problem after all was just to edit the self same stylesheet and re-deploy!

[LoSboccacc]

> It's not like a library that needs to be compiled

with the craze of css preprocessor I wouldn't bet on this

[nandhp]

Because five years down the road, nobody wants to have to remember to stick that in when the vendor-specific version is removed.

An example of someone who didn't do this: https://bugzilla.mozilla.org/show_bug.cgi?id=765645

[ssmoot]

I think the future-proofing was just a "why not?" bonus. The real goal was just to render with system fonts so the page felt as native as possible and they got to take advantage of all the person-hours put into the choice by the OS vendors.

But the fonts do change on occasion, so it makes sense to me, for forwards and backwards compatibility, you'd ideally just want to be able to say "render whatever font the rest of the system is using".