Creating accessible "web 2.0" applications can be a tricky process. Many of the advanced widgets and controls we develop today don't exist in the current HTML specification — there is no "slider" or "accordion" or "menu" element, so we must create one from scratch using markup that isn't semantically correct (divs, spans, unordered lists and the like), and layer on the appearance and behavior using CSS and Javascript. This works well when your audience is using a standards-compliant browser, but what about those using older browsers or mobile devices that only partially support the styles and scripts necessary for it to work? And how do you make the fully functional version — a block of non-specific divs and spans — accessible to assistive technology, like screen readers?

The solution we devised is based on the core principle of progressive enhancement: start with basic, functional markup and then layer on complexity, if supported. In most cases, coding for progressive enhancement allows us to build a single code base for both the basic and enhanced versions; we then apply additional CSS and Javascript to create the richer experience for capable browsers. But when we're developing the UI for a web application and creating widgets that capture data, we're often starting with form element markup that doesn't readily cooperate with CSS, or that doesn't have all the moving pieces necessary to create a more complex widget.

To solve this problem, we developed an "element API" — a script that combs a form element for relevant information (data values, key structural characteristics), and uses that information to build a new widget on the fly and insert it into the DOM. Below we describe a test case that outlines our process for making this work.

An "element API"

Recently we designed and developed an interface that required a slider control, which allows users to choose one or a range of values on a continuum. Values on a slider can represent anything from hours on a clock to the volume on a music player to a complex, proprietary data set. In its simplest form, the slider is displayed as an axis of values with a handle to drag and select a value, or two handles for selecting a range.

Because there is currently no slider element in HTML, the slider is made up of non-semantic markup (divs, spans), and requires advanced CSS (positioning, background images) and Javascript to work properly. In the absence of CSS or Javascript, the slider is unusable, and the markup is meaningless to users navigating the page with keystrokes or screen readers.

For the slider to be usable in the absence of styles and scripts, we decided that alternate markup is necessary — rather, we applied the principals of progressive enhancement and looked for an analogous HTML form element that could do the job on its own, something with similar features and functionality that:

• supports selecting a single value, or a range,
• provides feedback on the value selected, and
• allows for a default value to be set.

We chose the <select> form control because, like sliders, it natively performs the functions listed above, and also comes with the added bonus of grouping multiple options (with the <optgroup> tag) and clean management of large data sets. Then, to make the slider we created a script — an element API, or connector script — that leveraged the structure, data values, and labels in the standard select element. The select is served to all browsers, and if the browser can support the slider's advanced styles and scripts, it's hidden and a slider is inserted into the page.

So we took a standard select element:

<select name="speed">
	<option value="Slower">Slower</option>
	<option value="Slow">Slow</option>
	<option value="Med">Med</option>
	<option value="Fast">Fast</option>
	<option value="Faster">Faster</option>
</select>

And used it to create a slider when the browser is capable of rendering advanced CSS and Javascript:

<div class="sliderControl">
	<ol class="xScale clearfix">
		<li class="Slower"><span>Slower</span></li>
		<li class="Slow"><span>Slow</span></li>
		<li class="Med"><span>Med</span></li>
		<li class="Fast"><span>Fast</span></li>
		<li class="Faster"><span>Faster</span></li>
	</ol>
	<div class="scale">
		<span style="left: 0pt;"/>
		<span style="left: 31px;"/>
		<span style="left: 62px;"/>
		<span style="left: 93px;"/>
		<span style="left: 124px;"/>
	</div>
	<div aria-valuemax="Faster" aria-valuemin="Slower" role="slider" class="indicator1 sliderIndicator" tabindex="1" aria-valuetext="Slower" aria-valuenow="Slower">
		<span class="indicatorFeedback1">Slower</span>
	</div>
</div>

Need to capture a range of values?

We developed the connector script to be smart — it acts on a single container element and detects the number of child select elements. When a single select is found, the script injects a slider with one pull handle for choosing a single value on the continuum. When a second, identical select element is found in the container, the script injects a slider with two pull handles for specifying a range of values as shown in the example below. Users without advanced CSS and Javascript can simply choose the low and high end values from each select, respectively.

