Two New Proposals to Solve the CSS3 Vendor Prefix Crisis

Posted on May 15, 2012 by Craig Buckler

Web developers have been concerned about the vendor prefix crisis since February 2012. To summarize the issue, this is what should happen in an ideal world:

Vendors implement experimental CSS3 properties using their own prefix, e.g. -webkit-transform, -moz-transform, -ms-transform, -o-transform.
Developers can use the technologies today without breaking cross-browser compatibility. Properties can be listed with their prefixed and unprefixed names to ensure they work everywhere.
Once a property becomes a W3C recommendation, all browser vendors can provide a stable unprefixed property, e.g. transform.
Optionally, developers can remove the prefixed properties from their stylesheets. However, it’s not strictly necessary if the unprefixed property is defined last and CSS cascade rules apply.

This is what occurs in the real world:

Vendors implement experimental CSS3 properties using their own prefix. In some cases, vendors promote them as an HTML5 “standard” even if they’re device-specific or never submitted to the W3C.
Some developers use the proprietary property from a single vendor, e.g. only -webkit-transform. This might be owing to ignorance, laziness or because they’re testing a limited number of devices.
Once a property becomes a W3C recommendation, all browser vendors can provide a stable unprefixed property, e.g. transform…
but developers neglect to change their stylesheets. The site looks good in some browsers but worse in others even when they support the standard W3C specification.
The vendors become concerned and add support for other prefixes into their browser, i.e. Opera implements the -webkit prefix for some properties. The prefix process is broken and, while it’s too early to predict the outcome, the majority of developers consider it to be a bad move.

We have discussed the issues at length on SitePoint; there are no easy solutions. However, two interesting proposals have been raised by W3C members during the past week.

Option 1: Unprefixed Properties are Supported From Day One

The first proposal comes from Florian Rivoal, Opera’s W3C representative:

When a browser vendor implements a new CSS feature, it should support it, from day 1, both prefixed and unprefixed, the two being aliased. If a style sheet contains both prefixed and unprefixed, the last one wins, according to the cascade.
Authors should write their style sheets using the unprefixed property, and only add a prefixed version of the property (below the unprefixed one) if they discover a bug or inconsistency that they need to work around in a particular browser.
If a large amount of content accumulates using the a particular vendor prefix to work around an issue with the early implementation in that browser, the vendor could decide to freeze the behavior of the prefixed property while continuing to improve the unprefixed one.

For example, you could use the following transform code in your CSS:


transform: rotate(30deg);

The property would be ignored by all browsers which had not implemented transforms. If there were a difference between two or more implementations, e.g. webkit browsers rotated anti-clockwise by default, you could override the property accordingly, e.g.


transform: rotate(30deg);
-webkit-transform: rotate(-30deg);

It’s a simple solution and easy to implement. Most existing stylesheets would continue to work and prefixed properties would rarely be necessary. In most cases, you would never need to update your CSS again.

However, what would happen if webkit changed rotation to the W3C-approved clockwise direction? Developers would need to fix their stylesheets by removing or rearranging the -webkit-transform: rotate(-30deg); property. Unfortunately, not everyone uses the same version of the webkit engine at the same time. You could encounter a situation where your site works in Chrome but not in Safari for several months.

Option 2: A New Vendor-Draft Modifier

The second proposal comes from François Remy:

Let’s introduce the “!vendor-draft” value modifier. I propose we use unprefixed properties from start, but with a token explaining which version of the property we built our CSS for:
border-radius: 3px !webkit-draft;
Any browser which is not webkit but implemented border-radius in a way that is compatible with the “webkit draft” can support the declaration. This is different from vendor prefixes: other browsers don’t impersonate webkit, they just acknowledge they support one specific property the way the webkit draft defines it. Browsers which are not compatible with that draft will just ignore the declaration. Browsers that change their implementation of a property are encouraged to iterate their “!vendor-draft” flag (using a version number, if appropriate).

This solves the issue by changing the property value rather than its name (in a similar way to the !important modifier). Again, the following transform code could be used:


transform: rotate(30deg);

But a default anti-clockwise rotation could be fixed in any browser adhering to a webkit specification:


transform: rotate(30deg);
transform: rotate(-30deg) !webkit-draft;

If a browser subsequently supported the W3C specification, the second property would be ignored.

It would also be possible to implement draft versioning, e.g.


transform: rotate(30deg);
transform: rotate(-30degrees) !webkit-draft;
transform: rotate(-30deg) !webkit-draft-2;

It’s a flexible solution which finally addresses the issue of properties evolving over time.

Unfortunately, it’s more difficult to implement and could take months to appear in browsers even if all vendors agreed today. It may be technically better, but it’s a fundamentally different approach which could break existing stylesheets. In the short term, vendors would probably support both prefixes and value modifiers — and that would lead to confusion.

I like both solutions. From a coding perspective, vendor-draft modifiers seems the most logical option but I doubt it can be considered until vendors “complete” CSS3 and begin work on CSS4.

Supporting unprefixed properties is more practical but will certainly cause versioning issues which couldn’t be fixed in CSS alone. But perhaps that’s the price you pay for using experimental technology?

Do you have a preference for either of these options? Or is it too late to prevent a vendor prefix catastrophe?

Goodbye -9999px: A New CSS Image Replacement Technique

Posted on April 10, 2012 by Craig Buckler

The -9999px image replacement technique has been popular for the best part of a decade. To replace a text element with an image, you use the following code:


<h1>This Text is Replaced</h1>
<style>
h1
{
	background: url("myimage") 0 0 no-repeat;
	text-indent: -9999px;
}
</style>

The element’s background is displayed and it’s text is moved off-screen so it doesn’t get in the way. Simple and effective. It was often adopted to show graphical titles — that’s rarely necessary now we have webfonts, but you’ll still find it used all over the web.

Until now.

A new technique has been discovered by Scott Kellum and promoted at Zeldman.com:


#replace
{
	text-indent: 100%;
	white-space: nowrap;
	overflow: hidden;
}

The code indents the text beyond the width of its container but it won’t wrap and the overflow is hidden.

While it’s a little longer and more difficult to remember, performance can be improved because the browser’s no longer drawing a 9,999px box behind the scenes. It will also prevent the weird left-extended outlines you’ll see around links using hidden text.

I haven’t been able to discover any downsides — only than I wish I’d discovered it first. Have you adopted the technique? Have you experienced any issues?

How to Use the HTML5 Full-Screen API

Posted on April 5, 2012 by Craig Buckler

Flash has offered a full-screen mode for many years but, until now, browser vendors have resisted the feature. The main reason: security. If you can force an app to run full-screen, the user loses their browser, taskbar and standard operating system controls. They may not be able to close the window or, worse, nefarious developers could emulate the OS and trick users into handing over passwords, credit card details, etc.

At the time of writing, the HTML5 full-screen API has been implemented in Firefox, Chrome and Safari. Mozilla provide good cross-browser details but it’s worth noting that the specifications and implementation details are likely to change.

Unlike pressing F11 to make your browser go full-screen, the API sets a single element full-screen. It’s intended for images, videos and games using the canvas element. Once an element goes full-screen, a message appears temporarily to inform the user that they can press ESC at any time to return to windowed mode.

The main properties, methods and styles are:

element.requestFullScreen()
Makes an individual element full-screen, e.g. document.getElementById(“myvideo”).requestFullScreen().

document.cancelFullScreen()
Exits full-screen mode and returns to the document view.

document.fullScreen
Returns true if the browser is in full-screen mode.

:full-screen
A CSS pseudo-class which applies to an element when it’s in full-screen mode.

Vexing Vendor Prefixes

Don’t bother trying to use these API names. You’ll require vendor prefixes for BOTH the CSS and JavaScript properties:

Standard	Chrome/Safari	Firefox
.requestFullScreen()	.webkitRequestFullScreen()	.mozRequestFullScreen()
.cancelFullScreen()	.webkitCancelFullScreen()	.mozCancelFullScreen()
.fullScreen	.webkitIsFullScreen	.mozfullScreen
:full-screen	:-webkit-full-screen	:-moz-full-screen

There’s no support in Internet Explorer or Opera yet, but I would suggest you use the ‘ms’ and ‘o’ prefixes for future proofing.

I’ve developed a function in the demonstration page which handles the prefix shenanigans for you:


var pfx = ["webkit", "moz", "ms", "o", ""];
function RunPrefixMethod(obj, method) {
	var p = 0, m, t;
	while (p < pfx.length && !obj[m]) {
		m = method;
		if (pfx[p] == "") {
			m = m.substr(0,1).toLowerCase() + m.substr(1);
		}
		m = pfx[p] + m;
		t = typeof obj[m];
		if (t != "undefined") {
			pfx = [pfx[p]];
			return (t == "function" ? obj[m]() : obj[m]);
		}
		p++;
	}
}

We can then make any element viewable full screen by attaching a handler function which determines whether it’s in full-screen mode already and acts accordingly:


var e = document.getElementById("fullscreen");
e.onclick = function() {
	if (RunPrefixMethod(document, "FullScreen") || RunPrefixMethod(document, "IsFullScreen")) {
		RunPrefixMethod(document, "CancelFullScreen");
	}
	else {
		RunPrefixMethod(e, "RequestFullScreen");
	}
}

The CSS

Once the browser enters full-screen mode you’ll almost certainly want to modify the styles for the element and it’s children. For example, if your element normally has a width of 500px, you’ll want to change that to 100% so it uses the space available, e.g.


#myelement
{
	width: 500px;
}
#myelement:full-screen
{
	width: 100%;
}
#myelement:full-screen img
{
	width: 100%;
}

However, you cannot use a list of vendor prefixed selectors:


/* THIS DOES NOT WORK */
#myelement:-webkit-full-screen,
#myelement:-moz-full-screen,
#myelement:-ms-full-screen,
#myelement:-o-full-screen,
#myelement:full-screen
{
	width: 100%;
}

For some bizarre reason, you must repeat the styles in their own blocks or they won’t be applied:


/* this works */
#myelement:-webkit-full-screen	{ width: 100% }
#myelement:-moz-full-screen		{ width: 100% }
#myelement:-ms-full-screen		{ width: 100% }
#myelement:-o-full-screen		{ width: 100% }
#myelement:full-screen			{ width: 100% }

Weird.

View the demonstration page in Firefox, Chrome or Safari…

The technique works well. The only issue I’ve discovered concerns Safari on a two-monitor desktop — it insists on using the first monitor for full-screen mode even if the browser is running on the second screen?

While it’s possibly a little early to use full-screen mode, games developers and video producers should keep an eye on progress.

Combining LESS with ASP.NET

Posted on March 29, 2012 by Malcolm Sheridan

Everyone knows how cool LESS is. If you’re not, then here’s the elevator speech. LESS extends CSS with dynamic behavious such as variables, mixins, namespaces and functions, it makes CSS easy to work with. Now, it’s important to remember it doesn’t code your CSS for you – it isn’t a magic CSS editor. You still need to know how to work with CSS. It allows you to write CSS once and use it in multiple places. This is something I’ve wanted for a long time and now it’s here.

There are other libraries which perform similar functions, such as SASS, but I’ll focus on LESS as that’s what I’m familiar with. I’m going to be concentrating on how to use this with ASP.NET.

I’m going to be using Visual Studio 2010 for this demonstration, as I had a few issues using LESS with Visual Studio 11.

Running LESS On the Client

LESS can be run purely on the client or from the server. To run it on the client is a simple three step process.

Add a reference to the LESS JavaScript file
Update the rel value in the LINK tag to rel=”stylesheet/less”
Add a new .less file to your project and reference that in your LINK tag

Updating the rel value to stylesheet/less is necessary because the LESS library looks for this value. Once it’s found it processes that file. Your page should look like this now.


<link href="styles/my.less" rel="stylesheet/less" />
<script src="http://lesscss.googlecode.com/files/less-1.3.0.min.js"></script>

I’m referencing a file called my.less, so let’s define some LESS code to ensure this is working.


@back-color: #000;
@font-color: #fff;
body {
  background-color: @back-color;
  font-size: .85em;
  font-family: "Trebuchet MS", Verdana, Helvetica, Sans-Serif;
  margin: 0;
  padding: 0;
  color: @font-color;
}

I’ll skip over the syntax for now, but if you run the website and look in the developer tools, you’ll see that LESS code is being served as valid CSS.

Running LESS On the Server

There are several ways to install LESS on the server. The easiest approach is via NuGet. There’s a package called dotless. Install it with the following command inside Visual Studio.

Once installed, you can remove the JavaScript reference from your page. Also make sure you update the LINK tag and remove the /less from the rel attribute.


<link href="styles/my.less" rel="stylesheet" />

The package has also added some entries to your web.config file. There’s a new configSection defined.


<configSections>
  <section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
</configSections/>
<dotless minifyCss="false" cache="true" web="false" />

And a new HTTP handler has been added to cater for .less requests.


<system.webServer>
  <handlers>
   <add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
  </handlers>
</system.webServer>

The nice feature about dotless is that it can automatically minify the CSS for you via the minifyCss attribute. If you update that to true and run the website now, you’ll see the minified CSS.

That’s it. LESS is now running on the server.

When To Use It?

I think LESS is great for development, but when you need your site to run as fast as possible, you don’t want to transform each .less request on the fly. This is why I’d recommend using this only during development. The good news is when you install dotless, it installs the dotless compiler. This can be in the packages\dotless1.3.0.0\Tool folder in your website folder.

You can add this to your pre-build event from the build properties tab.

“$(SolutionDir)packages\dotless.1.3.0.0\tool\dotless.Compiler.exe” “$(ProjectDir)content\my.less” “$(ProjectDir)content\my.css”

This way you get the best of both worlds.

Before moving away from Visual Studio, there are extensions you can install that gives you the familiar syntax highlighting. LessExtension seems like one of the better ones.

LESS Syntax

I haven’t covered any of the syntax in this article. I wanted to focus on LESS with ASP.NET. Ivaylo Gerchev has a good article on the syntax and that can be found here.

I think LESS is a must tool to have during development. It will make your life easier when coding CSS.

How to Create a CSS3 Ajax Loading Icon Without Images

Posted on March 21, 2012 by Craig Buckler

There’s an inevitable delay whenever your web application interacts with the server. That could be for an Ajax request, uploading a file, or using newer HTML5 APIs such as web sockets or server-sent events.

Ideally, you should give the user some feedback to indicate their action is being processed. You’ll often see small animated GIFs with rotating patterns. There are several sites which will create them for you, such as preloaders.net and ajaxload.info.

Images are the best cross-browser option but they have a number of issues:

GIFs do not support alpha-transparency. You need to be careful when placing the image on a colored background.
Bitmap images won’t scale nicely. If you change the dimensions, you need to create a new image.
If you’re not careful, animated graphics can have a large file size.
Images incur an additional HTTP request. While the image will be cached, the initial download may take longer than the background process it represents! You can code around this issue by pre-loading the image or using embedded data URLs but it’s more effort.

Fortunately, CSS3 allows us to create loading icons without images. They’re easy to create, scale, re-color, use on any background and don’t incur image downloads. You require:

A single HTML element, e.g. <div id="ajaxloader"></div>.
A few CSS backgrounds, border and shading effects to create a graphical icon.
CSS3 transformations and animations to rotate or move the element.

