Performance should be a concern of yours if you do front end work. Speed is of the essence, and it’s (rightfully) becoming a focus. A simple thing to do to boost page speed and performance is to reduce HTTP requests. There’s science behind it, but the generalist view is: the fewer HTTP requests the better. A stellar way to reduce requests is to use image sprites in your style layer.

A sprite is a conglomeration of all the (non-repeating) image assets of your design into a single image to be referenced and obscured and in doing so having a single HTTP request to retrieve any number of pseudo-’images’. The trouble with spriting is that it takes planning and can be tedious. Luckily, spriting can be automated to a certain extent, and tools like Spritemapper make that a bit easier.

Spritemapper seems very well put together, and I can not wait to find an automated solution that will help me not have to keep track of my sprites manually.

Years ago, when using CSS for layout was still rather new, one of the common arguments for using CSS instead of tables for layout was that it enables you to change the layout order without editing your markup.

A typical example is a page with a vertical sub-navigation to the left, a centered content area, and a sidebar to the right. If you use tables for layout you will need to change the HTML to move the columns around, say if you wanted the navigation on the right and the sidebar on the left. With CSS you can change the visual order of the columns without touching the HTML.

But, there is a but.
Read full post
Posted in Accessibility, CSS.

David made a comment on Twitter about some markup he was working on:

Feels dirty setting id’s on main HTML5 page header and footer, but overriding inheritance they cause seems needlessly laborious.

I know the feeling. I don’t like using IDs at all, unless I want part of a document to be addressable through the fragment identifier portion of the URL. While I think it’s desirable to use the id attribute to create in-document permalinks, I don’t think it’s desirable to use the id attribute just as a styling hook. Its high specificity may seem a blessing but, in my experience, it quickly leads to duplicated CSS. IDs are often used as a substitute for understanding the cascade.

Nicole feels the same way about ID selectors, and she knows a thing or two about writing efficient CSS.

Back to David’s dilemma. Let’s say you’re targetting header and footer elements used throughout your document in sections, articles, etc. All you need to use is an element selector:

header {
// regular header styles
}

But what about the document-level header and footer? They’re probably styled very differently from the headings of sections and articles.

You could try using a child selector:

body > header

But there’s no guarantee that the document header will be a direct child of the body element. Hence the use of the id attribute—header id="ID":

header#ID {
// page header styles
}

There is another way. In HTML5 you can, for the first time, use ARIA roles and still have a valid document. ARIA landmark roles add an extra layer of semantics onto your document, distinguishing them as navigational landmarks for assistive technology.

Some of these landmark roles—like IDs—are to be used just once per document:

Within any document or application, the author SHOULD mark no more than one element with

banner
main
contentinfo

That’s useful for two reasons. One, the existence of role="main" means it is not necessary for HTML5 to provide an element whose only semantic is to say “this is the main content of the document.”

A lot of people have asked for such an element in HTML5. “We’ve got header, footer and aside,” they say. “Why not maincontent too?”

But whereas header, footer and aside can and should be used multiple times per document, a maincontent element would, by necessity, only be used once per document. There are very few elements in HTML that are like that: the html element itself, the title element, head and body (contrary to popular opinion—likely spread by SEO witch-doctors—the h1 element can be used more than once per document).

Now the desired functionality of semantically expressing “this is the main content of the document” can be achieved, not with an element, but with an attribute value: role="main".

The rough skeleton of your document might look like this:

<header role="banner"></header>
<div role="main"></div>
<footer role="contentinfo"></footer>

Now you can see the second advantage of these one-off role values. You can use an attribute selector in your CSS to target those specific elements:

header[role="banner"] {
// page header styles
}

Voila! You can over-ride the default styling of headers and footers without resorting to the heavy-handed specificity of the ID selector.

And, of course, you get the accessibility benefits too. ARIA roles are supported in JAWS, NVDA and Voiceover

Tagged with
html5
css
aria
accessibility
standards
semantics

A few months ago I posted a tip on how to Minimise file size with the YUI Compressor TextMate Bundle. The idea is to get minifying of CSS and JavaScript files into your workflow even if your server or CMS isn’t setup to do it automatically for you.