Our process

Start with solid markup

When writing the markup for the select control, we paid particular attention to how the select's standard child elements, values, and text map to similar elements in the slider:

• the number of options (<option>) is used to calculate the scale and distance between labels on the slider axis
• option selected attributes (selected="selected") are translated into default values on the slider
• option value attributes (value="abc") provide feedback in the form of a "tooltip" that sits above each slider handle
• option text nodes (<option>Text</option>) become the labels along the slider axis
• optgroup elements (<optgroup>) are used for dividing the axis into regions, like AM and PM, and
• optgroup label attributes (<optgroup label="AM">) are used to identify the axis regions.

Apply enhanced CSS and Javascript, if supported

As the page loads, we test the browser to see if it's capable of rendering advanced styles and scripts correctly. If it fails the test, nothing happens — the browser renders the simple, fully functional markup it started with. But if it passes, the test script applies advanced styles and scripts for a richer, more interactive experience. That's when we use the script to hide the select and insert the slider. (We describe how we test a browser's capabilities and provide an enhanced experience in Delivering the right experience to the right device.)

Really important side note: we wrote the connector script — a plugin based on an older version of the jQuery library — that specifically builds a slider from a select element. The script that runs the slider is part of the Interface UI library, also based on jQuery. If you'd like to reproduce this code, we strongly recommend that you grab the latest version of jQuery and create a new slider — a good starting point may be the updated slider in jQuery's UI library. You're welcome to use our connector script as a model, just keep in mind that it will need to be updated and edited for production-ready code.

Keep it accessible for all users

The slider markup is injected into the DOM immediately after the select element, and the select is hidden visually (it's still in the source). Events assigned through the DOM allow the user to manipulate the slider, which in turn updates values in the hidden select element so that the correct select option is submitted with the form. And since the select element is still technically on the page, users with assistive devices can use it in place of the slider.

We've also added attributes to the slider component as specified in the WC3's ARIA spec. ARIA attributes provide another layer of accessibility because they allow developers to declare the role of each non-semantic widget. Browsers such as IE8 and Firefox 3 have begun to support these features, so we're excited to begin using them in our applications.

A slider can be made ARIA-accessible by adding the following attributes to the slider handle (which in this case is a div element):

• tabindex allows the element to receive keyboard focus
• role="slider" makes the assistive device aware of the slider control
• aria-minvalue is the minimum value in the slider scale
• aria-maxvalue is the maximum value in the slider scale
• aria-valuenow is the currently selected value
• aria-valuetext is a user-friendly equivalent of the currently selected value

The markup with ARIA attributes:

<div role="slider" aria-valuemin="6am" aria-valuemax="8pm" aria-valuetext="11am" aria-valuenow="11am" tabindex="1"&t;</div>

The slider examples shown here are ARIA-accessible, and currently some key events are in but need more work to be fully functional. Making the key events work correctly is something we consider to be a necessity, so it's something we'll continue to refine.

We're always looking for ways to improve our code and its accessibility — in particular, we're working on ways to make the "API" more generic — so If you have any ideas about how to fine tune this concept, please drop us a line.

Along with the founders, Dan Cederholm and Ethan Marcotte, we hosted the latest meeting of the Markup & Style Society in our office on South Street Thursday night.

All told it was a great success — about fifty designers and developers from the area joined us to talk shop about building responsive, stretchy layouts, what it means to be a craftsman (or -woman) in this space, and a new method for applying progressive enhancement to web applications. Some highlights:

Ethan Marcotte (Airbag Industries, Unstoppable Robot Ninja), enlightened us in the ways of making a stretchy layout where all components — including static images, images generated from Flash (sIFR), and even embedded objects — resize with the browser.

Dan Cederholm (SimpleBits) reviewed how to apply grid-based design to stretchy layouts by using ems to specify size, and how to constrain the layout to the size of the browser window so that horizontal scrollbars don't appear (set the layout container's width to 100%).

Joshua Porter (Bokardo Design) discussed the importance of maintaining a craftsman's integrity when approaching web design and development work, and how that can have a positive effect on collaborations.

Our own Scott Jehl capped the night and presented a technique that we're refining to help us better apply progressive enhancement to our code. It's a script called testUserDevice.js, and you can learn about how it works and download it from our lab article, Delivering the right experience to the right device | Download Slides (1mb).

We were impressed with the knowledge, inspired by the enthusiasm, and energized by the positive feedback and new connections that we made. Thanks to all who attended and shared their ninja secrets. And special thanks to the folks at Freshview for the pizza and beer.

Inspired by Jeremy Keith's concept of Hijax, we've adopted the practice of coding with progressive enhancement in mind to ensure optimal accessibility, compatibility with multiple browsers and platforms, and ease of maintenance for each site or web application. But how do you do that when so many browsers only partially support javascript and CSS techniques? We met the challenge by developing a script to test the browser's ability to handle modern coding techniques, and ensure a usable experience for all.

Why is progressive enhancement important?

We presented this technique at the Markup & Style Society on March 13, 2008. Download Slides (1mb PDF)

In a word: accessibility. Most of the web sites and applications we design and code are intended for a wide audience, be it a targeted segment of the general public, the client's own organization, or both, and our intention is to provide a usable experience to everyone. In most cases that means developing front-end code that supports the required functionality and design elements on a variety of browsers and platforms, some of which are standards-compliant and render complex Javascript animations and visuals flawlessly, and some of which render those same modern script and style techniques poorly (and that's putting it kindly). The ongoing challenge is to develop code that provides the richest experience to the broadest audience, and at the very least a clean and usable experience to those using non-compliant browsers.