View the demonstration page…

Browser Compatibility

CSS3 transformations and animations are experimental properties which require vendor prefixes — and you know what trouble they cause. The example code implements the final property as well as prefixes for -webkit (Chrome and Safari), -moz (Firefox), -ms (IE), and -o (Opera), but there’s no guarantee they’ll work consistently if at all.

At the time of writing, recent versions of Chrome, Safari and Firefox offer CSS3 animations. IE9/8/7/6 and Opera show a static image, although IE10 and Opera 12 may support the properties.

Just to complicate matters further, Firefox allows you to animate pseudo elements separately. You can therefore add a couple of elements using :before and :after and rotate or move them in different directions to create more complex animations. While I’d initially hoped to do that, it doesn’t work in the webkit browsers. Chrome and Safari only allow real elements to be animated. It appears to be a bug or oversight, but it’s not been fixed in the current or beta releases.

Creating the Icon

Our HTML div can be placed anywhere in the document although it might be best to append it as the last child of the body. It will then appear above other elements and can be positioned in relation to the page.

The icon CSS simply sets wide white rounded border. The right border color is then set to transparent and a little shading is applied:


#ajaxloader
{
	position: absolute;
	width: 30px;
	height: 30px;
	border: 8px solid #fff;
	border-right-color: transparent;
	border-radius: 50%;
	box-shadow: 0 0 25px 2px #eee;
}

The result:

It’s easy to tweak the properties for different effects, e.g. adding border-right: 0 none; produces:

Animating the Icon

To make the icon spin and pulsate, we apply rotation transformations and opacity changes within a CSS3 animation. The animation name, duration, easing type and repeat are applied to the element:


#ajaxloader
{
	animation: spin 1s linear infinite;
}

followed by the animation keyframes:


@keyframes spin
{
	from { transform: rotate(0deg);   opacity: 0.2; }
	50%  { transform: rotate(180deg); opacity: 1.0; }
	to   { transform: rotate(360deg); opacity: 0.2; }
}

None of the browsers support animation without vendor prefixes so you’ll see -webkit, -moz, -ms and -o alternatives within the source code when you view the demonstration page.

The icon can now be displayed using a little JavaScript whenever an Ajax request is initiated. It’s a great effect which can be customized easily and works on 55% of current browsers.

Unfortunately, 45% of web users won’t see the animation. That number will fall when IE10 is released and users switch to recent versions of other browsers, but it remains a large percentage. You could fall back to an image but, if you’re doing that, you might as well use the image for all browsers.

I therefore suggest you look at your own statistics. If your visitors are are predominately using Chrome, Safari and Firefox you could adopt the technique today. If not, stick with images for now and wait a little longer for more consistent browser support.

5 Things I Hate About CSS3

Posted on March 20, 2012 by Craig Buckler

You knew this was coming. Yes, I still love CSS3 and use it every day — but that doesn’t mean I’m happy with everything. To counterbalance Viki Hoo’s 5 Things I Love About CSS3, here are five things which frustrate me…

1. Property Overload

How often did you consult manuals or reference materials when writing CSS2.1 code? After learning the basics, I suspect you only required a cursory glance now and again.

Those days are gone. Perhaps it’s just me but the sheer volume of new tags is overwhelming. Even when I know a property exists it’s impossible to recall the values. Has anyone learned the all the background gradient and border image options?

While CSS3 definitely saves time, you’ll need to consult online manuals or tools every few minutes.

2. Vendor Prefixes

Vendor prefixes are absolutely necessary. I use them and accept it’s the price to pay for cutting-edge techniques. That doesn’t mean I have to like them. Other developers don’t either — otherwise we wouldn’t be heading for a CSS3 catastrophe.

At best, prefixes result in clunky repetition. At worst, they use completely different syntaxes. There are JavaScript and server-side pre-processors which help ease the burden but none are perfect. After all, if a property doesn’t work in a particular browser is it a problem with your CSS, the browser, or the automatic code-creation tool you’re using?

3. Developer Tools

It’s difficult for any IDE vendor to keep up with the rapid pace of CSS3 development. Does anyone know of an editor which supports all the new properties and syntaxes with all the vendor-prefixed differences? I don’t.

It’s not all bad; there are a number of great online CSS3 tools. However, you still won’t find many decent validators.

4. Browser Support and W3C Politics

Browser vendors have different priorities and release schedules. While it’s easy to pick on IE (IE9 doesn’t support text shadow), even webkit isn’t consistently ahead of the game (Chrome doesn’t support separate animation of pseudo elements). One browser will always be more capable than another, but hype and marketing often get in the way of development. How often have you assumed a browser supports property X, written some code and found it doesn’t work?

The major vendors belong to the W3C and work together to agree standards. In reality, they’re competitors:

Apple has been accused of implementing iPhone/iPad-specific features which are promoted as an “HTML5 standard” but never submitted to the W3C.
The proposal to support webkit prefixes in non-webit browsers could break CSS3 as we know it.
The lethargic rate of the standards approval process highlights the disagreements and political battles.

It’s frustrating. Developers are caught in the crossfire but there isn’t a simple solution. And, before anyone suggests it again, dropping all but one of the rendering engines is not an option and will stagnate innovation.

5. Silly Shim Shenanigans

CSS3 rounded corners have save hours of time during every project. There’s no need for convoluted layouts or multiple background images. Unfortunately, they won’t work in IE8 or previous incarnations of the browser. You therefore have three options:

Forget CSS3 and use traditional development techniques.
Accept that no two browsers render the same. IE8 is three years old and was released before the industry jumped on the HTML5 bandwagon. Pages viewed in IE8 will look different (and uglier) to IE9, Firefox, Chrome, Safari and Opera.
Try and make IE8 look good using JavaScript shims which normally implement old IE-specific filters.

I recommend option two. You may need to educate your clients but their costs will be reduced and, ultimately, it may persuade users to upgrade their browser.

Unfortunately, I keep find sites which add a plethora of shims in a futile attempt to achieve pixel perfection. While pages may look better, it results in bulky code and IE8 often becomes frustratingly slow. I can’t believe their clients were pleased with the result.

In Summary

CSS3 is great. In terms of practicality, it’s progressed faster and is more useful than HTML5 or the assorted JavaScript APIs.

Browser compatibility is an issue but Viki is confident that “the day they are unified will eventually come”. I’m not convinced. We will reach a point when CSS3 is fully implemented but we’ll be moaning about CSS4 by then!

5 of the Best Free HTML5 Presentation Systems

Posted on March 12, 2012 by Craig Buckler

I have a lot of respect for Microsoft PowerPoint. It may be over-used and encourages people to create shocking slide shows, but it’s powerful and fun. I have just one criticism: all PowerPoint presentations look the same. It doesn’t matter how you change the colors, backgrounds, fonts or transitions — everyone can spot a PPT from a mile away.

Fortunately, we now have another option: HTML5. Or, more specifically, HTML5 templates powered by JavaScript with CSS3 2D/3D transitions and animations. The benefits include:

it’s quicker to add a few HTML tags than use a WYSIWYG interface
you can update a presentation using a basic text editor on any device
files can be hosted on the web; you need never lose a PPT again
you can easily distribute a presentation without viewing software
it’s not PowerPoint and your audience will be amazed by your technical prowess.

Admittedly, HTML5 presentations are not quite as powerful:

you require web coding skills
positioning, effects and transitions are more limited
few systems offer slide notes (it’s a little awkward to show them separately)
it’s more difficult to print handouts

But those are not necessarily killer drawbacks — you’re forced to concentrate on the presentation content rather than frivolous tweaks and awful animations.

