Slashdot Mirror


W3C Member Proposes "Fix" For CSS Prefix Problem

Pieroxy writes "The W3C is proposing a set of new rules for CSS prefixing by browser vendors. This would greatly mitigate the problem caused today where vendor specific prefixing is seeing its way through production sites. The problem is so bad that some vendors are now tempted to support other browsers' prefixing. The article also has a link to an email from Mozilla's Henri Sivonen that does a nice job of addressing many potential issues and shortcomings of this new proposal." I was under the impression that browser prefixes existed to allow use of experimental CSS features before standardization; just ditching the vendor prefix seems like a step backward.

3 of 144 comments (clear)

  1. Here's another proposal: by orthancstone · · Score: 5, Insightful

    Get the standard done. Browser vendors are not going to wait 20 years for you to make up your mind. The digital world moves too fast for policy to take too long. Proposed ideas are going through vigorous testing in the real world long before a finalized plan for that idea is set.

  2. Re:The solution is.. by Anonymous Coward · · Score: 5, Informative

    Because before it's allowed to be a recommendation, it has to have "beta'd" in 2 browsers. So, usually they prefix with the vendor-name (minus webkit browsers which use the engine-name).

    Sometimes they have competing syntaxes, such as in gradients, which webkit and gecko duked out.

    Basically, they need to allow to experiment, allow backwards compatibility (NEVER BREAK THE WEB), and still be able to ship. Prefixes solve this problem.

    The problem most are having with this, is web developers are getting lazy, and on mobile sites only including (pretty much) webkit. So now, IE9Mobile and Firefox Fennac(? is it still called that), are having to implement the -webkit- features because sites look terrible on them, because developers got lazy.

  3. Re:The solution is.. by chrissigler · · Score: 5, Informative

    In some cases, different engine authors have different ideas of what the best way to define the spec would be. And given that there's no solid standard yet, they want to do it the way they want to do it. And over time, they can even change their minds, perhaps submitting to the weight of the broader industry.

    For example, consider Webkit's two implementations of a simple linear gradient, from black at the top to white at the bottom:

    -webkit-gradient(linear, left top, left bottom, color-stop(0%,#000000), color-stop(100%,#ffffff)); /* older webkit method */
    -webkit-linear-gradient(top, #000000 0%, #ffffff 100%); /* newer webkit method */

    Note that the "new" approach to the arguments is based more on the emerging "standard" (implemented the same way with -ms-, -moz, and -o- prefixes). But when you're out there before the standard emerges (or better yet, is defined), you don't just presume to define the standard.

    Or, at least that's how I imagine it went down...