It works well, but I recently ran into a YUI Compressor bug that had me scratching my head for quite some time. Some of my media queries simply weren’t working. I checked the Media Queries specification, read various tutorials and examples from around the Web, and despite my syntax being correct some things just wouldn’t work.

Incredibly frustrating, but I found out what the problem was and how to fix it.
Read full post
Posted in CSS, Coding.

One of the most visited pages on this site is the Simple 2 column CSS layout tutorial, where I explain how to create a basic 2-column CSS layout with floats. Many readers have asked for a similar tutorial on how to create a three-column layout, and I’ve been meaning to write one for a few years.

Well, I finally took the time to do it. Three-column CSS layouts have been explained many times, in many different ways, by many people already, so there is nothing (or at least not much) new here. It’s also something that I’m pretty sure that most regular readers can do in their sleep. Regardless, there are many people looking for this info, and it’s convenient to be able to refer to an explanation of how I normally create 3-column CSS layouts with a method that I find robust.
Read full post
Posted in CSS.

I love Christmas. I love walking around the streets of London, looking at the beautifully decorated windows, seeing the shiny lights that hang above Oxford Street and listening to Christmas songs.

I’m not going to lie though. Not only do I like buying presents, I love receiving them too. I remember making long lists that I would send to Father Christmas with all of the Lego sets I wanted to get. I knew I could only get one a year, but I would spend days writing the perfect list.

The years have gone by, but I still enjoy making wish lists. And I’ll tell you a little secret: my mum still asks me to send her my Christmas list every year.

This time I’ve made my CSS wish list. As before, I’d be happy with just one present.

Before I begin…

… this list includes:


things that don’t exist in the CSS specification (if they do, please let me know in the comments – I may have missed them);
others that are in the spec, but it’s incomplete or lacks use cases and examples (which usually means that properties haven’t been implemented by even the most recent browsers).


Like with any other wish list, the further down I go, the more unrealistic my expectations – but that doesn’t mean I can’t wish. Some of the things we wouldn’t have thought possible a few years ago have been implemented and our wishes fulfilled (think multiple backgrounds, gradients and transformations, for example).

The list

Cross-browser implementation of font-size-adjust

When one of the fall-back fonts from your font stack is used, rather than the preferred (first) one, you can retain the aspect ratio by using this very useful property. It is incredibly helpful when the fall-back fonts are smaller or larger than the initial one, which can make layouts look less polished.

What font-size-adjust does is divide the original font-size of the fall-back fonts by the font-size-adjust value. This preserves the x-height of the preferred font in the fall-back fonts. Here’s a simple example:

p {
font-family: Calibri, "Lucida Sans", Verdana, sans-serif;
font-size-adjust: 0.47;
}

In this case, if the user doesn’t have Calibri installed, both Lucida Sans and Verdana will keep Calibri’s aspect ratio, based on the font’s x-height. This property is a personal favourite and one I keep pointing to.

Firefox supported this property from version three. So far, it’s the only browser that does. Fontdeck provides the font-size-adjust value along with its fonts, and has a handy tool for calculating it.

More control over overflowing text

The text-overflow property lets you control text that overflows its container. The most common use for it is to show an ellipsis to indicate that there is more text than what is shown. To be able to use it, the container should have overflow set to something other than visible, and white-space: nowrap:

div {
white-space: nowrap;
width: 100%;
overflow: hidden;
text-overflow: ellipsis;
}

This, however, only works for blocks of text on a single line. In the wish list of many CSS authors (and in mine) is a way of defining text-overflow: ellipsis on a block of multiple text lines. Opera has taken the first step and added support for the -o-ellipsis-lastline property, which can be used instead of ellipsis. This property is not part of the CSS3 spec, but we could certainly make good use of it if it were…

WebKit has -webkit-line-clamp to specify how many lines to show before cutting with an ellipsis, but support is patchy at best and there is no control over where the ellipsis shows in the text. Many people have spent time wrangling JavaScript to do this for us, but the methods used are very processor intensive, and introduce a JavaScript dependency.

Indentation and hanging punctuation properties

You might notice a trend here: almost half of the items in this list relate to typography. The lack of fine-grained control over typographical detail is a general concern among designers and CSS authors. Indentation and hanging punctuation fall into this category.

