Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox Will Support Non-Standard CSS For WebKit Compatibility (theregister.co.uk)

Posted by samzenpus on from the making-it-work dept.

RoccamOccam writes: Mozilla developers have discussed a plan to implement support for a subset of non-standard CSS prefixes used in WebKit. Mozilla developer Daniel Holbert says: "A good chunk of the web today (and particularly the mobile web) effectively relies on -webkit prefixed CSS properties & features. We wish we lived in a world where web content always included standards-based fallback (or at least multiple-vendor-prefixed fallback), but alas, we do not live in that world. To be successful at rendering the web as it exists, we need to add support for a list of frequently-used -webkit prefixed CSS properties & features."

1 of 132 comments (clear)

  1. The list of prefixed properties by Anubis+IV · · Score: 5, Informative

    Here's a list of the "-webkit"-prefixed properties.

    https://compat.spec.whatwg.org...

    At 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. I.e. 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. 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.

    Long story short, WebKit did things exactly as they were supposed to. 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. 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. Two sides of the same coin. It's no surprise that one side blames the other.