Firefox css webkit update#

So, blame W3C for not being faster, but mainly blame browser developers for tacitly allowing and encouraging developers to make use of the experimental CSS properties ahead of itme for production sites. If a web developer waits for the W3C to finalize and only uses W3C recommendations, they're left hoplelessly behind the state of the art.įrom that point, it was only a matter of time before a dominant browser emerged with its proprietary prefixes became de facto standards adopted by web developers before W3C was ready to finalize their own version of them.

Also, the slowness with which W3C has historically acted to finalize their recommendations exacerbates this incentive. The prefixed CSS rules were supposed to be for not-yet finalized pre-standards versions of stuff the W3C hadn't yet finalized, to give web developers a chance to play with them, test them, and provide feedback so that when W3C finalized their recommendation, they were well tested in the real world and good.īy making them available to everyone early, it incentivized web developers who wanted their websites to look 'cutting edge' to make use of the unofficial properties before they were ready. Maybe push those into a 'developers only' mode, or an extension, but keep it out of production.

I think browser developers could all have gone a little bit further and not enabled their proprietary CSS prefixes in production releases by default. It's no surprise that one side blames the other.

Firefox css webkit update#

Really, the only ones who aren't following best practices are the developers too lazy to update their code to work with the current standards, but if we're going to blame WebKit for being too quick to support proposals, then we may as well blame the other rendering engines for being so slow that the lazy devs couldn't use their prefixed versions. They implemented a proposed standard, prefixed it as they were supposed to, and then implemented the standard version later while maintaining support for the prefixed version. Long story short, WebKit did things exactly as they were supposed to. Lazy developers implemented those properties using the prefixed property, since that's all that was available at the time, but didn't go back to fix the code afterwards when the standard was finalized. WebKit was the first rendering engine to support those properties, but it did so while the web standard was being finalized, so it prefixed those properties, as it is supposed to. Here's a list of the '-webkit'-prefixed properties.Īt least at an initial glance, it seems to me that the criticisms about WebKit being 'the new IE' are generally misplaced, since most of the listed properties are aliases for the standard versions of those properties.