The problem

In a fixed width layout it is simple to specify both the width and the height of an element:

.rect {
    width: 800px;
    height: 400px;
}

When creating a responsive layout things get trickier, since (to the best of my knowledge) it isn’t possible to specify a percentage based height that is relative to an element’s width. For example the following CSS rule won’t have the desired result, since the height value will be ignored:

.rect {
    width: 100%;
    height: 50%;
}

A solution

However, when we specify a padding-bottom value for the same element, the padding measurement is calculated relative to the element’s width:

.rect {
    width: 100%;
    height: 0;
    padding-bottom: 50%;
}

View a demo

You will notice that I have set the element’s height property to 0, to ensure that the height of any child elements will not be added to the padding value when the visible height is calculated.

A note about child elements

If you also want to specify percentage based heights for a child element, you will need to assign an absolute or relative position value to both the parent and the child:

.rect {
    position: relative;
    width: 100%;
    height: 0;
    padding-bottom: 50%;
    }
    .rect p {
        position: absolute;
        margin: 0;
        height: 100%;
        }

View a demo

Parallax what?

Even if you’re not familiar with the term “parallax scrolling” you will certainly be familiar with the technique. Parallax scrolling is a 2d animation process that creates an illusion of depth by animating foreground layers faster than background layers. When you observe the landscape from a moving car, objects closer to the car appear to pass you faster than scenery further away. Parallax scrolling uses the same principle to trick the viewer into thinking they are observing a 3d scene.

Demo and Download

My demo web page shows one approach to building a vertical parallax scrolling interface:

View demo
Download source

You can scroll in the usual fashion, use the navigation menu at the right-hand side of the page, or the next/prev buttons that appear underneath each article. As you scroll, the page’s four content layers are animated independently of one another to create an illusion of depth.

The scrolling looks smoothest in Safari (at least that’s the case on my PC), but my demo should work in any modern browser.

Disclaimer 1: Because this is just an experiment I’ve not spent any time optimising the demo to work on mobile devices. I wanted to keep the demo lean ‘n’ mean, and not clutter it by sniffing mobile browsers and forking my code. On a production site you’d want to ensure that the site degrades gracefully on mobile devices, where scroll events and fixed positioning might work in unexpected ways.

Disclaimer 2: The navigation menu in my demo is inspired by the menu on the Nike Better World website. If you plan on implementing a similar menu on a production site, please be aware of its origin.

How it works

The articles and background layers are given a fixed positioned with CSS, and assigned a z-index so that the foreground layers appear above the background layers. The four layers are: small clouds, large clouds, balloon/landscape images, articles.

/* foreground (ballons/landscape) */
#parallax-bg3 {
    z-index: 3;
    position: fixed;
    left: 50%; /* align left edge with center of viewport */
    top: 0;
    width: 940px;
    margin-left: -470px; /* move left by half element's width */
}

Within each layer individual content elements are absolutely positioned. This was the most fiddly part of the process, since the elements need to positioned in such a way that they align in a pleasing manner when the user scrolls to any of the four articles. In this case it was really just a process of trial and error.

#bg3-1 {
    position: absolute;
    top: -111px;
    left: 355px;
}
#bg3-2 {
    position: absolute;
    top: 812px;
    left: 321px;
}
/* etc... */

A few lines of jQuery control the parallax effect, triggered by a scroll event. I was surprised how easy this was to achieve, it is literally just a handful of lines of code.

$(window).bind('scroll',function(e){
    parallaxScroll();
});
 
function parallaxScroll(){
    var scrolled = $(window).scrollTop();
    $('#parallax-bg1').css('top',(0-(scrolled*.25))+'px');
    $('#parallax-bg2').css('top',(0-(scrolled*.5))+'px');
    $('#parallax-bg3').css('top',(0-(scrolled*.75))+'px');
}

As you can see the CSS top property is used to move each layer as the user scrolls. The foreground layer is always aligned to the top of the document, while the movement of other layers is adjusted according to their depth. The lower a layer sits in the stack, the less distance it is moved.

The rest of the jQuery is concerned with controlling the navigation menus. When the user clicks a navigation button the page scrolls to the top of the associated article. In the event that the user has JavaScript disabled, regular HTML anchor links still allow the page to be navigated, but without any fancy pants animations.