Here are the best HTML5 presentation systems I’ve found. Click the headings to view a demonstration — most work best in Chrome, Safari or Firefox…

Reveal.js

This is my current favorite. Slides look great and can be positioned horizontally or vertically. It’s also easy to change the CSS to add your own effects — I managed to add a rudimentary notes facility doing just that.

Slides are defined in separate section tags and Reveal.js offers a choice of several 3D slide transitions … although they look fairly similar.

Download the reveal.js files…

Impress.js

Impress.js is, well, impressive. It’s been influenced by the commercial prezi.com; slides are arranged in a 3-dimensional space and your view rotates and pans accordingly. I won’t attempt to explain it further — just try it and you’ll understand what I mean.

Slides are defined in div elements with data attributes controlling the x, y, z locations and rotations. That’s the only drawback; it’s a little difficult to visualize and define those values. Persevere, though, and you’ll be able to create some stunning and original slide shows.

Download the Impress.js files…

Google Slides Template

As you’d expect, Google has their own HTML5 presentation template (as well as the one offered in Google Docs). It’s fairly basic when compared to Reveal.js or Impress.js; it’s restricted to right-to-left slide transitions and fade-in effects, but it still looks great.

Slides are defined in article tags and it’s easy to add extra stylesheets to override the default CSS.

Download the Google Slides Template file…

Deck.js

Deck.js was one of the first HTML5 presentation systems. It looks similar to Google’s offering — perhaps a little prettier, but without slide transition effects.

Slides are defined within semantically correct section blocks in an outer article. There’s also a documented API so it’s possible to create your own extensions.

Download the Deck.js files…

Shower

Shower is a presentation system by Vadim Makeev of Opera Software. While it’s one of the simpler systems, it’s fast and works well in all browsers. The slide thumbnail view is especially cool (press ESC).

Shower’s main drawback is it’s convoluted HTML. Slides are defined in a section within a div within another div and contain their own header and content. A little more development could make it easier to use.

Download the Shower files…

Other worthy mentions:

S5 — A Simple Standards-Based Slide Show System (download)
CSSS — CSS-based SlideShow System (download)
Slides (download)
HTML5Rocks (no direct downloads, but you can copy the source)

Have I neglected to mention your favorite HTML5 presentation system…

SitePoint Podcast #151: Vender Prefixes vs Web Standards with Rachel Andrew

Posted on February 27, 2012 by Louis Simoneau

Episode 151 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Rachel Andrew (@rachelandrew), one of the co-author of Everything You Know About CSS is Wrong and the author of The CSS Anthology (about to go into it’s fourth version) about the ongoing vendor prefix saga and how that affects the future of Web standards.

Listen in Your Browser

Play this episode directly in your browser — just click the orange “play” button below:

Download this Episode

You can download this episode as a standalone MP3 file. Here’s the link:

SitePoint Podcast #151: Vender Prefixes vs Web Standards with Rachel Andrew (MP3, 30:55, 28.4MB)

Subscribe to the Podcast

The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.

Episode Summary

Louis and Rachel cover Mozilla considering supporting the WebKit vendor prefixes for certain CSS properties Firefox already supports and how that could lead us away from having an effective set of Web Standards for the future.

Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/151.

Interview Transcript

Louis: Hello and welcome to another episode of the SitePoint Podcast coming to you a little bit late this week, we had a little bit of trouble getting the schedule together, but I hope it was worth the while because we have with us today on the show Rachel Andrew; hi, Rachel.

Rachel: Hello.

Louis: So Rachel is a web developer, will be well known to any long time SitePoint fans, she’s the author of a few of our books actually, co-authored Everything You Know About CSS is Wrong with Kevin Yank, who was the former host of the podcast, and also wrote The CSS Anthology, and you’re currently working on a fourth edition, is that right?

Rachel: That’s right, yeah.

Louis: Just putting the finishing touches now, if I understand it.

Rachel: That’s right, yeah.

Louis: We’re expecting that in a month or two maybe.

Rachel: Hmm-mm, yeah, I believe so.

Louis: Fantastic. I want to talk to you a bit about what’s new in the book a bit later, give you the chance to plug it a little bit, but before that, the main reason I wanted to talk to you is this ongoing I guess you could call it a drama concerning vendor prefixes, which came out of a W3C meeting recently, and you wrote a blog post on it about the issue for the Web Standards Project’s blog.

Rachel: Hmm-mm.

Louis: So, we talked about this a little bit on the podcast last week, but for anyone who’s either just tuning in, or to get a more complete breakdown of the issue, do you want to just go over sort of what happened and why it’s important.

Rachel: So what’s really happened is that because of the mobile web particularly being very WebKit-centric, you know, most of the browsers that people are using on mobile devices are running some form of WebKit, or the ones people are caring about, they’re thinking about iPhones and Android devices as well. So, web developers are implementing the new features of CSS3 using these vendor prefixes and only using WebKit prefix, when in fact we’ve got prefixes for Mozilla, for other browsers as well, but these aren’t being used. And so what’s happening is that obviously in the browsers that have support for these CSS features with their own prefix, people aren’t seeing the site in the same way they’re seeing it on WebKit browsers, which obviously for those other browser they want the site to look as good. So the danger is that what will happen is that other browsers will start implementing WebKit prefixes rather than allowing people to use their own prefixes or the standard feature, and this is becoming a real sort of problem, and so developers have been asked to really do something about it and to think about what they’re doing.

Louis: Right. So the issue came up at a W3C CSS Working Group.

Rachel: That’s right, yeah.

Louis: And I think it was someone from Mozilla who was making the point that at some point in the future Mozilla would need to implement the WebKit prefixes in Firefox just because they were so widely used.

Rachel: Yes.

Louis: Even for features that Firefox did support in its own version.

Rachel: That’s right, yeah. And really, as someone who’s been involved in sort of Web Standards for a very, very long time, you know this sort of brings us back to the point of a browser or an implementation sort of hanging around for an awful lot longer than it really should do, we’ve really just got to a point where we’re kind of getting rid of IE6, which has hung around for over 10 years; it was a great browser when it first came out. And we were, as developers at the time, were really excited about IE6, it might be hard to think if you’re a newer developer, because we could use a lot of CSS2, so people were just supporting IE6. You know at one point it had huge market share, there was really nothing else out there in sort of common use, and so we just built sites, or a lot of people just built sites for IE6 which is why IE6 has hung around for as long as it has. So I think those of us who are sort of the old geeks on the Web are slightly worried now that we’re going to see this happen again but with WebKit browsers and with WebKit extensions sort of hanging around for much longer than they really need to because of this.

Louis: So there are a few separate issues here. I guess one of the points that people make is that this to some extent bypasses the Standard’s Project, because a few of these WebKit properties aren’t actually in the CSS spec at all.

Rachel: That’s right, yeah.

Louis: They’re simply properties that have been added by developers at Apple or at Google; has Google also been involved in that?

Rachel: I’m not too sure, I think the common things are stuff which really are I guess making experience of mobile websites better, and so have been added for that purpose, but of course you know we do have mobile — Firefox, and Opera, of course, is important mobile browser. So, I think sort of going off and people just deciding to implement WebKit means that, yes, you know, sort of the WebKit process and Apple perhaps, or maybe Google, could start to pull the development of the Web and make it very proprietary rather than it going through the W3C process.

Louis: Right. So the idea here is that if someone — or if Apple implements a new property in WebKit doesn’t bother submitting it through the W3C to be included in the CSS spec, all the other browsers adopt it because other developers start using it, suddenly you don’t have a Standard’s process, you have various browsers implementing things willy-nilly, and if it catches on so be it, and if not, too bad.