Coding for progressive enhancement allows us to meet that challenge with a single code base. (In some exceptional cases it may make sense to fork the code to meet the functional requirements of different devices, but most often we find that creating and maintaining multiple code bases is unnecessary when the it's written with progressive enhancement in mind.)

We start with plain, structured, semantic HTML and layer on functionality to provide an enhanced experience to capable browsers. The end result of this approach is:

• Modern, standard-complaint browsers render a rich, interactive experience including accurate rendering of the visual designs with multi-column layouts, background colors and images, and Javascript-based interaction and animation.
• Depreciated, mobile or text-only browsers render clean, fully usable and well-formatted pages with minimal style and without interaction effects. As an added benefit, this approach also makes it possible to provide a clean, well-structured experience for users accessing the sites from mobile devices, screen readers and other accessibility support aids.

How do you know if a browser supports advanced CSS and Javascript?

There are a few well-known ways to prevent non-compliant browsers from rendering particular styles, like using tricky reference syntax, or doing object detection to prevent a browser from executing a specific function. But we found ourselves running into cases of partial support, where a few browsers would support some but not all of the latest CSS or DOM specification correctly.

Rather than complicate our markup and scripts with numerous exceptions or resort to the less reliable method of browser version sniffing, we decided to take matters into our own hands and created a comprehensive test to determine if a browser is capable of doing what we want it to do: floated column layouts, interactive widgets, animation effects, and so on. If the browser passes, we apply all of our styles and complex interactions; if the browser fails, it skips the fancy CSS and Javascript and renders a basic, clean — and fully usable — version of the site.

Our solution: use javascript to detect CSS

We can figure out which browsers support the richest experience by a process of elimination. To begin, if javascript is disabled, the test won't run and the page loads with basic HTML and styles. But if javascript is enabled, we can run the test and apply styles using CSS, and then test their display accuracy using common javascript equivalents. For example, we can set the width on an element with css and then check its width using offsetWidth. Or we could float two elements and then evaluate their offsetTop values for equality.

What we test for

Immediately after the body element is ready, testUserDevice.js evaluates a device's ability to handle the following css properties properly:

• Box model: make sure the width and padding of a div add up properly using offsetWidth
• Positioning: position a div and check its positioning using offsetTop and offsetLeft
• Float: float 2 divs next to each other and evaluate their offsetTop values for equality
• Clear: test to make sure a list item will clear beneath a preceding floated list item
• Overflow: wrap a tall div with a shorter div with overflow set to 'auto', and test its offsetHeight
• Line-height (including unitless): test for proper handling of line-height using offsetHeight, primarily to rule out Firefox 1.0

It also tests the following javascript capabilities:

• Basic DOM traversal
• Window Resize Detection
• Printing
• A little additional object detection to rule out certain browsers that have known CSS bugs that cannot be easily tested for, like faulty background-image rendering in Netscape 7.0

If the browser fails any of the above tests, the script will return false and the browser will render the clean, well-structured markup on the page with few styles and no interaction effects — users will still have access to all of the content, but will just experience a plainer version of it.

Generally, these tests are set up to target known issues of devices we do not intend to support, but they are performed in a way that is unbiased to the device being tested and will work with future devices as well.

What happens when a device passes?

Upon successful completion of the test, advanced styles and interaction effects are applied to the basic markup through the DOM:

• Any script passed in as an argument will be forwarded along to execute on DOM ready. (The test script contains a library-independent DOM-ready function but it will use jQuery's instead if it is available.)
• A class of "enhanced" is assigned to the body element to be used for optional CSS scoping (such as: body.enhanced {background: red;})
• Any links to alternate stylesheets that have a class of "enhanced" will be enabled. In order for this to work, each alternate stylesheet must have a title attribute.
• Any links to stylesheets that have a class of "basicNoCascade" will be disabled. This is optional depending on whether your enhanced stylesheets cascade or conflict with your basic sheets.
• A cookie is set (enhanced = true) to notify the script on future page loads that the browser has already passed and can receive an enhanced experience.

Users with successful browsers will experience the design as intended, with the complete and intact visual design and complex interactivity.

Usage

To apply testUserDevice.js, simply grab the file linked below and link to it in the head of your html file. Enclose any DOM-related script executions within the following function:

 enhancedDomReady(function(){
  //put scripts here to be executed after the 
  //dom is ready and the browser has passed the test
 });

Download Script: testUserDevice.js

Results Matrix

By running this test, we're able to ensure that all browsers render a usable experience to our entire audience — the only difference is that browsers that fail render well-structured HTML with minimal styling and no interaction effects, while browsers that pass render the enhanced experience with rich visuals and fully interactive elements. The following tables represent the division of browsers:

This article describes a solution we've developed that automates the age-old task of preloading images in web applications. It uses javascript and is packaged as a jQuery plugin, but the concept could easily be ported to other libraries or plain old Javascript as well.

Why is preloading important?

Web applications tend to involve a multitude of background images for elements and states that aren't in view when the page loads. In traditional web apps these images are used for rollover states for links and buttons, but Ajax applications have expanded the list to include images for inline messaging, tooltips, toggled content, overlay panels, and even entire pages of content that could potentially wind up in an interface. In order to create a snappy desktop-like experience on the web, images must be preloaded so that there is no blinking or fragmented loading. We found that our current options for preloading images were both insufficient and time-consuming, and it was clear that we needed to find a new approach.

How preloading is usually done

Developers tend to employ a couple of common practices:

• CSS Sprites: Combine all states of an image (default, rollover, active) into a single image file and use CSS to position and crop it into place. While this solves the problem of preloading image states that aren't visible when the page first loads, it doesn't address how to preload background images that appear when new content is loaded via Ajax.
• Using JavaScript to create image objects from filenames: Create an array of background-image filenames that need preloading, then loop through that array to create an image object for each image file. This ensures that images are cached and ready for later use, but often the number of images required in a complex Ajax application can be up to 50, 100, or more. On top of that, inevitable design changes throughout a development process mean constantly updating and adding file paths, which would lead most developers to simply not do it.

A typical array of images for preloading with JavaScript:

var imagesToLoad = 
  [
     'image1.gif', 
     'image2.gif', 
     'image3.gif', 
     'etc...'
  ];

How is this script different?

Our script parses through linked and imported stylesheets and creates an array of all the image urls they contain. Then it loops through the array of urls and creates an image object for each one so they'll be cached and ready for later use. Sound familiar? That's because it's nearly the same as the traditional JavaScript approach, but with the major added advantage of automation. Using this script means we only have to worry about specifying background images and states in our CSS files, and the script takes care of the rest.

Take it straight from the source:

/*
 * --------------------------------------------------------------------
 * jQuery-Plugin "preloadCssImages"
 * by Scott Jehl, scott@filamentgroup.com
 * http://www.filamentgroup.com
 * reference article: http://www.filamentgroup.com/lab/automated_image_preloading/
 * demo page: http://www.filamentgroup.com/examples/preloadImages/
 * 
 * Copyright (c) 2008 Filament Group, Inc
 * Licensed under GPL (http://www.opensource.org/licenses/gpl-license.php)
 *
 * Version: 1.0, 31.05.2007
 * Changelog:
 * 	02.20.2008 initial Version 1.0
 * --------------------------------------------------------------------
 */
$.preloadCssImages = function(settings){
	//overrideable defaults
	settings = jQuery.extend({
		 imgDir: 'images'
	}, settings);

	//dump all the css rules into one string
	var sheets = document.styleSheets;
	var cssPile = '';
	for(var i = 0; i<sheets.length; i++){
		var thisSheetRules = document.styleSheets[ i ].cssRules;
		for(var j = 0; j<thisSheetRules.length; j++){
			cssPile+= thisSheetRules[ j ].cssText;
		}
	}
	//parse string for image urls and load them into the DOM
	var allImgs = [];//new array for all the image urls  
	var imgUrls = cssPile.match(/[^\/]+\.(gif|jpg|jpeg|png)/g);//reg ex to get a string of between a "/" and a ".filename"
	if(imgUrls != null && imgUrls.length>0 && imgUrls != ''){//loop array
		var arr = jQuery.makeArray(imgUrls);//create array from regex obj	 
		$(arr).each(function(k){
			allImgs[ k ] = new Image(); //new img obj
			allImgs[ k ].src = settings.imgDir +'/'+ this;	
		});
	}
	return allImgs;
}

How do I use it?

Paste the code above into your JavaScript file and run $.preloadCssImages() when the DOM is ready. Don't forget that you'll also need to reference the jQuery javascript library in your page. By default, the script assumes a root directory called 'images'. This default directory can be overridden by passing a different imgDir value to the settings object like so: $.preloadCssImages({ imgDir: 'myImagesDirectory' });

Time for a demo

The example below uses our script to parse through a sample stylesheet which we've linked to the page. The sample stylesheet has background image rules for elements that don't actually exist on the page, so the images specified are not currently loaded. Clicking the button below will load them into the DOM. For example purposes, we've written the loaded images into the page as well.

Download preloadCssImages.jQuery.js

This script is a jQuery plugin, meaning is is dependant on the incredible jQuery javascript library. If you feel particularly adventurous, this script could be easily ported to another library or written in plain old JavaScript as well. Feel free to grab the script and try it for yourself. We're always looking for ways to improve our scripts, so if you encounter any issues or have any questions or suggestions please leave a comment below.

Future plans for preloadCssImages.jQuery.js

Currently this plugin assumes that all images are held in a single directory. Down the road, we would like to extend the script so that image paths are worked out in relation to the location of the CSS file, enabling images to be loaded from different directories on a server.

Data visualization in HTML has long been tricky to achieve. Past solutions have involved non-standard plugins, proprietary behavior, and static images. But this has changed with the recent growth in support for the new HTML Canvas element, which provides a native drawing API that can be addressed with simple Javascript. This article is a proof of concept for visualizing HTML table data with the canvas element.

The idea of visualizing HTML table data has been a hot topic lately. The first mention of it that we have seen was Christian Heilmann's YUI blog entry, which provides a clean solution for the problem using the Yahoo library. The idea is a good one: having the data on the page in a table allows it to be accessible, and the chart can be shown as a visual enhancement. Our attempt at solving the problem uses jQuery and provides several types of graphs, such as Pie, Line, Area, and Bar.

So how does it work?

First the markup:

We start with a regular old HTML data table like the one shown below:

<table id="dataTable" summary="Member Data from 2000 to 2006">
	<caption>Member Data from 2000 to 2006</caption>
	<thead>
		<tr>
			<td></td>
			<th id="2000">2000</th>
			<th id="2001">2001</th>
			<th id="2002">2002</th>
			<th id="2003">2003</th>
			<th id="2004">2004</th>
			<th id="2005">2005</th>
			<th id="2006">2006</th>
		</tr>
	</thead>
	<tfoot>
		
	</tfoot>
	<tbody>
		<tr>
			<th headers="members">Mary</th>
			<td headers="2000">150</td>
			<td headers="2001">160</td>
			<td headers="2002">40</td>
			<td headers="2003">120</td>
			<td headers="2004">30</td>
			<td headers="2005">70</td>
			<td headers="2006">70</td>
		</tr>
		<tr>
			<th headers="members">Tom</th>
			<td headers="2000">3</td>
			<td headers="2001">40</td>
			<td headers="2002">30</td>
			<td headers="2003">45</td>
			<td headers="2004">35</td>
			<td headers="2005">49</td>
			<td headers="2006">70</td>
		</tr>
		<tr>
			<th headers="members">Brad</th>
			<td headers="2000">10</td>
			<td headers="2001">00</td>
			<td headers="2002">10</td>
			<td headers="2003">85</td>
			<td headers="2004">25</td>
			<td headers="2005">79</td>
			<td headers="2006">70</td>
		</tr>
		<tr>
			<th headers="members">Kate</th>
			<td headers="2000">40</td>
			<td headers="2001">80</td>
			<td headers="2002">90</td>
			<td headers="2003">25</td>
			<td headers="2004">15</td>
			<td headers="2005">119</td>
			<td headers="2006">200</td>
		</tr>		
	</tbody>
</table>

For the charts, we place Canvas elements in the markup with class names that are descriptive of their chart type and source.

<canvas id="chart1" class="fgCharting_src-dataTable_type-pie"></canvas>

As you can see, we've created somewhat of a custom syntax in our class names. The syntax begins with "fgCharting" and is followed by key/value pairs which are separated using underscores and matched using dashes. Using this syntax, the above class name tells our script that the source ("src") is a table with an ID of "dataTable", and our chart type ("type") is Pie. Note: There are many other ways this could be handled, and including the chart settings in the markup may not be the best separation of markup and behavior, but for the purposes of this example it seems to work well.

And now for the Scripting:

Once we have jQuery and our charting library attached, we can convert our canvas elements into charts with the following line of javascript:

$.fgCharting();

A live demo

The following demo uses the markup and scripting mentioned above. For example purposes, the following table is editable, so if you change the values the Pie will redraw in real time!

Cool! What about different charts?

We've developed several other types that can be specified using our library; these are:

• line
• filledLine
• additiveLine
• additiveFilledLine
• pie
• bar
• additiveBar

Since these charts involve different groupings of data, our script organizes the table data in multiple ways. For example, Pie charts need the total table sum, each member's individual total, and each member's name. However, line, bar, and area (filled) charts need to know each member's value at every point on the X scale. Because of these differences, our script collects an object of the following properties and passes it along to the chart builder:

• members: member names
• allData: array of every value in the table
• dataSum: sum of all members in the allData array
• topValue: highest value in the table
• memberTotals: array of totals for each member
• yTotals: array of y-axis totals
• topYtotal: highest value in the yTotals array
• xLabels: labels for the X axis of line, bar, and area charts
• yLabels: labels for the Y axis of line, bar, and area charts
• yLabelsAdditive: y labels for the Y axis of additive charts

More chart types: (data table hidden visually)

The following example shows some more examples of charts that our library can generate.

Grab our script

You can download our charting library source here: fgCharting.jQuery.js

Note: Be sure to download the jQuery javascript library as well, as our charting library depends on it!

Browser support

Canvas is not natively supported in Internet Explorer, but lucky for us, the smart folks at Google have made a patch that uses purely javascript to port Canvas support to IE! We've included their library for our examples and it can be downloaded here: ExplorerCanvas.

Looking ahead

There are many charting libraries out there today that use Canvas and many of them go well beyond what we've demonstrated above. We feel that the major advantage of this technique is that the data is accessible to users on any device. Looking ahead, we hope to develop a library that is much more focused on retrieving the table data in a way that is similar to accessing a database with SQL statements. This library would then allow its data to be sent to more advanced charting libraries such as Flot, to create truly dynamic data visualizations.

This script was developed to allow for quick conversion between pixel and em values so that page scalability can be retained throughout the course of a web application. It appends a method to the native string object and leverages the jQuery library for its rapid selectors.

Why Ems, Anyway?

In CSS layouts, ems are often used in place of pixels to allow elements and text to scale in unison. Although pixels tend to be easier to use and more precise, many browsers such as Internet Explorer can not scale text that is set in pixels. By using ems for not only our text, but also the heights and widths of structural elements, we can allow parts of the page layout to scale in proportion to the text size.

How do they work?

In brief, an em is a relative unit that is equivalent to the height of a font. Since most browsers' default font size is 16px, we can assume that 1em is equal to 16px; meaning that 12px is equal to 0.75em, and 10px type is equal to 0.625em. As you can see, it can be quite tedious to calculate em values this way, and luckily a method was developed by clagnut to alleviate the problem. By simply setting the body element's font size to 62.5%, the value of 1em becomes 10px. This allows for nice and easy calculations to ems by simply dividing a pixel value by 10.

The inconveniences of using ems do not stop there however, since the value of 1em can vary depending on parent/child relationships in the DOM. For every element on the page, the value of 1em is calculated based on the font size of its parent element. This means that while a paragraph may have a font size of 1.2em and appear to be 12px tall, all of its children will exist in a world where 1em is equal to 12px instead of 10. This sounds like a similar situation to where we started.

Where Ems are Often Abandoned

As confusing as managing an em-based stylesheet might get though, it usually doesn't cause any major setbacks to web developers. We find that the problems more often occur when elements are inserted or modified with javascript. During animation effects or modifications to the DOM, many javascript libraries style elements using pixels to avoid the possibility of conflicts. While pixels are often desired and are a good default, we usually want our modifications to fit within a scalable interface. For this reason, we've come up with a method that converts pixel values to ems on the fly, and always calculates within the scope it is given.

So how does it work?

When called, pxToEm converts a given pixel value to ems. By default, it uses the body's font size for scope, but a scope property can be passed to handle conversions that are relative to another element's font size.

Sample Output:

var pixelValue = 256; 
var emValue = pixelValue.pxToEm(); 
==> returns '25.6em'

The sample above may look like a simple division of 10, but the script actually checks the font size of the body before calculating so it will work in many environments. To demonstrate how scope is used, consider the following example which uses a scope property.

Sample Output Using a Scope Element:

var pixelValue = 256;
var scopeElement = $(myElement); //element being used for scope. It has a font size of 14px.
var emValue = pixelValue.pxToEm({'scope': scopeElement}); 
==> returns string "18.29em"

We can see that pxToEm has used the font size of the scope element for its calculation above. Using a scope parameter would be useful for figuring out dimensions when inserting an element into the scope element.

But What About Ems to Pixels?

Don't worry, we didn't leave you hangin'! A second optional property called 'reverse' defines the direction of the conversion. Simply pass a reverse parameter as true and pxToEm will convert your value to pixels. The following calculator demonstrates the flexibility and capabilities of this plugin.

Demo Calculator

Sweet! How do I use it?

First, you'll need to be using the jQuery javascript library, which is free and can be downloaded here: jQuery.com. Then grab one of the javascript files linked below and either paste its contents into your javascript file or link to it as a standalone.

Syntax and options

Unlike a jQuery plugin, pxToEm is a string/number method and is not meant to be applied to a jQuery object. Instead, you will apply it as a method on a variable that references either a number or numeric string. pxToEm has defaults that can be overridden via the options argument. These settings should be passed in as an object as shown below:

myValue.pxToEm({
   scope: 'h3',
   reverse: true
});

Available Options

• Scope: jQuery object or selector string, defaults to 'body'
• Reverse: Boolean, defaults to true

Download it!

• pxToEm.js

We're always thinking about better ways to present information, streamline workflows, and develop applications. Welcome to our lab.

Particle Tree recently posted an article describing a technique for styling the HTML button element. For those not familiar, form buttons are notoriously difficult to customize because they render differently across browsers and platforms. The typical solutions are to use the default button style that the browser provides, or use an image input, which may look fine but requires that you create a unique background image with text "baked in" for each type of button (i.e., "Enter", "Send message") and its rollover state.

While Particle Tree's technique works well, we needed a more flexible solution that accommodated a wider range of styles. We're often designing and developing complex applications with buttons that are styled with background images, background colors, icons, and sometimes a combination of all three. Ideally, our buttons would:

• use the sliding doors method introduced on A List Apart,
• allow us to use HTML text for the button labels so that we could reuse the same button style many times without having to cut unique images for each, and
• do not require JavaScript for form submission or rollovers.

To meet these conditions we developed the following technique — a cross-browser method for styling button elements with sliding doors.

Examples

Each button shown uses the same markup and style — only the label text is different.

Images & Markup

We cut two images for each state, default and hover (4 images total). The first pair form the left side of the button, the second form the right side.

(We'd like to convert these states into two sprites, where the default and hover state for each are burned into a single background image that is repositioned on hover. Initial testing for that idea yielded inconsistent results — if you have any success with this, please drop us a line.)

Button markup consists of a button tag around a span tag, and label text is written into the span. Both tags are necesary to support the two sliding door background images: the button tag's background image is shorter with right corners, and the span's background image is the larger with left corners. We found in our tests that it's best to cut the right image at least as wide as it is tall to avoid gaps between the doors.

And last but not least, the "submitBtn" class is assigned to the button tag (styles for the span tag are assigned with descendant selectors):

<button value="submit" class="submitBtn"><span>Submit</span></button>

CSS

button { 
  border:0; 
  cursor:pointer; 
  font-weight:bold; 
  padding:0 20px 0 0; 
  text-align:center; 
}
button span { 
  position:relative; 
  display:block; 
  white-space:nowrap; 
  padding:0 0 0 20px; 
}

/*blue buttons*/
button.submitBtn { 
  background:url(images/btn_blue_right.gif) right no-repeat; 
  font-size:1.3em; 
}
button.submitBtn span { 
  height:50px; 
  line-height:50px;
  background:url(images/btn_blue_left.gif) left no-repeat;
  color:#fff; 
}
button.submitBtn:hover {
	background:url(images/btn_blue_right_hover.gif) right no-repeat; 
}
button.submitBtn:hover span {
	background:url(images/btn_blue_left_hover.gif) left no-repeat; 
}

CSS for IE 6 and 7

We recommend referencing these in a dedicated IE stylesheet using conditional comments.

button { 
  width:auto; 
  overflow:visible; 
}
button span { 
  margin-top:1px; 
}

Supported Browsers

So far we've tested: IE 6, IE7, Firefox (Mac + PC), Safari, Opera, Camino

Caveats

IE 6 does not support the ":hover" pseudoclass on elements other than anchor tags. To get the hover to work in IE6, you'll need to duplicate the :hover styles and assign them a class name, and then script a function to toggle that class on/off.

Credits

This technique was motivated by the Particle Tree article Rediscovering The Button Element. The "width: auto;" workaround for IE is a technique we discovered at Jehia.cz.