Next steps

I’m sure there are plenty of other approaches to parallax scrolling, and hopefully my experiment provides a starting point for your own explorations of the technique.

Update

I have updated the demo so that each parallax layer is given a fixed, rather than absolute, position. This approach gives a smoother scrolling effect.

Conditional comments have provided a great stopgap measure while we wait for obsolete versions of IE to fall into disuse, but as the market share of IE6 and IE7 has dwindled I’ve found myself relying on them less and less. In fact, I can’t remember the last time I resorted to a separate stylesheet to make an old browser behave.

Last week Microsoft announced that support for conditional comments will be dropped from version 10 of Internet Explorer. Like other modern browsers IE10 will treat conditional comments just like regular HTML comments, and ignore them. This is a very encouraging sign, since it means that Microsoft are confidant that IE’s support for web standards has reached a level where a standards compliant website ought to “just work” across all modern web browsers, without having to make special allowances for legacy rendering engines.

Of course, conditional comments will continue to be recognised by older versions of IE, but with IE6 and IE7 ready to disappear off the radar the time is clearly right for conditional comments to be put out to pasture. Goodbye conditional comments.

Specificity in action

Before we tackle the topic of over-specificity, let’s brush up on the basics. Here is a simple CSS/HTML snippet in which we want all h1 headings to be blue, except for those which appear in a section element:

h1 { color: blue; }
section h1 { color: red; }

<h1>I am blue!</h1>
<section>
    <h1>Big deal, I am red!</h1>
</section>

When a browser renders the h1 that is nested within the section element, it resolves the conflict between the two CSS rules by giving priority to the more specific selector: section h1.

In this example it’s easy to guess that the nested h1 is going to be red, but specificity isn’t always so easy to grasp. Things get trickier when you start throwing IDs and classes into the mix, and in these cases it helps to understand how specificty is calculated.

Calculating specificity

When resolving a conflict between two rules, the cascade assigns the greatest weight to the rule with the most ID selectors. If the results are tied then the rule with the most class selectors wins out, and failing that the rule with the highest number of element selectors trumps any competing rules.

Many online resources state that specificity is calculated by assigning a numeric value to each selector, then adding them together: ID selectors are assigned a value of 100, class selectors a value of 10, and HTML elements a value of 1. This was how CSS1 worked, but CSS2 introduced the new calculation method which I outlined above. For most intents the two methods are identical, but results do differ when dealing with large numbers of selectors.

If you want the nitty gritty, the Sitepoint CSS reference explains Specificity calculation in great detail. If you find Sitepoint’s examples too difficult to digest then Andy Clarke’s humorous Specificity Wars might be more your cup of tea.

Here is another example, showing the impact that an ID selector has on specificity. I’ve added a couple more HTML elments into the mix (you’ll see why soon), but we’re still trying to make the first h1 blue, and the nested h1 red:

#content h1 { color: blue; }
section h1 { color: red; }

<div id="content" class="home">
    <article class="blog-post">
        <h1>I am blue!</h1>
        <section>
            <h1>Big deal, I am red! Or am I?</h1>
        </section>
    </article>
</div>

At first glance the second selector may appear to be more specific because it contains a reference to section, an element that is closer in proximity to the target heading. In fact the first rule will win out, and both h1‘s will be blue. This is because the first rule includes an ID selector, while the second rule contains only element selectors. Remember that an ID selector trumps any number of class or element selectors.

To get the second color declaration working we would need to add a #content ID selector to it. This makes the selector more specific, and the nested h1 will now be red as intended:

#content section h1 { color: red; }

Don’t over-specify

Complexity begets complexity, and the more specific a CSS selector is, the more difficult it becomes to overrule it. Imagine if our ‘blue’ selector had looked like this:

div#content.home article.blog-post h1 { color: blue; }

Talk about overkill. As well as an ID selector, the rule now also contains two class selectors and two additional element selectors. This forces us to make our ‘red’ rule even more specific to ensure its color declaration is respected:

div#content.home article.blog-post section h1 { color: red; }