Rachel: You know I’m all for browsers implementing features and coming up with new features, I mean obviously Apple have got a huge amount of stuff to add in terms of mobile web, and where we are now is very much being led by sort of iPhone and things; it’s not a bad thing for browsers to be implementing features and thinking of new features, but what we need is for things to then come back to that Standards process so that we can all sort of move along together and we don’t end up with a situation where we end up having to either build separate sites for different, you know, I can remember doing that sort of back in the browser wars days.

Louis: Right. An example that I’ve seen thrown around, for example to support this argument, is the case of the WebKit gradient syntax where the initial version was extremely verbose and complicated and so hard to use that people didn’t really understand it. And so that was the WebKit version, Mozilla developed a separate version, eventually the Standards process settled on something that was very close to the Mozilla version, and because they had been separately vendor prefixed it became pretty easy for developers moving forward to settle on the standard version.

Rachel: Yes, yeah.

Louis: Whereas if Mozilla had just implemented the WebKit version, or worse, had implemented their own syntax under the WebKit prefix, we never would have been able to make that kind of progress.

Rachel: Yeah. I’m quite a fan of vendor extensions, I think sort of coming from having worked through the sort of browser wars era with their version 4 browsers, I can understand why the vendor extension and things are kind of a good way forward, kind of the only way forward for browsers to be able to start implementing this stuff, try it out, let us try it out, let us feedback and say, no, that doesn’t work very well or that’s very confusing, and then come to eventually a sort of standard implementation of that feature. And I think it’s great, you know I enjoy trying out these different features even when they don’t really work in much; you know (laughter) I can’t really use it on real projects, but being able to have a play-around, see how something might work, and then feedback as well if possible to say that doesn’t work so well or what the problems are with it, because then we’re moving things on.

Louis: Yeah. Coming back to the idea of developers using these WebKit prefixes exclusively, do you have any sense of how widespread this is, because I get the feeling when I look at, for example, educational materials on the Web, that usually the authors of these materials are very clear in saying, you know, you use all the prefixes and you follow it with the un-prefixed one to make it future-proof. Now there are some cases of these cool demos of emerging WebKit features where people will just use the WebKit one and not bother to put in the un-prefixed one because it just isn’t supported anywhere else. But in the real wild of the Web is this something that’s really widespread?

Rachel: I’ve certainly seen it. I think it’s really difficult, you know, you have to sort of get out of the kind of Standard’s bubble; I think those of us who are very sort of keen on Web Standards, very keen on the open web, are going to be trying to do things the right way because we kind of care about that. But I think for a lot of people who are just building websites and they’re seeing mobile as being WebKit, which I think is often quite a reasonable assumption to make, have a quick look at the stats of the sites that I’m involved with, you know, many of which the traffic isn’t sort of web people, it’s just regular folk, you know, and the mobile landscape is very WebKit-centric, you don’t see very much else. And so I think it’s kind of a reasonable assumption for people to make to say, well, we hardly ever see Opera, we hardly ever see any of the mobile browsers so why bother. So unless people actually realize why it’s important to bother, and that it’s not just the browser support today isn’t just the issue, you know, then I think people aren’t really going to sort of engage with that as an issue at all.

Louis: Right.

Rachel: It works. I mean that’s always been the problem, you know, if something seems to work in the browsers that you know visit your site, unless you actually understand what the underlying issues are then why would you do anything else?

Louis: Right. So we’ve seen this kind of educational approach with web developers sort of work in the past, the initial push towards standards was largely driven by developers, but there was also a roll played by the browser vendors themselves.

Rachel: Yeah.

Louis: Do you feel like they have in some sense or responsibility to not go down the road of supporting WebKit prefixes? I know, for example, I quoted in the last episode of the podcast of Eric Meyers’ blog post on the topic.

Rachel: Yes, yeah.

Louis: Where he very nicely put it from the point of view of the browser makers; obviously their concern is for the users, and if the users aren’t seeing the site as pretty as it can be then that’s the step. But do you feel that that’s entirely right? Do you feel that there might be some greater sense of responsibility from the browser makers?

Rachel: Yeah, I mean I would like there to be a sense of responsibility from the browser makers, but also I understand that their sort of businesses or their browser has to sort of be front and center for them, they have to do what people want and what will ensure people carry on using their browser, so I can kind of understand the problem that they’re in, the quandary; do they make a stand and say, no, we’re not going to do this because it’s bad for the Web, or do they say, yeah, users want to be able to see the site the same, we can do the same as WebKit, we don’t want to look inferior to WebKit because people haven’t bothered to use the extensions.

Louis: Hmm-mm.

Rachel: I think that’s the sort of issue that browser makers are in, and I think that’s the point at which developers hopefully can make a difference because we can say well, no, we’re going to make sure we’re using these prefixes and makes sure every browser looks as good as it can do. But, yeah, I can see where they’re stuck and, you know, just as businesses and organizations wanted to make sure that their browser carries on being used and isn’t seen as some sort of lesser thing.

Louis: Right.

Rachel: Which, you know, I really feel — I have a real sense that we in recent years, and I guess with IE9 coming out, looking towards IE10, we’ve really got what we asked for with WaSP, you know, we asked for browsers to implement all the standard features in the same way so that we could build a site — I’ve been involved in a sort of big responsive web design project at the moment which I’ve been working on, and essentially I built is using Firefox because that’s the browser I developed it in, and I’ve looked at in IE9, I’ve looked at it in all the current browsers, and it just works, it’s all the same (laughs), and that’s what we asked for, that’s what we wanted, and it would be such a shame if having got to that point, got to the point where the standard features are pretty much implemented in the modern browsers in the same way, and new features being pushed forward through the sort of vendor extensions and in appropriate ways, it would be a real shame if we then kind of took a big step backwards with this issue.

Louis: Yeah. It would be largely a big step backwards that was prompted solely by over-enthusiasm and wanting to use all of these new features that we now have access to and that are now coming into browsers at a very fast rate after all these years of essential stagnation.

Rachel: Yes, I mean, you know, it’s a really exciting time, and I think we just need to temper that with remembering that we can actually cause some damage, you know.

Louis: Yeah, that’s a very valid point. So there’s a few various initiatives that you linked to from your blog post on The WaSP site, so one of them is Prefix the Web, which is an initiative I think which was started by Christian Helmut?

Rachel: Yes.

Louis: So this is an attempt to sort of go through a lot of these fancier demos on GitHub that are sort of trying to show web developers what’s possible with CSS3, and a lot of those if those are using only WebKit obviously then anyone who goes and tries to find how to do something by looking at this code might fall into the same trap.

Rachel: Hmm-mm. Yeah, I mean I said, yeah, there’s a lot of people that will just copy and paste code as well, you know, so this works.

Louis: Yeah, definitely. And there’s also a petition which is being run on change.org, sort of a pledge to the browser makers asking them to not do this, and also pledging to not do this on our sites.

Rachel: Yeah, that’s right. Yeah, I think we can do a lot by making sure people understand what the issue is, you know, and it’s not just a kind of academic thing, that there is a real problem here that we can kind of solve if we make sure that we’re doing — writing things in the right way, and hopefully we can kind of head this off.

Louis: Right.

Rachel: Saying to the browser makers, look, this is why it’s important, and we think it’s really important.

Louis: Yeah, I’ve seen a few different suggestions thrown around for ways that might help to avert this sort of vendor prefix clash, and so I don’t know what do you think about this? So one of them was to have everyone use the same thing but not be vendor specific prefix, so something like beta.

Rachel: Hmm-mm.

Louis: One of them was — and this is one that I kind of think makes sense, is that once a browser adds a non-prefixed version of a property, that it should remove support for the prefixed version.

Rachel: Yeah.