The CSS3 specification introduces two new possible values for the text-indent property: each-line; and hanging. each-line would indent the first line of the block container and each line after a forced line break; hanging would invert which lines are affected by the indentation.

The proposed hanging-punctuation property would allow us to specify whether opening and closing brackets and quotes should hang outside the edge of the first and last lines. The specification is still incomplete, though, and asks for more examples and use cases.

Text alignment and hyphenation properties

Following the typographic trend of this list, I’d like to add better control over text alignment and hyphenation properties. The CSS3 module on Generated Content for Paged Media already specifies five new hyphenation-related properties (namely: hyphenate-dictionary; hyphenate-before and hyphenate-after; hyphenate-lines; and hyphenate-character), but it is still being developed and lacks examples.

In the text alignment realm, the new text-align-last property allows you to define how the last line of a block (or a line just before a forced break) is aligned, if your text is set to justify. Its value can be: start; end; left; right; center; and justify. The text-justify property should also allow you to have more control over text set to text-align: justify but, for now, only Internet Explorer supports this.

calc()

This is probably my favourite item in the list: the calc() function. This function is part of the CSS3 Values and Units module, but it has only been implemented by Firefox (4.0). To take advantage of it now you need to use the Mozilla vendor code, -moz-calc().

Imagine you have a fluid two-column layout where the sidebar column has a fixed width of 240 pixels, and the main content area fills the rest of the width available. This is how you could create that using -moz-calc():

#main {
width: -moz-calc(100% - 240px);
}

Can you imagine how many hacks and headaches we could avoid were this function available in more browsers? Transitions and animations are really nice and lovely but, for me, it’s the ability to do the things that calc() allows you to that deserves the spotlight and to be pushed for implementation.

Selector grouping with -moz-any()

The -moz-any() selector grouping has been introduced by Mozilla but it’s not part of any CSS specification (yet?); it’s currently only available on Firefox 4.

This would be especially useful with the way HTML5 outlines documents, where we can have any number of variations of several levels of headings within numerous types of containers (think sections within articles within sections…).

Here is a quick example (copied from the Mozilla blog post about the article) of how -moz-any() works. Instead of writing:

section section h1, section article h1, section aside h1,
section nav h1, article section h1, article article h1,
article aside h1, article nav h1, aside section h1,
aside article h1, aside aside h1, aside nav h1, nav section h1,
nav article h1, nav aside h1, nav nav h1, {
font-size: 24px;
}

You could simply write:

-moz-any(section, article, aside, nav)
-moz-any(section, article, aside, nav) h1 {
font-size: 24px;
}

Nice, huh?

More control over styling form elements

Some are of the opinion that form elements shouldn’t be styled at all, since a user might not recognise them as such if they don’t match the operating system’s controls. I partially agree: I’d rather put the choice in the hands of designers and expect them to be capable of deciding whether their particular design hampers or improves usability.

I would say the same idea applies to font-face: while some fear designers might go crazy and litter their web pages with dozens of different fonts, most welcome the freedom to use something other than Arial or Verdana.

There will always be someone who will take this freedom too far, but it would be useful if we could, for example, style the default Opera date picker:

<input type="date" />



or Safari’s slider control (think star movie ratings, for example):

<input type="range" min="0" max="5" step="1" value="3" />



Parent selector

I don’t think there is one CSS author out there who has never come across a case where he or she wished there was a parent selector. There have been many suggestions as to how this could work, but a variation of the child selector is usually the most popular:

article < h1 {
…
}

One can dream…

Flexible box layout

The Flexible Box Layout Module sounds a bit like magic: it introduces a new box model to CSS, allowing you to distribute and order boxes inside other boxes, and determine how the available space is shared.

Two of my favourite features of this new box model are:


the ability to redistribute boxes in a different order from the markup
the ability to create flexible layouts, where boxes shrink (or expand) to fill the available space


Let’s take a quick look at the second case. Imagine you have a three-column layout, where the first column takes up twice as much horizontal space as the other two:

<body>
<section id="main">
</section>
<section id="links">
</section>
<aside>
</aside>
</body>

With the flexible box model, you could specify it like this:

body {
display: box;
box-orient: horizontal;
}
#main {
box-flex: 2;
}
#links {
box-flex: 1;
}
aside {
box-flex: 1;
}

If you decide to add a fourth column to this layout, there is no need to recalculate units or percentages, it’s as easy as that.

Browser support for this property is still in its early stages (Firefox and WebKit need their vendor prefixes), but we should start to see it being gradually introduced as more attention is drawn to it (I’m looking at you…)[…]

TrueType font embedding has come to iPhone and iPad, Hallelujah, brothers and sisters. That is to say, Mobile Safari now supports CSS embedding of lower-bandwidth, higher-quality, more ubiquitous TrueType fonts. This is huge. Test on your device(s), then read and rejoice:

The Typekit Blog: iOS 4.2 improves support for web fonts
iOS 4.2 is also the first version of Mobile Safari to support native web fonts (in TrueType format) instead of SVG. This is also exciting news, as TrueType fonts are superior to SVG fonts in two very important ways: the files sizes are dramatically smaller (an especially important factor on mobile devices), and the rendering quality is much higher.

Ryan N.: Confirmed: TrueType Font Support on Mobile Safari on iOS 4.2
Thanks to Matt Wiebe for mentioning the rumour that Mobile Safari on iOS 4.2 supports TrueType fonts and providing a handy link to test.

TrueType
TrueType is an outline font standard originally developed by Apple Computer in the late 1980s as a competitor to Adobe’s Type 1 fonts used in PostScript. TrueType has become the most common format for fonts on both the Mac OS and Microsoft Windows operating systems.

The primary strength of TrueType was originally that it offered font developers a high degree of control over precisely how their fonts are displayed, right down to particular pixels, at various font sizes. With widely varying rendering technologies in use today, pixel-level control is no longer certain in a TrueType font.

More about webfonts
If you’re coming late to the party, the following bits of required reading and listening will get you up to speed on the joys (and occasional frustrations) of “real type” on the web:

Bulletproof @font-face syntax, Paul Irish, 4 September, 2009

Web Fonts at the Crossing, Richard Fink, 8 June 2010, A List Apart
Big Web Show Episode 1, Dan Benjamin and I discuss webtype with Ethan Dunham of Fontspring and Font Squirrel and Jeffrey Veen of Typekit
Big Web Show Episode 18, Dan Benjamin and I discuss webtype, screen resolution, and more with Roger Black

Thanks
My thanks to David Berlow of Font Bureau for waking me from my Thanksgiving stupor and alerting me to this exciting slash overdue development.

Now we have something else to be thankful for. Nathan Smith of Sonspring has created a library that gives designers and developers “some measure of control over form elements, without changing them so drastically as to appear foreign in a user’s operating system.” Smith calls his new library Formalize CSS:

I’ve attempted to bridge the gap between various browsers and OS’s, taking the best ideas from each, and implementing what is possible across the board. For the most part, this means most textual form elements have a slight inset, and all buttons look consistent, including the button tag.

For more, including demos, options, screenshots, thanks, and the library itself, read Smith’s write-up at SonSpring | Formalize CSS. Hat tip and happy Thanksgiving to my good friend Aaron Gustafson for sharing this gem.

Do you feel that your front-end code isn’t quite up to enterprise standards? Want some good tips on how to take your HTML, CSS, and JavaScript to the next level? Go to Enterprise CSS, Enterprise HTML, and Enterprise JavaScript for loads of useful tips and best practices.

Note: To eliminate any risk of misunderstanding I think it’s best to add that this is a joke – most of the tips are actually anti-best practice. The sad thing is that the front-end code of many “enterprise-level” sites and content management systems really do look like many of these “tips” have been taken seriously.

Some of my favourite tips are these:

Store your application’s state as a hash in a single hidden input on the page, because page-weight is not my problem
Creating forms without the need for cumbersome label elements
Bullet-proof rounded corners that work all the way down to Netscape 4.79
Liberally using documentation to describe sections of content
Every single tag gets an id or class, because how else would you style it?
Read full post
Posted in (X)HTML, CSS, JavaScript.

Another week, another responsive web site.