This is clearly a much less efficient solution than the earlier example. Our ‘red’ rule now requires one ID selector, two class selectors, and four element selectors to achieve what before we were doing with just one ID and two element selectors.

As well as being difficult to read, verbose CSS selectors make it harder to target nested elements. Conflicts may be easy to diagnose using a DOM inspector such as Firebug, but isn’t it better to avoid having to hunt for problems in the first place?

The solution is to make your selectors only as specific as they need to be. Use as few selectors as possible to achieve the desired result, and avoid adding extra ID or class selectors into your rule unless they really needs to be there. By crafting your selectors to be as unspecific as possible you can keep your stylesheets simple and readable, and preserve your sanity.

This morning I visited a website that caused me to wonder if we’ve come so far after all. I was looking forward to experiencing the site’s typography, which I’d been informed was exemplary, and was surprised when my browser served up fallback system fonts rather than the embedded web fonts I was expecting. A warning message in the masthead informed me that if the fonts looked “kind of weird” I should switch to Chrome or Safari.

My guess is that the site’s designer had chosen a typeface that wasn’t properly optimised for on-screen display, and as a consequence the site’s typography didn’t fare well on certain browser and operating system combinations. Rather than adapt their design to suit a wider audience the designer decided to try and change their user’s behavior by instructing them to switch to a different web browser. As a web professional I was surprised to be admonished for choosing to use Firefox 4 – the latest version of a modern web browser – and I can only imagine what a less technically inclined visitor would make of the warning message.

Thankfully browser sniffing is still a rarity, but all too often I see evidence of designers who are ignorant of, or choose to ignore the fact that many embedded web fonts render in a sub optimal fashion on the Windows platform. For these designers the fact that the website looks nice on their own (presumably Apple branded) computer seems to be enough. Never mind the fact that 85% of the average website’s audience use the Windows platform, and will experience the site’s typography in a very different fashion.

Jeffrey Zeldman called the disparity between various browser and OS font rendering engines the “elephant in the room” – everyone knows the problem is there, but none of us wants to mention it for fear of spoiling the web font party. Sadly his warning seems to have gone unheeded by some. Too many web designers continue to make poor font selections, ignore the majority of their users, and jeopardize their website’s usability in the process.

Thankfully typeface designers are beginning to acknowledge the problem, and hinting their fonts for improved performance on the Windows platform. Recently the Skolar typeface, which used to look very shabby in Windows, was skillfully re-hinted by Ross Mills and now renders superbly. But the responsibility doesn’t rest solely with type designers – web designers and font vendors need to do their share too. Mills wrote an article for Typographica called The State of Webfont Quality from a Type Designer’s View in which he urges all parties involved in the production and distribution of web fonts to carefully consider the quality of the fonts being released. From my perspective that means web designers too: if we don’t choose our web fonts appropriately then can we really claim to be doing our jobs properly?

The case can be made that Apple’s approach to font rendering is superior to Microsoft’s, but that doesn’t give web designers an excuse for subjecting Windows users to a substandard typographic experience. Web design has always been about compromise and working within technical limitations. Trying to modify user’s behaviour by convincing them to switch operating system or browser won’t work, and designing for a single platform is simply irresponsible.

Instead, why not restrict our typeface choices to those fonts that have been optimised to render well on both the Macintosh and Windows platforms? There are plenty of well hinted fonts out there, and as the web font marketplace matures the number of choices will continue to grow. Yes, it requires patience and restraint, but restraint should be something we’re all used to by now – for years we’ve had to make do with the handful of fonts that come pre-installed on both Windows and Mac OS. Surely it won’t kill us to continue using a little of that self-control and limit ourselves to web fonts that render well for all our users, instead of designing for a minority.

PHP example:

HTML example:

CSS example:

JavaScript example:

I’m not sure who designed the Monokai theme originally, but it has cropped up in Textmate, Notepad++, Sublime – where it is the default colour scheme – and no doubt a bunch of other editors as well.

My version of Monokai is based on a Notepad++ theme, but I have standardised the color of variables (green) and symbols (white) across all the languages.

I don’t actually use phpDesigner much these days – I’ve jumped ship for Aptana Studio 3 – but I still think it is a great code editor, and hopefully someone out there will get some use from my theme.