Louis: Now that makes sense to me. I can see, again, how it puts the browser makers in a tight position, obviously, because removing support for something that developers are using is going to make some sites out there look broken.

Rachel: Yeah, and that’s the problem is that we should feel safe to use — I mean there are people who say, well, just don’t use vendor prefix stuff on production work, but I don’t think that’s a reality. And part of that is because the actual standard’s process is pretty slow, and, you know we’re not getting the non-prefixed version as quickly maybe as we could, you know, you sort of have things that have really been stable for a very long time, and yet still we have to use a prefixed version. So I think really what we want to see is once things have been decided on and generally everything’s using the same implementation, it would be best to be using obviously the Standard version. But, you know, I could understand that browsers aren’t going to want to pull out those prefixed versions just in case people aren’t using them in the way they’re intended and are using them for things that worked in a slightly different way originally, you know, on sites that are sort of hanging around.

Louis: Yeah.

Rachel: Yeah, so I think there’s various things; I think the idea of a sort of beater-type extension if we’ve got something where everyone has agreed on it, that’s kind of cool, but, as you say, that sort of stops thing where manufacturers can implement things in slightly different ways as we’re coming down on what is going to be the final standard. See, I mean we don’t want to stop.

Louis: Yeah, obviously it makes sense for these different implementations.

Rachel: Yeah.

Louis: Again, coming back to gradients, if it had been the case where WebKit was using a beta prefix and Mozilla also wanted to use a beta prefix, it couldn’t go and completely change up the syntax.

Rachel: No.

Louis: Which I think anyone who’s worked with gradients can be thankful of the way things played out.

Rachel: (Laughs) yeah. And I think, you know, we want to encourage the browser manufacturers to put all there skills behind coming up with great implementations of this stuff, and coming up with new ideas, absolutely. We’ve got some very, very clever people, you know, working at each of these browsers, and we want all that (laughs) to be thrown into our daily work, essentially, and to come through.

Louis: So we can come to the conclusion that the best course of action for developers is to go through your sites and ensure that you’re using every available prefix and a non-prefixed version.

Rachel: Yeah, definitely.

Louis: To make sure that their stuff will go on working and to ensure that the browser makers will never be — or won’t feel pressured to support other vendors’ prefixes.

Rachel: I think so. And especially if you’re writing articles and tutorials and that sort of stuff to be — you know, I fully understand that you’re trying to keep the amount of code down, you’re trying to keep an article under a word count or whatever, but I think it’s really important that when people have cut and paste code that it’s correct, and that it won’t just lead them down this route of thinking, oh well, it doesn’t matter because it works in WebKit so it’s fine.

Louis: Yeah. And there are, of course, a number of tools available to make this easier, both preprocesses on the server side, which will run over your CSS and output it with all the required vendor prefixes so that you write it without prefixes.

Rachel: Yeah.

Louis: And then there are also client side solutions; I spoke on the podcast a few months ago with Lea Verou, who wrote an excellent little snippet of JavaScript that handles all of the prefixes for you on the front-end, so, again, you just write the canonical version and the prefixes get taken care of for you.

Rachel: Hmm-mm.

Louis: So, no excuse, and I think the first step is the petition, and after that the witch hunt starts and we start pointing fingers; is that right, am I getting that right?

Rachel: I mean I think if we do — if we spot stuff that is particularly high-profile articles or sites that we’re seeing, and we know this is the case for them, I think yeah, you know, drop them a line and say, hey, this is important, can you change this, especially for people who are educating, who are writing and speaking and teaching, I think we have to sort of hold ourselves to the highest level of Standards compliance, I think that’s really important.

Louis: Entirely. So speaking of writing and educating, that segues me perfectly into talking a little bit about the upcoming book. So, for anyone who’s not familiar with The CSS Anthology, so you’re on the fourth edition now, so it’s –

Rachel: It makes me very old (laughs), yeah.

Louis: Definitely part of The Web Standards canon, it’s been around forever, and it’s a fantastic resource, but you want to explain a little bit for anyone who’s not familiar with the book how it’s structured and what it has gone into in the past and maybe what’s different about the new one.

Rachel: Okay, well, the original idea of CSS Anthology is that it would be a collection of tips and tricks, so essentially it’s all question and answer, how do I do whatever. And so it’s essentially something to dip in and out of; you’ve got a CSS problem and hopefully it will have an answer for it and essentially a copy and paste solution within an explanation of how it works. In the first edition we talked about dealing with Netscape 4, so it’s goes back a long way (laughter); it’s very funny looking through the progression of the editions and the sort of different browsers that have come and gone and been important. So, when I came to write this fourth edition, and obviously it’s a revised edition, and sometimes you do a revised edition and you really don’t have change that much, you tighten things up, you make it a bit more modern; however, as I sort of read through the table of contents from the third edition, I said, you know, this is a rewrite, we’re going to have to start again because so much has changed. And it’s not just that, obviously we’ve got a lot of CSS3, which is now possible for us to use in production, and one thing I’ve always thought with this book is it should be stuff that I would use myself, I’d happily use in a client project, because ultimately that’s what I am, I’m just a web developer, I work with client projects and other products, but I wanted this stuff in the book to always be things that people can use, not sort of experimental CSS, not stuff that needs to be used with a whole load of provisos. But, you know, we’re at a point where we can use a lot of CSS3, and there is a chapter in the book which deals with what to do if you have to support older browsers, and particularly the very old browser, things like IE6 and 7.

Louis: And 8 (laughs).

Rachel: IE8 for an awful lot of the stuff actually isn’t too much of a problem so –

Louis: Rusty, archaic clunkers like IE8.

Rachel: (Laughs) well, um, I mean, you know, I think an awful lot of the stuff that we cover actually works reasonably well in IE8, the real problems really the sort of old dinosaurs, certainly in my work I’ve had projects fairly recently where we’ve had to have very good IE6 support just because of the type of people viewing the site, so unfortunately it’s not completely gone away.

Louis: Right.

Rachel: But you know generally it’s forward thinking, it’s using stuff that works very solidly across modern browsers, of course, you know we’ll be looking forward to IE10 being released hopefully before too long, and IE8 then becomes a two-versions old browser, which hopefully will help things move on a bit. So, yeah, and not only have we got CSS3, we’ve also got a real change in approach in terms of how we’re building sites; I’m sort of really talking about responsive design. And I think although we haven’t actually got any real new ways of laying out sites, you know the actual techniques we’re using we’re still having to use floats, we’re still having to lay things out in very much the same way we have been, there’s some new stuff on the horizon which is very interesting in terms of layout, but it’s not there yet. However, while we’re still using the same tools, I think the way we’re thinking about layout is very different, and how we’re thinking about providing layouts that work for mobile devices and, you know, having sort of one web approach to design. And so I’ve covered a lot of that in sort of the chapters with layout, I’ve assumed that people are going to be thinking about working in a responsive or adaptive way.

Louis: Right. And that, I mean that’s increasingly becoming the standard, we’ve only seen maybe a few very high-profile sites adopt it, but I can’t imagine it’d be very long before we’d see a whole slew more.

Rachel: Yeah, that’s it. And obviously in this book these sorts of layout solutions are essentially one chapter, I can’t teach everything that I know about responsive design or everything that’s out there, but what I’ve tried to do is show people how to get started with making a site responsive, the sort of key tools they need. And that’s very much the approach of the whole book, you know, I get people started, I show a technique, and I hope that then people will use that and start experimenting from that point and play around a bit and see how things work.

Louis: Right. I imagine some of the stuff that must have been a lot of fun working on this book is seeing techniques that were five pages worth of delicate, nested div background image placement that became a one-line CSS declaration.

