If you’re a forward-thinking web developer – which of course, as you’re a Ubelly reader, almost goes without saying – you must be pretty familiar with code that looks something like this:

.foo {
-moz-transform: rotate(45deg);
-ms-transform: rotate(45deg);
-o-transform: rotate(45deg);
-webkit-transform: rotate(45deg);
}

The same property, repeated four times but with four different prefixes, one for each of the four main browser rendering engines (these are known as vendor prefixes). It seems wasteful; all four operate in exactly the same way, so all this means is extra work for us and a lot of repetition in our stylesheets. Unsurprisingly, a lot of people are calling for these prefixes to be scrapped. In a post which began a round of discussion recently, Henri Sivonen said:

I think vendor prefixes are hurting the Web. They are hurting Web authors. They are hurting users of browsers. They are hurting competition in the Web browser space.

This divided opinion. Daniel Glazman disagreed in a point-by-point rebuttal, but Alex Russell was more emphatic still, saying “vendor prefixes are a rousing success”:

Prefixes are an enabler in allowing the necessary process of use, iteration, and consensus building to take place.

So I’d like to provide a little context to the debate, as well as put my own opinion on the relative success of vendor prefixes.

What are vendor prefixes for?

In the past they were mainly used for features that were proprietary to each particular browser, but in recent years they’ve become more common as a way to introduce experimental support for new CSS properties, before they become standardised. The aim is that no browser introduces a new feature before it’s been found to be fully interoperable with other browsers.

As an extreme example, imagine we introduce a new property called dangle which takes a single angle value, like so:

.foo { dangle: 45deg; }

Seems straightforward, but what if WebKit measured that angle vertically, and Mozilla, horizontally? If the two implemented the property without a prefix, the feature would be interoperable; in one of the two browsers it would display completely differently to how you wanted it.

Browser prefixes are intended to save us from that problem, and when they do their job, they do it very well. For a real world example, consider the radial-gradient property. This is how the syntax looked when WebKit first introduced it, used to create a circular black to white gradient from the top left corner with a 100px radius:

gradient(radial,0,0,0,0,0,100,from(black),to(white);

Not to put too fine a point on it, it was ugly. As the syntax currently stands, you have to do this to get the same effect:

radial-gradient(0 0,circle,black,white 100px,transparent 100px);

But there’s a new, refined syntax on its way, which does the same like this:

radial-gradient(100px circle at 0 0,black,white);

The syntax has undergone radical changes since first being introduced, it’s much more logical and human-readable now, and it’s thanks only to the browser prefixes being used that we haven’t ended up with a load of incompatible properties across different browsers, causing us (and therefore our clients) no end of problems.

So you can see how prefixes are useful in this example, but the complaints tend to come when we have the opposite; as in my first example, where we have four properties working in exactly the same way, seemingly standardised but not available for us to use yet.

That’s down to the way the W3C works. Their criteria state that features are deemed to be experimental until the module they belong to has gained Candidate Recommendation status. This means the technical reviews have been completed and there are no outstanding objections, which are things we don’t always get to see; while it may appear to us that the feature is ready, there may be very good reasons why it isn’t.

The real problems with browser prefixes

Other than making our code messy and repetitious, there are two serious problems being caused by prefixes in the form they currently take.

The first is that developers love to experiment with cutting edge features as they’re released, creating demos to show off their potential. But sometimes a feature can be implemented in one browser years before it appears in others, as was the case with CSS Animations. When that happens, those demos aren’t always updated to accommodate the new vendor prefixed property, meaning that in new browser versions the demos simply don’t work even though it seems as if they should – which looks like the fault of the browser, not the developer.

The other problem occurs when developers use prefixed properties in a way that, deliberately or otherwise, means the targeted browser is the only one that can display the site correctly. I’m thinking specifically of WebKit properties on mobile here; it’s unfortunately the case that some developers make mobile websites using -webkit- properties only, meaning that alternative browsers – such as IE9 Mobile, Opera Mobile, Firefox for Android – get a broken or non-existent experience. This is an example where browser prefixes lead to a browser monoculture which is actively harmful.

The situation has become so bad that some browser makers have considered implementing -webkit- properties just so that their users can browse the web without problems. Should this happen, this would break the vendor prefix system once and for all.

Some proposed solutions

Many people have suggested ways to replace the vendor prefix system: Henri Sivonen suggested in his original post that experimental features should be kept in nightly and development releases of browsers, and not make their way into full releases until they are stable. Lea Verou suggested a number of different approaches, including using a single experimental prefix but applied per-browser using an @vendor rule, and Felipe Gomes has a similar suggestion, using the @vendor-unlock rule to activate experimental properties.

However, all of these people believe that the vendor prefix system is more fundamentally broken than I do. I think the problem is a little more obvious, as you’ll notice that both of the key problems I described previously have a clear commonality: developers. Us. As Opera’s Bruce Lawson said:

We’re approaching a monoculture on mobile. This is not the work of an evil organisation, but it’s developer-constructed.

In a post on this subject on my own blog, I argued that we need to take more responsibility, including:

• Commit to supporting old demos that we have made.
• Always make sure we plan our designs and builds in a way that they are not reliant on prefixed features, but degrade gracefully.
• Don’t use an unprefixed property before standardisation has happened unless we can have reasonable confidence that it is safe.

Even if you’re an advocate for a more fundamental revamp, you should agree that a change in our behaviour could be massively beneficial to the web as a whole.

Of course, there is another option: don’t use vendor prefixed properties at all.

Bonus section: Tools

If you get bored writing out all of the prefixes individually, there are tools such as Prefixr and CSS3 Please! which allow you to write the rule once and have all the code output for you.

An alternative approach is to use tools which pre-process your stylesheets, either on the client side like -prefix-free or LESS, or the server side like Sass. Note that the former two introduce a dependency on JavaScript, which may be less than optimal.

Tomorrow a few of the Ubelly guys (namely Martin, Andrew and myself) will be heading up to Nottingham to attend the New Adventures in Web Design conference. We’re rather excited due to the calibre of speakers (and attendees for that matter) and can’t wait to hear some of the talks. We’ll be live tweeting throughout the day from @Ubelly and will have a blog or two to post about the conference.

We’re particularly looking forward to hearing about Brendan Dawes‘ journey and Elliot Jay Stocks‘ ‘With Great Power Comes Great Responsibility’ talk, which focuses on HTML5 and CSS3 and the possibilities (and dangers) of using these nifty new technologies.

In addition, we’ve got an extra person coming along in the form of Sam to sketchnote the conference (and provide the little image above). We had something similar last year at Flash on the Beach, but with a new year and new conference we’ve picked someone up with a whole new style and we’re looking forward to how it goes!

Can we stop there? Of course not.

Keep an eye out on Foursquare, as we’ve set up a special venue for #naconf and we’ll be giving out some goodies through the day. All you have to do is find us  first…

I was walking through the high street yesterday and noticed a poster outside of M&S that was advertising a dine in for two, £10 promotion. The way that they had used a picture as the infill for the 0 in £10 made me think about how you could achieve that effect using CSS3.

So when I got home I booted up my editor and had a fiddle with the border-radius property that’s supported in IE9, Chrome, Safari, FireFox and Opera.

From the picture I’d say they were using Helvetica as the font, but to keep things simple I’ve just used Arial.

Firstly I added the HTML I’ll need which consists of some text wrapped in a span and on the right a 200px by 200px image of some food:

<span>£1</span><img src="food.png" style="width:200px; height:200px" />

Then I added the CSS for the page:

<style>
    body{
        background-color:#000;
         font-family:arial;
    }
    span
    {
        color:#fff;
        vertical-align:middle;
        font-size: 280px;
    }

    img {
        border-radius:105px;
        border: 10px solid #fff;
        vertical-align:middle;
    }
</style>

To create the round image shape I added the CSS3 attribute border-radius and set it’s value to 105 which is half the size of the width + border.

I also added a 10px white border so that it looks more like the original image.

I started up the browser and IE9 displayed roughly what I was expecting. However a number of the other browser failed to correctly apply the border.

Google Chrome

rounded the corners but did not display the white border that I specified.

Safari

pulled the same trick.

Firefox

Did not apply the rounded corners at all. This is because Firefox currently applies border radius with a vendor prefix.

To fix this you simply have to add the vendor specific code to the image in CSS:

-moz-border-radius : 105px;

However, Firefox still didn’t apply the border as I was expecting.

Opera

The rendering in opera was similar:

It seemed that only IE9 Beta was rendering border-radius correctly, so I thought I’d change approach. This time I created a DIV and set it’s background-image property to the food image and rounded the corners of the DIV.

This time all the browsers displayed the border-radius correctly, however I had now broken the vertical-alignment by using  a left floated div  rather than an image.

<style>
    body{
    background-color:#000;
         font-family:arial;
    }
    span
    {
        color:#fff;
        vertical-align:middle;
        font-size: 280px;
        float:left;
    }

    div {
        background-image:url("food.png");
        border-radius:105px;
        border: 10px solid #fff;
        -moz-border-radius : 105px;
        vertical-align:middle;
        float:left;
    }

</style>

<span>£1</span><div style="width:200px; height:200px" />   

IE9

Opera

Safari

Chrome

FireFox

I guess the lesson here is: Don’t use CSS3 border-radius on elements other than DIV’s if you want consistent rendering across all browsers.

Trying to get a good website layout and CSS not quite cutting it? here’s 10 jQuery Plugins to Help with Web Page Layouts

Starting out building retail websites? Make sure you add SEO into your list of things to do. To help, here’s 5 SEO Tips for Retail Websites 

Fancy playing around with CSS and html to create some cartoons, videos and animation? 10 Mind-Blowing Experimental CSS3 Techniques and Demos

46 CRO/Conversion Rate Optimization Resources for Web Design, SEO & Social Media Experts – not sure whether your outsourced partners are really experts? This article could help…

Research Desktop tags your activities and creates a unified user experience for the desktop.

Working remotely? Need to stay sane? Read Jeff Atwood On Working Remotely.

Estimating Programming Time – interesting read from an Oracle developer about culture, coding, and planning.

Enable CSS pseudo-element selectors in Internet Explorer with IE-CSS3.js  – as Andy Clarke says, this is a ‘game changer’. Take a look at his step by step guide.

Silverlight 4 Beta Networking Screencasts by our very own Mike Taulty.

Viral growth trumps lots of faux followers – you might have 1000+ followers but are they doing anything with your tweets?

Blaise Aguera y Arcas demos augmented-reality maps – this will blow your mind, showing how Bing maps integrates all available data to provide an in-context experience.

Not 10, not 20 – not even 30 but 50 useful coding techniques.

Just starting out as a web designer and need help? Here’s some ‘Expert advice for students and young web designers’

5 Timeless Usability Principles for Website Designers. We think they’re useful – do you agree?

Client asking you to create a web form and need inspiration? Here are ‘4 Terrific Tools for Creating Business Web Forms’. Enjoy.