Download

Download Monokai theme for phpDesigner

Installation and uninstallation instructions are included with the theme. The theme has syntax highlighting colors for the four languages I work with: HTML, CSS, JavaScript and PHP.

Important

There is currently a bug in phpDesigner that sometimes causes the ‘separator’ colors to revert to their defaults (e.g. the color of tags reverts to black). The only sure-fire way to get things back to normal is to open the phpDesigner preferences dialog, and click ‘OK’.

Apparently this bug will be fixed in the next release of phpDesigner (yay!).

Use a global reset

Web browsers apply default styles to HTML documents, but they do so inconsistently. So that you have a level playing field when you start writing your CSS rules it is important to ‘reset’ those browser-defined styles.

Eric Myer’s venerable CSS Reset is the best known global reset snippet, and he has recently updated it for HTML5. Others options to consider are the HTML5 Doctor Reset Stylesheet and HTML5 Boilerplate.

It doesn’t matter which flavour of reset you use, just make sure you use one! A global reset saves you from having to overwrite browser-defined styles at multiple locations throughout your stylesheet, and leaves you to concentrate on defining the styles you want instead of removing the ones you don’t.

Break your CSS files into logical blocks

Stylesheets can grow very large, and the bigger they become the harder they are to navigate. One way to manage this complexity is to organise your CSS document into smaller blocks, each one dealing with a specific aspect of your application.

I use CSS comments to demarcate each block of rules in my stylesheet, making it easy to scan the document for section headings rather than hunting for individual selectors:

/* Navigation
**************************************************/
 
nav { ... }
 
/* Footer
**************************************************/
 
footer { ... }

The document outline you settle on will be a matter of taste, but I typically divide my stylesheet into the following sections:

• Global reset
• Minimal base styles (generic)
• Extended base styles (site specific)
• Common shared styles
• Page structure
• Navigation
• Headings
• Footer
• Forms
• Printer styles
• Handheld styles

The ‘global reset’ and ‘minimal base styles’ sections stay the same from one project to the next, but everything else will change depending on the project requirements. I also assign a block to each major section of the website: the homepage, image galleries, contact page, and so forth.

Use indentation to nest CSS rules

Certain CSS properties are inherited by descendant elements, and it can be helpful to visualise the inheritance chain by indenting your CSS rules. This makes it easy to see where an element sits within the document tree and inherits its properties from.

#nav {
    float:right;
    }
    #nav li {
        float:right;
        width:100px;
        }
        #nav li a {
            color:#ccc;
            }
        #nav li span {
            color:#fff;
            }

Indentation is very common when writing HTML markup, but I find it invaluable for organising my CSS too.

Organise your declarations following the box model

When I was a starting out with CSS I didn’t employ any particular system for organising declarations within my CSS rules. I imagine this is how most web designers start off, but the lack of logical structure makes it difficult to locate a specific property within your CSS rule.

Once I started to get more organised I began sorting declarations alphabetically, so for instance a background property would come before a width property. There is a certain logic to that approach, but it means that related properties (font-family, color, and text-indent, for instance) are scattered around the rule instead of being grouped together.

More recently I’ve settled on a method of organising declarations that keeps related properties grouped together, yet standardises the order in which they appear within a rule.

My method is to organise declarations following the CSS box model, moving from the outside in. In addition I place properties that affect the element’s interaction with the rest of the document at the top of the rule, and text-level rules near the bottom.

#my-element {
    display:block;
    float:left;
    margin:10px;
    border:1 px solid #999;
    padding:2px 4px;
    width:200px;
    height:50px;
    color:#fff;
    font-size:14px;
    background:#000;
}

The precise order in which properties should appear is debatable (should float come before display, or after?), nevertheless I find that that this approach helps me construct a mental picture of the element’s box model and its interaction with other elements on the page.

Use shorthand property values

Many CSS properties support shorthand notation which allow you to define several properties in a single declaration. This minimizes bloat as well as making your CSS easier to read and edit.

For example instead of:

border-width:2px;
border-style:dotted;
border-color:#ffffff;

You could write:

border:2px dotted #fff;

Write for readability, not performance

