All posts tagged ‘CSS Working Group’

File Under: CSS

W3C Gives Its Blessing to Prefix-Free CSS Animations

Sisyphus

The W3C’s CSS Working Group, the group charged with creating the CSS standard, has given browser makers the go-ahead to remove the prefixes from CSS 3 Transforms, Transitions and Animations.

CSS vendor prefixes were designed to help web developers by giving them a way to target CSS to specific browsers and use proposed standards before they were finalized. By prefixing properties developers can target any quirks in specific browsers until the standard is finalized. Unfortunately that’s not always what has ended up happening. Vendor prefixes have come under considerable fire recently, with Opera going so far as to implement other browsers’ prefixes.

That’s why the announcement that three more properties are ready to go prefix-free is good news for web developers. Obviously it’s a bit early to get rid of your transition and animation prefixes, but look for coming updates from browser makers to do away with the need for prefixes like -moz, -webkit, -o and -ms when using Transforms, Transitions and Animations. In fact the latest preview release of Internet Explorer 10 already supports the unprefixed versions.

The IEBlog recently posted a nice overview of all the new prefix-free CSS properties in IE 10.

Unfortunately, as is often the case in web development, using the prefix-free version of CSS rules is not a simple as it should be. Even those who followed the best practice of including an unprefixed version of CSS rules after the prefixed declarations may, in some cases, need to tweak their code a bit.

Consider for example the syntax of CSS gradients. The prefixed gradient syntax supported by today’s browsers is in fact based on a now obsolete draft version of the gradient specification. The earlier syntax is incompatible with the current Candidate Recommendation version of the spec. That means if you wrote out the unprefixed rule on a site two years ago, using the correct syntax for the time, your unprefixed code won’t work when gradient prefixes are removed (as they have been in IE 10). Fortunately, gradients are something of an anomaly and most of the time you won’t need to change too much. With the Transforms, Transitions and Animations you shouldn’t need to change anything at all.

Either way, browser makers will likely need to continue supporting the prefixed versions of CSS rules even after the W3C declares the non-prefixed versions ready for prime time.

File Under: CSS, Web Standards

Web Developers Sound Off on WebKit Prefixes

Photo: Ariel Zambelich/Wired.com

Yesterday we told you about a disturbance in the web standards force, a supposed rash of websites that work in one and only one web browser. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit, the engine that powers Safari, Chrome, iOS and Android web browsers.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

We aren’t the only ones who think that spells disaster not just for web standards but for the long-term viability of the open web. In fact the response from the web community has all but drowned out everything else in our RSS and Twitter feeds.

Here’s our round-up of what’s being proposed, what it might mean for the web and how we might go about solving the problem:

First and foremost read the minutes from the CSS Work Group meeting, which is where all of this started. The legend for the names is at the top of the page, though you’ll need to scroll about half way down to get to the actual meat of the discussion.

The second must-read post on vendor prefixes comes from CSS Working Group Co-Chair Daniel Glazman who calls on other browser makers to not implement the -webkit prefix and asks developers to make the extra effort to build cross-browser apps. Glazman has since followed up that piece with two more, one clarifying the original post and one defending the CSS Working Group against those who argue that the reason prefixes exist is because the standards process is too slow. If you believe that the CSS spec moves to slowly, this post is well worth a read (spoiler alert: it’s typically browser makers arguing, not the standards process, that creates the hold up on new features).

Remy Sharp of HTML5Doctor fame, weighs in with a series of rough ideas, neatly summarizing the issue and looking at it from both sides. In the end Sharp seems to conclude that just about everyone is to blame, from the browsers to the working group to developers.

Rachel Andrew of the web standards project generally agrees with Glazman writing, “once again we run the risk of having sites built only for one platform, and [will] find it very hard to get that platform to go away if things move on.”

The ever-humorous Bruce Lawson, who works as a web standards evangelist at Opera Software, writes: “Personally — PERSONALLY — I’m pretty depressed about all this. I’ve spent 10 years — pretty much since IE6 came out — evangelizing cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.”

Over at Quirksblog mobile expert Peter-Paul Koch argues that vendor prefixes are just plain wrong: “Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.” He goes on to propose an interesting idea of vendor-neutral prefixes like -alpha and -beta for experimental features.

Aaron Gustafson, a member of the Web Standards Project, has started a petition to ask Mozilla, Microsoft and Opera to not implement -webkit. Gustafson also has a one-line bash script you can use to search your code for any instances of the -webkit prefix so you can double check to make sure you’re supporting other browsers as well.

Mozilla developer Christian Heilman believes that “this mess has partly been created by developers, the least we can do is help fix it.” To that end Heilmann’s Pre-fix the web project is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

JavaScript developer Peter van der Zee has some other possible solutions: “Either we strongly limit the life span or availability of the prefix by making them only available in beta versions of a browser. Or we force other vendors to pick up on the slack by giving them a certain time to come up with their own implementation of a certain feature, or forfeit that possibility after a certain amount of time.”

Finally, if you read through the CSS WG notes you’ll notice that Tantek Çelik cites developer Lea Verou as an example of web developers who use just the -webkit prefix. In fact that’s completely untrue and Çelik has since corrected his statement. Verou has long advocated using all prefixes and even created prefixfree to help automate the process.