Rachel: Well, exactly, yeah, I mean stuff like rounded corners, we had this enormous section about how to implement rounded corners at one point, you know, with all these different ways, whether you might use sort of JavaScript or sticking images in (laughs), you know, and that was — and this is just one line.

Louis: It’s one paragraph, exactly.

Rachel: (Laughs) I mean it’s brilliant, and, yeah, I mean stuff like that, so that’s been, yeah, great fun actually in doing a new edition is sort of seeing all the bits I’ve just gone, nah, we can throw that away now (laughs), which is, yeah, it’s fascinating. And, you know, sometimes people say, oh, everything — things don’t change very quickly, but actually what we’re doing has changed hugely in the last few years; I think it’s only a couple of years since I wrote the third edition, and this stuff was all just on the horizon, you know, it was there but we couldn’t really use it.

Louis: Yeah, absolutely, and no one was thinking about responsive design or –

Rachel: No, no.

Louis: — we had fluid layouts but a lot of people didn’t like fluid layouts for a number of reasons.

Rachel: Well, I think, yeah, it got to that point where people were doing fixed width because they understood people had enormous screens, and so fluid layout just didn’t really work for that, and I mean, yeah, that kind of whole debate about fixed width versus fluid, it sort of got to the point where people were saying, yeah, I don’t like those long line lengths (laughs), and so actually responsive design has kind of turned all that round now, and we can have things which work well for large screens and small screens without having that horrible long line of problem and designers getting upset about that. So, you know, I think it’s great, I love working with responsive designs as a developer, I really enjoy it.

Louis: Yeah, it’s definitely a bit more work up front because you have to think a lot more about where things go.

Rachel: Yeah.

Louis: But once it’s accomplished you can just drag that window around forever. And I find that the — well, anyway, the weirdest thing for me is showing it to people who aren’t involved in web development, and I drag the window around, “see, look how it fits in all sizes,” and they’re like “I didn’t know that was a thing, is this good?”

Rachel: Well, the issue, and I’ve got a 14 year old daughter, and I always show — I’m showing her the site I’m currently working on and saying look at this, and she’s got an iPad and a Blackberry, because that’s what all the teenagers like, so, but I was showing and I was dragging the window around, and she’s like, “Doesn’t everything do that?” “Is that not just normal?” Because she kind of — you know, she sees websites very differently, I think, as a child, and being very used to mobile devices, and it seemed logical to her that some things should display differently no matter what you’re using.

Louis: Yeah.

Rachel: It seemed strange to her that things don’t (laughs), and I thought it was quite interesting, you know, sort of kids coming up and just get used to the fact that things work on phones, and to me it’s quite exciting, quite amazing.

Louis: Yeah, well I guess that’s true in any technology or any field, right, you come to it as a user expecting it to just work, but when you’re the implementer you get interested in all the little tricks that are required to make something feel like it just works.

Rachel: Yeah, and, you know, it’s really nice, at the moment I’ve got this little stack of devices on my desk which I’m constantly going through and looking at the site that I’m working on, and it’s actually really enjoyable to feel that you are presenting that nice experience no matter what people are using, and that’s something we’ve always tried to do, but I think we’re really kind of getting to a point now where we’ve got more tools to do that, and I think there’s sort of new things coming up for CSS layout as well that will make that even easier, so we are somewhat tied at the moment to things like source order and where we can actually put things. So, yeah, it’s an exciting time, it really feels at the moment like we’ve got so much new stuff, you know, going back to the vendor prefix issue I think it’s just making sure we use this new stuff responsibly and still care about the things that we’ve always cared about, caring about standards and caring about accessibility and the things that, you know, well, we get excited about all the new shiny, to do that in a responsible way in a way that moves the Web forward all the time.

Louis: And not forward off a cliff, forward in the direction we want to go in a safe and productive future.

Rachel: Yeah, I mean that’s it, and you know I’m really excited about the Web at the moment, I think that there’s lots of really interesting stuff happening.

Louis: Yep, and I keep saying this every time someone comes on basically, and we end sort of at the same place where the guest is just saying this is all great and wonderful and I’m really excited, and it’s fantastic to hear this sentiment echoed so consistently across such a wide range of people working in so many different areas of the Web.

Rachel: Yeah, and I’ve been to the Web Conference and things recently, and talking to a lot of people who were sort of around my age or have been doing this for as long as I have, and everyone just seems really kind of, yeah, reinvigorated and excited about what’s going on at the moment, which there are some really great minds out there in terms of people thinking about the Web, and it’s good to see older people as excited as sort of new people coming in who you kind of expect to be enthusiastic and excited because they’re new and they’ve just found out about all this stuff. But I think that mix of younger people and new people coming in with all their sort of ideas and enthusiasm, and those of us who’ve been around a long time and perhaps can temper that with a bit of we don’t want to go down this route because we did last time (laughter). I think that’s great, and the fact that everyone’s excited about it from all their different viewpoints is really important, and I think will sort of push things forward in good ways.

Louis: Yeah, that’s fantastic. So, I wanted to thank you so much for taking the time to come on the show, I know it’s a little hard to work out time zones, especially with Australia and the UK are particularly difficult, but very much appreciate it, I want to wish you all the best of luck on the book if you’ve got any work left.

Rachel: Yeah, it’s getting there.

Louis: Fantastic. So to anyone listening, The CSS Anthology fourth edition will be out soon with SitePoint, so keep your eyes and ears peeled. If people want to find you online do you want to drop some links to either your website, Twitter?

Rachel: I’m @rachelandrew on Twitter, and rachelandrew.co.uk is my personal site, edgeofmyseat.com is the business site.

Louis: Fantastic. So thanks again for coming on.

Rachel: Okay, thank you.

Louis: And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to Sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict. The show this week was produced by Karn Broad and I’m Louis Simoneau, thanks for listening and bye for now.

Theme music by Mike Mella.

Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.

How to Create a CSS3-Only Horizontal Accordion Using the :target Selector

Posted on February 23, 2012 by Craig Buckler

The CSS3 :target selector is incredibly powerful and allows us to create attractive widgets which would have required ninja-like JavaScript skills a few years ago. We’ve already built a tab control and a vertical accordion. In this post, we’ll create a horizontal accordion using the same HTML5 markup.

View the demonstration page…

The solution works in IE9, Chrome, Firefox, Safari and Opera and doesn’t require JavaScript or images. Again, it fails miserably in IE6, 7 and 8 so you either need a JavaScript shim such as selectivizr or some other fallback.

The HTML

Here’s a reminder of the HTML5 code. It’s identical to our vertical accordion: there are a number of section elements with clickable headings contained in the initial h2 tag:


<article class="accordion">
	<section id="acc1">
		<h2><a href="#acc1">Title One</a></h2>
		<p>This content appears on page 1.</p>
	</section>
	<section id="acc2">
		<h2><a href="#acc2">Title Two</a></h2>
		<p>This content appears on page 2.</p>
	</section>
	<section id="acc3">
		<h2><a href="#acc3">Title Three</a></h2>
		<p>This content appears on page 3.</p>
	</section>
	<section id="acc4">
		<h2><a href="#acc4">Title Four</a></h2>
		<p>This content appears on page 4.</p>
	</section>
	<section id="acc5">
		<h2><a href="#acc5">Title Five</a></h2>
		<p>This content appears on page 5.</p>
	</section>
</article>

The CSS

The CSS is a little more complex but it’s worth it. First we style our outer article container:


article.accordion
{
	display: block;
	width: 43em;
	margin: 0 auto;
	background-color: #666;
	overflow: auto;
	border-radius: 5px;
	box-shadow: 0 3px 3px rgba(0,0,0,0.3);
}

Each section starts in its closed state; they’re floated to the left and have a width of 2em. Overflow is set to hidden and we’re also making the text color the same as the background so they effectively look like solid blocks without content:


article.accordion section
{
	position: relative;
	display: block;
	float: left;
	width: 2em;
	height: 12em;
	margin: 0.5em 0 0.5em 0.5em;
	color: #333;
	background-color: #333;
	overflow: hidden;
	border-radius: 3px;
}

Now for some nasty prefixed CSS3! Each h2 title is rotated 90° counter-clockwise using a transform and absolutely positioned over the closed section:


article.accordion section h2
{
	position: absolute;
	font-size: 1em;
	font-weight: bold;
	width: 12em;
	height: 2em;
	top: 12em;
	left: 0;
	text-indent: 1em;
	padding: 0;
	margin: 0;
	color: #ddd;
	-webkit-transform-origin: 0 0;
	-moz-transform-origin: 0 0;
	-ms-transform-origin: 0 0;
	-o-transform-origin: 0 0;
	transform-origin: 0 0;
	-webkit-transform: rotate(-90deg);
	-moz-transform: rotate(-90deg);
	-ms-transform: rotate(-90deg);
	-o-transform: rotate(-90deg);
	transform: rotate(-90deg);
}
article.accordion section h2 a
{
	display: block;
	width: 100%;
	line-height: 2em;
	text-decoration: none;
	color: inherit;
	outline: 0 none;
}

We can now ‘open’ the active section using the :target selector. The section width and colors are changed and the title is moved back to the top:


article.accordion section:target
{
	width: 30em;
	padding: 0 1em;
	color: #333;
	background-color: #fff;
}
article.accordion section:target h2
{
	position: static;
	font-size: 1.3em;
	text-indent: 0;
	color: #333;
	-webkit-transform: rotate(0deg);
	-moz-transform: rotate(0deg);
	-ms-transform: rotate(0deg);
	-o-transform: rotate(0deg);
	transform: rotate(0deg);
}

That’s fine, but a CSS3 transition makes it look fantastic:


article.accordion section,
article.accordion section h2
{
	-webkit-transition: all 1s ease;
	-moz-transition: all 1s ease;
	-ms-transition: all 1s ease;
	-o-transition: all 1s ease;
	transition: all 1s ease;
}

View the demonstration page…

It’s a shame IE6, 7 and 8 users can’t use the widget. IE9 users won’t see animation either. But you’d need a lot of time and patience to achieve the same effect using JavaScript! Have fun with it.

7 Solutions to the CSS3 Vendor Prefix Crisis

Posted on February 21, 2012 by Craig Buckler

As we reported last week Mozilla, Microsoft and Opera have become frustrated with sites which only target -webkit CSS3 properties. It makes their browser look bad even when it implements identical or better technology. To solve the issue, they propose adding -webkit prefix support to the non-webkit browsers.

While this is largely a marketing decision, it’s a real problem. The solution appalls many web developers but we deserve our share of the blame. In this article we’ll discuss the options, pros and cons.

1. Nothing Changes

Assume nothing is done to solve the browser prefix problem.

PROS

Browsers continue to implement their own prefixes which you are free to use or ignore.
There’s nothing new to learn or test.
It feels right and the decision will please the majority of web developers.

CONS

We retain the four prefixed and one standard property. Stylesheets are larger than necessary and difficult to test.
Lazier or less experienced developers will continue to target webkit browsers only.
Chrome and Safari’s market share could rise to a point which makes other browsers redundant. We return to the days of single browser engine and innovation stagnates. The dark days of IE6-like dominance return.
Microsoft, Mozilla and Opera consider this to be a real problem: doing nothing is not an option.

2. Non-Webkit Browsers Support the Webkit Prefix

Assume IE, Firefox and Opera support webkit-prefixed properties.

Microsoft had already implemented -webkit-text-size-adjust in the mobile version of IE. While it’s a non-standard property for Safari (there’s no text-size-adjust), they listened to community feedback and pulled support. That’s unlikely to happen again if Mozilla or Opera start adding webkit properties to their engines.

PROS

It’s a quick and dirty solution which allows non-webkit browsers to render as well as Chrome or Safari.
There’s no need for developers to update their websites.
-webkit will become the dominant prefix; using -moz, -ms or -o will become unnecessary and CSS file sizes will reduce
It prevents webkit, Google and Apple becoming too powerful. If another vendor disagrees with an implementation, they can simply break it or provide an alternative. Developers may not be able to use the property in any browser.

CONS

It feels wrong: one browser should not need to masquerade as another.
It rewards sloppy development practices.
Differing browser implementations will make some properties unusable.
If developers retain webkit properties which fail in other browsers, more users will switch to Chrome and Safari. Other vendors will become increasingly irrelevant.

3. All Browsers Use a -beta Prefix

Rather than separate prefixes, assume every browser implemented the same -beta prefix.

PROS

Just one prefix to learn and use.
Stylesheet file sizes are reduced.
The property is obviously experimental; developers will be more cautious about using it.

CONS

As a solution, it’s little different to every vendor adopting the -webkit prefix.
Differing browser implementations may make some properties unusable.
Vendors are unlikely to remove their own prefixes; the situation won’t change.

4. Experimental CSS Properties Only Appear in Beta Browsers

Assume prefixed properties are abolished in all browsers. Newer experimental properties would only be present in nightly and beta releases — and they would not require a prefix.

PROS

It becomes impossible for developers to use prefixed code or target specific browsers in production websites.
Webkit-only sites are punished accordingly.
We all work to final standards — not future ones.

CONS

Far fewer developers will use and test experimental properties. It could lead to buggier implementations.
New properties may take several years to become standardized. Are we prepared to wait?
It’ll never happen. If a single vendor chooses to keep prefixes in their main release, they all will.

5. Vendor Prefixes are Dropped Following Final Implementation

Once a property is stable and implemented without a prefix, all previous prefixed versions are removed from the browser.

PROS

It’s a logical solution.
It removes unnecessary code. Library bloat is reduced and browsers become leaner and faster.
It rewards good development practices and punishes the bad.

CONS

It offers no immediate resolution for sites which only target webkit browsers.
It will break sites overnight — vendors will be reluctant to implement the policy.
Properties can take years to reach standardization and browser implementation schedules differ. Prefixes will break at different times so ongoing site testing and maintenance is required.

6. The W3C Agreement Process Becomes Faster

Assume the W3C adopt quicker methods of standardization and publish schedules detailing when a property is expected to reach maturity.

PROS

The existing process is too slow.
Developers will know when the final property can be used.
There’s less chance for vendor prefixes to gain widespread adoption.

CONS

The process is not intentionally slow. There will always be practical and logistical problems to overcome.
Vendors work at different speeds and it’s impossible to accurately estimate delivery times.
A faster approval process could lead to poorer implementations which negates the point of having a standardization process.

7. Better Evangelism and More Education in the Developer Community

We would not be in this mess if developers wrote cross-browser code and understood best-practice techniques.

PROS

It’s a good solution which we can implement today.
Anyone demonstrating example code with prefixed properties can provide browser support information with strong disclaimers.
Everyone can help. Fix your own code and contact sites which are not cross-browser compatible.

CONS

There’s no guarantee evangelists and developers will change their attitude.
Is it too late? Best-practice techniques are published but ignored.
There’s no definitive central information repository.
There will always be new, ignorant and sloppy developers. No one can become an expert overnight.

There’s no single solution to the vendor prefix problem. Personally, I favor a quicker W3C process, dropping prefixes after implementation and better evangelism. But those require a major shift in mindset rather than technical changes.

Ultimately, developers caused this problem: it’s up to us to fix it. There won’t be an issue if we shun prefixed properties or use correct cross-browser fallbacks. If we don’t, there’s a risk the CSS3 properties we rely on today won’t work tomorrow.