When multiple selectors share the same rule, place each selector on its own line. This increases readability and ensures the selectors don’t get lost in a lengthy list. The same goes for CSS declarations. Instead of chaining your declarations together on a single line give them room to breath.

#nav li a,
h2 a,
.home aside h3 {
    margin:1em 0;
    padding:0 0 0 50px;
    color:#ccc;
}

This is much more readable than:

#nav li a,h2 a,.home aside h3{margin:1em 0;padding:0 0 0 50px;color:#ccc;}

If you want the benefits of readable CSS and the bandwidth savings of single-line notation, then all you need to do is minify your CSS immediately prior to deploying your project or on the server.

Use comments for storing notes

I usually keep comments within my CSS files to a minimum, but one place where I like to be expansive is at the top of the document, where I store ‘meta information’ about the stylesheet.

In this header comment I include the project name, the purpose of the stylesheet and author contact details.

/* F6 DESIGN
   Master Styles
   Author: Jonathan Nicol (jonathan@f6design.com)
 
   Resources
   HTML5 Boilerplate: html5boilerplate.com
 
   Colors
   Text gray: #76797b
   Link blue: #03add1
   Heading black: #1b1d1e
**************************************************/

In the example above I have also made a note of any CSS techniques I may want to refer back to later, and stored references to commonly used hex color codes. It is a pain in the butt to scour the entire document looking for a specific hex value, and I find it more efficient to store my color codes in one place. You could use the same technique to store other commonly referenced CSS values, and needn’t restrict yourself only to colors.

Share your own tips

Organising CSS is very much a matter of personal preference, and there is no right or wrong approach. If you have any of your own CSS efficiency tips to share, please leave a comment below.

When I switched back to phpDesigner, the default blue-on-white color scheme seemed a tad boring, so I decided it was time to pimp my IDE! Unfortunately user created themes for phpDesigner are thin on the ground, which left me no option but to make my own.

PHP example:

HTML example:

CSS example:

JavaScript example:

I’ve named my theme Sunset, and it is inspired by the Midnight theme for SyntaxHighlighter. If any phpDesigner fans are looking for a light-on-dark color scheme to spruce up their code editor, perhaps Sunset will fit the bill.

Download

Download Sunset theme for phpDesigner

Installation and uninstallation instructions are included with the theme. Currently the theme has syntax highlighting colors for the four languages I work with: HTML, CSS, JavaScript and PHP.

Important

There is currently a bug in phpDesigner that sometimes causes the ‘separator’ colors to revert to their defaults (e.g. the color of <?php ?> tags reverts to black). The only sure-fire way to get things back to normal is to open the phpDesigner preferences dialog, and click ‘OK’. You might also try closing all your open documents and restarting the application. Hopefully this bug will be fixed in a future version of phpDesigner.

• The original typeface for Safari and Firefox 3.5
• A WOFF font for Firefox 3.6+
• An SVG font for Opera, Chrome, and iPhone
• An EOT font for Internet Explorer
• A sample HTML page
• A sample CSS stylesheet

The generator also features options to reduce file size by subsetting the font, cleanup font outlines, and auto-hint glyphs to improve rendering.

Sweet!

The trouble is that digital fonts have no provision for DRM, and pirating a copy of an embedded web font is a trivial exercise for anyone with the mind to do so. That’s obviously not a prospect type foundries are too keen on, and consequently no major foundry offers a licensing option for embedding their fonts in a web page. If you link to a commercial font from your CSS stylesheet the chances are that you are breaking your license agreement. Even the number of free fonts with an EULA that condones @font-face embedding is pitifully small.

That’s where Typekit comes into the picture. Typekit is a new font delivery service devised by Jeffrey Veen that promises to take the pain out of licensing fonts for web embedding. In their own words:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

Here’s how it works:

• Typekit strike up agreements with type foundries allowing fonts to be licensed for CSS linking.
• Web designers subscribe to Typekit, and pay a monthly fee to embed typefaces on their websites using an @font-face declaration.
• Would-be font pirates are deterred from stealing embedded Typekit’s fonts by security measures including: allowing only authorised domains to link to their fonts; source code obfuscation; and splitting fonts into multiple files.