Two weeks ago, it was St. Paul’s School. Last week, it was Salter Cane. This week, I’ve been working on next year’s UX London site, implementing a nice little design refresh courtesy of Paul.

More pages will be added soon but for now, it’s essentially like a poster for the conference.

Back when I was working on the first UX London site two years ago, I was building it together with Natalie, and I mean literally together: we were pair-programming. Well, I guess programming isn’t quite right for HTML and CSS, but we were pair-writing. It was an excellent experience.

Anyway, Natalie being Natalie, the UX London site was built with rock-solid markup with a flexible layout. All the pieces were in place for a responsive web design so once I was done with the current refresh, I spent a few minutes writing some media queries.

You can see the results for yourself.

Tagged with
css
design
adaptive
responsive
css3
mediaqueries
uxlondon

Everybody wants to use CSS 3 now that even Internet Explorer will support parts of it once IE 9 is out. But since parts of CSS 3 are still subject to change, most browsers use a vendor prefix for many CSS 3 properties to signal that their implemenation is “experimental” and may change in a later version of the browser.

This means that for a property like border-radius to work cross-browser you need to specify it several times with different vendor prefixes, like this:

.box {
-moz-border-radius:10px;
-webkit-border-radius:10px;
border-radius:10px;
}
Read full post
Posted in Browsers, CSS.

“We ought to praise vendors for using prefixes, and indeed encourage them to continue. Beyond that, I hold that prefixes should become a central part of the CSS standardization process. I do this not for the love of repetition, but out of a desire to see CSS evolve consistently. I believe that prefixes can actually accelerate the advancement and refinement of CSS.” - Eric Meyer on Prefix or Posthack

Learn to love vendor prefixes and create full-screen backgrounds that resize to fit the viewport in Issue No. 309 of A List Apart for people who make websites:

Prefix or Posthack
by ERIC MEYER

Vendor prefixes: Threat or menace? As browser support (including in IE9) encourages more of us to dive into CSS3, vendor prefixes such as -moz-border-radius and -webkit-animation may challenge our consciences, along with our patience. But while nobody particularly enjoys writing the same thing four or five times in a row, prefixes may actually accelerate the advancement and refinement of CSS. King of CSS Eric Meyer explains why.

Supersize that Background, Please!
by BOBBY VAN DER SLUIS

Background images that fill the screen thrill marketers but waste bandwidth in devices with small viewports, and suffer from cropping and alignment problems in high-res and widescreen monitors. Instead of using a single fixed background size, a better solution would be to scale the image to make it fit different window sizes. And with CSS3 backgrounds and CSS3 media queries, we can do just that. Bobby van der Sluis shows how.

Illustration by Kevin Cornell for A List Apart Magazine.

The long-planned inevitable has now been announced. With open-source-licensed web fonts, web font hosting, and add-a-line-to-your-header ease of configuration, Google has joined Typekit, Font Squirrel, Ascender, Font Bureau and others in forever changing the meaning of the phrase, “typography on the web.”

The Google Font Directory lets you browse all the fonts available via the Google Font API. All fonts in the directory are available for use on your website under an open source license and served by Google servers.

Oh, and Typekit? They’re in on it, and they couldn’t be more pleased.

When you have a key-value list what HTML tags should you use? I’ve been thinking a lot about this and I’ll say it flat out: the answer is tables. Here are some of the common tags used to contain key-value pair lists and why using tables is better.

Tags That Don’t Work Very Well

Dictionary Lists

You could use a dictionary list like so:

<dl>
<dt>Color</dt>
<dd>Red</dd>
<dt>Shape</dt>
<dd>Square</dd>
</dl>

Semantically, this kind of works out. It has key and value tags, dt and dd. But the problem comes with formatting. What if you want to put a border around a key value pair? Well, you can’t. One solution is to wrap each key-value pair in its own dl tag, but that seems like a lot of work and then you lose out on the whole list wrapper, so you have to wrap the whole thing in a div or something depending on your formatting requirements.

This is not to say that dictionary lists are bad, they are perfect for things that closely resemble actual dictionary lists, but they are not a very good general key-value pair container because of limited formatting options.

Unordered Lists

Unordered lists are very flexible and can wisely be used for all kinds of lists. The other day I saw them used as a container for key-value pairs like this:

<ul>
<li>Color <span class="Value">Red</span></li>
<li>Shape <span class="Value">Square</span></li>
</ul>

In many cases this will work fine. It has the benefit over a dictionary list that both the key and value are contained within one element. It has the downside that the Value span has to be formatted to undo any formatting you’ve given the li (the key). This could be altered by adding a Key span, but at that point you may as well just use a bunch of divs. This doesn’t give you very good CSS free presentation and completely loses the semantics of the data. The point of HTML is that if there’s no style things still end up looking fairly decent and that at the very least, the HTML can accurately represent the data relationships.

The Winner

Tables

We’ve been so conditioned against tables and rightly so. People have abused tables in the past to format their pages to the point where you can’t tell what’s going on. But remember the rule, “Tables should be used for tabular data.” A list of key-value pairs is an excellent example of tabular data, but I think people don’t think to use tables at first because the tabular data in this case only has two columns. People start to think of tables for things with three or more columns. Here’s the markup.

<table>
<tr>
<th>Color</th>
<td>Red</td>
</tr>
<tr>
<th>Shape</th>
<td>Square</td>
</tr>
</table>

This fixes all the problems. Each key value pair is enclosed in a tr element. The key is enclosed in a th and the value is enclosed in a td. The default formatting is going to be perfect.

Furthermore, tables offer so much more extensibility. If you need a header row, break out the thead and tbody elements. If you need a summary row at the bottom, add another tbody element. It’s ultimately extendable with no classes.

Of course, that doesn’t mean it’s the solution for everything. If what you have is a dictionary list, then of course the dictionary list tags are going to work better. But for general key-value pairs, and the ways we generally think of formatting key-value pairs this is way better.

It might be time to get back in touch with tables if you’ve stopped thinking about them. Once you drop the idea of tables being used for page formatting and adopt the idea of using them just for small blocks of data you can really start to see how great they are.

The CSS for tables is a little more complex, so take some time to start understanding that. I’ll give you a hint, though. Do yourself a favor and use the border-collapse property. It takes a lot of the fuss and mess out of formatting tables:

table
{
border-collapse: collapse;
}

Difficult Situations

I just thought I should mention here that I have run into one situation that isn’t covered very well by any existing HTML elements and in its nature is just difficult. This is the case where you have individual key-value pairs that you want “arranged” in an some custom manner. For instance you want the key on top with a border on the bottom and the value beneath that. Then you want those elements to be lined up horizontally:

Color Shape
-------- --------
Red Square

Using more radical CSS dictionary lists can be made to perform this way although it’s probably better handled by turning the table suggestion above on its side and using a table with two rows, a header row and a data row depending on how you want it formatted.

<table>
<thead>
<tr>
<th>Color</th>
<th>Shape</th>
</tr>
</thead>
<tbody>
<tr>
<td>Red</td>
<td>Square</td>
</tr>
</tbody>
</table>

That’s more HTML than absolutely necessary, the thead and tbody can be left out, but it still feel like a lot of HTML for something semantically simple. But at this point it’s going to take either a lot of HTML (tables) or a lot of CSS (dictionary lists) to make this particular scenario work. If you want it to work without CSS, you really have no choice but tables.

The issue with this concept is that it doesn’t allow for very long values or very many key-value pairs horizontally and the whole scenario is only appropriate when you know in advance the range and quantity of values to expect.

Our visually and behaviorally rich sites are about to lose precious Google juice, WebSiteOptimization.com reports in a new piece titled Page Speed Factored into Google Search Rankings:

Google’s addition of a page speed signal to its search rankings algorithm officially links performance with search engine marketing. The loading speed of a web page affects user psychology in a number of ways, and now it can effect its rankings as well.

This back-to-basics message catches us at a funny time in web design history.

“Make more of less” has long been the norm
Most of us who’ve designed sites for quite a while, and who consider ourselves user- and standards-focused, have traditionally designed sites that loaded faster the competition. We did it by using caching technologies (CSS instead of table layouts, linked instead of inline JavaScript, and so on). For many, many years, we also did it by keeping images to a minimum, using system fonts instead of pictures of type, CSS colors instead of faux backgrounds, and so on.