Problem solved, right? Well, perhaps.

Typekit’s font-as-a-service model navigates a clever path through the legal minefield of web font licensing, but I am not convinced that it is a perfect solution. In particular there are two aspects of Typekit’s approach that strike me as problematic: the fact that their pricing model is based around renting fonts rather than owning them, and the need to rely on remote servers for the delivery of fonts.

Renting vs buying

Because Typekit is still in beta details of its pricing are sketchy, but it is clear that customers will pay a monthly or annual subscription fee to access Typekit’s font library. This pricing model is significantly different to the traditional one-off payment required to license fonts for offline applications.

Will website owners be prepared to continue paying for a font month after month, year after year? Over time Typekit subscription fees could conceivably exceed the cost of a standard font license, despite the fact that Typekit’s fonts cannot be reused in any other medium, or potentially even on another website. And if you ever cancel your Typekit subscription, the fonts vanish into thin air. This is a radical departure from the current font licensing model, which grants customers the right to perpetually reuse any fonts they purchase.

Purchasing fonts twice

In addition to the fact that font subscription models require designers to pay for fonts they can’t reuse, in most cases it will also be necessary to purchase a regular installable version of each typeface.

To produce mockups and work on a production version of a website, a web designer needs to work with the same typefaces that will feature in the final live site. Typekit only offer web embedding of fonts, so to install a typeface on their local computer a web designer would have to purchase a separate font from another vendor. It’s not going to cut the mustard to produce mockups set in Arial and tell the client to “imagine that the headings are actually Avant Garde”!

When you also consider that many websites have multiple domain aliases (mysite.com, mysite.com.au, etc), and Typekit uses a per-domain pricing model, it is clear that the potential exists to pay many times over for the same font.

Network reliability

Another potential problem with Typekit is network downtime.

I can’t imagine many designers would trust their CSS files to a remote delivery network, and I think we need to accord fonts a similar importance. If major players like Google and Amazon suffer network interruption from time to time, then it is reasonable to assume that Typekit will too.

Admittedly, occasional network outages may not be a deal breaker, what happens if Typekit goes out of business, or a foundry retracts the right for Typekit to distribute their fonts? In either of these scenarios it seems probable that Typekit subscribers would have the fonts rudely stripped from their websites. In a best case scenario subscribers could turn to a Typekit competitor such as Fontdeck to revive their font links, but what if no competitor offered the same typefaces? The design of countless websites could be irrevocably ruined due to their dependence on remotely hosted fonts.

The future of font embedding

Despite the reservations I have outlined above, I have to agree with Andy Clarke when he predicts that Typekit will change everything.

By coming up with a practical answer to the problem of @font-face licensing, Typekit has paved the way for alternative font embedding approaches. Clearleft and OmniTI have joined forces to create Fontdeck, and at least one foundry, Typotheque, has a web font service under development.

Soon there will be a number of services vying with Typekit to win the hearts (and wallets) of web designers, however I suspect the deciding vote will ultimately be cast by large font foundries such as Linotype and Adobe.

The type industry’s major players will need to decide where they stand on the issue of font embedding, or they risk being left behind while smaller type foundries reap the benefits of web font licensing. If they follow the lead of their counterparts in the music industry it might be years before our @font-face woes are sorted out. On the other hand they might choose to take the bull the horns and launch their own font hosting services to compete with Typekit.

Whatever the response of large type foundries and vendors turns out to be, it will very likely determine the future of typography on the web. Hopefully we end up with a solution that is fair to web designers, website owners and font foundries alike.

Further reading

Introducing Typekit

Jeffrey Veen announces the arrival of Typekit, and explains the basics of how the service will work.

Ubiquitous web font embedding just got a step closer

John Allsopp argues the case for more liberal font licensing. Recommended reading.

First impressions of Typekit

A step-by-step tour of the Typekit beta.

On Typekit

David Yeiser shares some of my reservations about Typekit.

The Font-as-Service

Jay Elliot Stocks gives an overview of Typekit and its competitors.

Testing Typotheque @font-face embedding

Andy Clarke takes Typotheque’s new web license for a spin. It is interesting to note that Typotheque requires a one-off payment rather than a subscription like Typekit.