As the web audience grew, heavily trafficked sites became even more restrictive in their decorative flourishes, whether they cared about web standards or not. Thus Google, while happily using bad CSS and markup, exerted monk-like discipline over its designers. Not only were images out, even such details as rounded corners were out, because the tiny images needed to facilitate rounded corners prior to CSS3 added a tenth of a kilobyte to page weight, and a tenth of a kilobyte multiplied by a billion users was too much.

Of late, we have grown fat
Yet in the past few years, as wideband became the norm, every mainstream site and its brother started acting as if bandwidth didn’t matter. Why use 1K of web form when you could use 100K of inline pseudo-Ajax? Why load a new page when you could load a lightbox instead?

Instead of medium-quality JPEGs with their unimportant details painstakingly blurred to shave KB, we started sticking high-quality PNG images on our sites.

As these bandwidth-luxuriant (and not always beautiful, needed, or useful) practices became commonplace on mainstream sites, many advanced, standards-focused web designers were experimenting with web fonts, CSS3 multiple backgrounds, full-page background images, and other devices to create semantic, structurally lean sites that were as rich (and heavy) as Flash sites.

So now we face a dilemma. As we continue to seduce viewers via large, multiple background images, image replacement, web fonts or sIFR, and so on, we may find our beautiful sites losing page rank.

Read the report and watch this space.

Smashing Magazine rounds up a few tricks for “CSS Layouts, Visual Effects and Forms”. Not everything in here looks useful to me, but I did notice a few gems while quickly browsing through. Bookmarked for later investigation. link

Anyone who has been using CSS for any length of time has probably been frustrated by the lack of selector support in Internet Explorer 6. There are quite a lot of cases where a CSS 2.1 selector will let you target elements in all other relevant browsers, but where you, if you want it to work in IE 6, have to add a class or id attribute to the HTML.

Well, the market share of IE 6 is now finally at a level where we as developers can say that a site “supporting” IE 6 does not necessarily mean “looking pixel perfect”. Fortunately more and more clients understand this as well. IE 7 has been out for well over three years and IE 9 is on the horizon, so I think it’s time to revive those CSS selectors that you never got to use just because IE 6 doesn’t understand them.
Read full post
Posted in CSS.

Dan Benjamin and yours truly discuss the secret history of blogging, transitioning from freelance to agency, the story behind the web standards movement, the launch of A Book Apart and its first title, HTML5 For Web Designers by Jeremy Keith, the trajectory of content management systems, managing the growth of a design business, and more in the inaugural episode of the Pipeline.

When Tim and I were discussing the redesign of this site last year, one of the clear goals was to have a graphical style without making the pages heavy with a lot of images. When we launched, a lot of people were surprised that the design wasn’t built with PNGs. Instead we’d used RGBA colour values, which is part of the CSS3 specification.

What is RGBA Colour?

We’re all familiar with specifying colours in CSS using by defining the mix of red, green and blue light required to achieve our tone. This is fine and dandy, but whatever values we specify have one thing in common — the colours are all solid, flat, and well, a bit boring.

Flat RGB colours

CSS3 introduces a couple of new ways to specify colours, and one of those is RGBA. The A stands for Alpha, which refers to the level of opacity of the colour, or to put it another way, the amount of transparency. This means that we can set not only the red, green and blue values, but also control how much of what’s behind the colour shows through. Like with layers in Photoshop.

Don’t We Have Opacity Already?

The ability to set the opacity on a colour differs subtly from setting the opacity on an element using the CSS opacity property. Let’s look at an example.

Here we have an H1 with foreground and background colours set against a page with a patterned background.

Heading with no transparency applied


h1 {
color: rgb(0, 0, 0);
background-color: rgb(255, 255, 255);
}

By setting the CSS opacity property, we can adjust the transparency of the entire element and its contents:

Heading with 50% opacity on the element


h1 {
color: rgb(0, 0, 0);
background-color: rgb(255, 255, 255);
opacity: 0.5;
}

RGBA colour gives us something different – the ability to control the opacity of the individual colours rather than the entire element. So we can set the opacity on just the background:

50% opacity on just the background colour


h1 {
color: rgb(0, 0, 0);
background-color: rgba(255, 255, 255, 0.5);
}

Or leave the background solid and change the opacity on just the text:

50% opacity on just the foreground colour


h1 {
color: rgba(0, 0, 0, 0.5);
background-color: rgb(255, 255, 255);
}

The How-To

You’ll notice that above I’ve been using the rgb() syntax for specifying colours. This is a bit less common than the usual hex codes (like #FFF) but it makes sense when starting to use RGBA. As there’s no way to specify opacity with hex codes, we use rgba() like so:


color: rgba(255, 255, 255, 0.5);

Just like rgb() the first three values are red, green and blue. You can specify these 0-255 or 0%-100%. The fourth value is the opacity level from 0 (completely transparent) to 1 (completely opaque).

You can use this anywhere you’d normally set a colour in CSS — so it’s good for foregrounds and background, borders, outlines and so on. All the transparency effects on this site’s current design are achieved this way.

Supporting All Browsers

Like a lot of the features we’ll be looking at in this year’s 24 ways, RGBA colour is supported by a lot of the newest browsers, but not the rest. Firefox, Safari, Chrome and Opera browsers all support RGBA, but Internet Explorer does not.

Fortunately, due to the robust design of CSS as a language, we can specify RGBA colours for browsers that support it and an alternative for browsers that do not.

Falling back to solid colour

The simplest technique is to allow the browser to fall back to using a solid colour when opacity isn’t available. The CSS parsing rules specify that any unrecognised value should be ignored. We can make use of this because a browser without RGBA support will treat a colour value specified with rgba() as unrecognised and discard it.

So if we specify the colour first using rgb() for all browsers, we can then overwrite it with an rgba() colour for browsers that understand RGBA.


h1 {
color: rgb(127, 127, 127);
color: rgba(0, 0, 0, 0.5);
}

Falling back to a PNG

In cases where you’re using transparency on a background-color (although not on borders or text) it’s possible to fall back to using a PNG with alpha channel to get the same effect. This is less flexible than using CSS as you’ll need to create a new PNG for each level of transparency required, but it can be a useful solution.

Using the same principal as before, we can specify the background in a style that all browsers will understand, and then overwrite it in a way that browsers without RGBA support will ignore.


h1 {
background: transparent url(black50.png);
background: rgba(0, 0, 0, 0.5) none;
}

It’s important to note that this works because we’re using the background shorthand property, enabling us to set both the background colour and background image in a single declaration. It’s this that enables us to rely on the browser ignoring the second declaration when it encounters the unknown rgba() value.

Next Steps

The really great thing about RGBA colour is that it gives us the ability to create far more graphically rich designs without the need to use images. Not only does that make for faster and lighter pages, but sites which are easier and quicker to build and maintain. CSS values can also be changed in response to user interaction or even manipulated with JavaScript in a way that’s just not so easy using images.

Opacity can be changed on :hover or manipulated with JavaScript


div {
color: rgba(255, 255, 255, 0.8);
background-color: rgba(142, 213, 87, 0.3);
}
 
div:hover {
color: rgba(255, 255, 255, 1);
background-color: rgba(142, 213, 87, 0.6);
}

Clever use of transparency in border colours can help ease the transition between overlay items and the page behind.

Borders can receive the RGBA treatment, too


div {
color: rgb(0, 0, 0);
background-color: rgb(255, 255, 255);
border: 10px solid rgba(255, 255, 255, 0.3);
}

In Conclusion

That’s a brief insight into RGBA colour, what it’s good for and how it can be used whilst providing support for older browsers. With the current lack of support in Internet Explorer, it’s probably not a technique that commercial designs will want to heavily rely on right away – simply because of the overhead of needing to think about fallback all the time.

It is, however, a useful tool to have for those smaller, less critical touches that can really help to finesse a design. As browser support becomes more mainstream, you’ll already be familiar and practised with RGBA and ready to go.

jQSlickWrap. Clever jQuery plugin which allows text to wrap around irregularly shaped images, by processing the image with canvas and rewriting it as a sequence of floated horizontal bars of different widths. It’s a a modern variant of the the ragged float trick first introduced by Eric Meyer.