Printing The Web

Printable Websites - some books

While it is possible to consume nearly all means of content on your smartphone or tablet it seems like the dream of a paperless office comes true for a lot of web developers.

But digital natives are not the only ones who are on the web. There are still some people that like to print web sites on paper. Once you are aware of that you might want to include a dedicated print stylesheet into web sites you build. Here is some advice on what you can do to get the best out of your page.

Disclaimer: This article was first published in the German Screen Guide Magazine #15 (September to December 2012, pages 77 to 79). This article features more content and better research.

The basics of a print style sheet should already be well known by most web developers. There are two possible ways to include CSS for print:

  • a separate file included in the HTML that carries all CSS for print media
    <link rel="stylesheet" media="print" href="css/print.css">

  • a special media query which targets print mode and is integrated into your regular stylesheet
    @media print { … }

The decision which way to go is pretty obvious: We do not want to have another request to the server for an extra style sheet and thus will embed the styles using a media query. With the help of preprocessors such as LESS or Sass and build systems it is easily possible to put these styles into separate files and concatenate them when needed for production.

Remove Clutter

In general focusing on the main content of a web page is very important when it comes to print style sheets. Remove unnecessary page elements such as navigation and the footer using display: none;. However you might not want to remove a logo that identifies your website from the printed version. (Maybe you have an optimized monochrome version that looks better when printing black and white – you can include this as a background-image. This can be overwritten via the user’s configuration though.)

Think about readable fonts and appropriate font sizes – in print you usually want to have a size not bigger than 12px for your body copy, but on screen 16px is totally appropriate. Furthermore it is important to print mostly dark colors on light background. It might be the best solution to use black as the default text color.
This is also more economical than printing other colors.

When in doubt, print the page while developing it to get a better feeling for the font setup.

Improve The Content

There are a couple of techniques to add more value to the content of a page. One is to add the URL of a link directly after the link text. Don’t do that for links that link to sections of your page or have JavaScript handlers, because it will not carry any meaning for the uninformed reader:

a[href]:after {
    content: " (" attr(href) ")";
}
 
a[href^="#"]:after,
a[href^="javascript"]:after {
    content: "";
}

This is also useful for the abbr element (for abbreviations) and its title attribute. (The same rule technically appies to acronym – thanks to Adrian Roselli).

abbr[title]:after {
    content: " (" attr(title) ")";
}

You can find a more detailed post about this technique here.

Edit: As Tim suggests in the comments it might be necessary to use word-wrap: break-word; on these elements as especially links can become pretty long and thus break you layout.

Remember that browsers normally display a header and footer line with some information about your site such as the URL it was printed from or the date. The user might have an option to remove those lines so you may want to include some link or a breadcrumb in the printed page so the reader can easily check back on the web if needed. Other methods outline embedding a QR code on the printed page. Adrian Roselli describes this method further.

In general most style sheets might be done with these few considerations. But there are some more helpers and CSS rules that can come in handy in certain cases.

A few weeks ago there was an interesing article at Smashing Magazine which has some more useful tips for dealing with links, images and so on. Check it out if needed.

Structuring The Page

Let’s dig a bit deeper.

The at-rule @page allows you to specify the structure of the page. Here is an example of how you can configure the margin of the page:

@page {
    margin: 2cm 1.5cm;
}

Furthermore it is possible to define styles via pseudo-classes. With :first for instance you target only the first page of a document, :left and :right target all even/odd pages (this depends on the direction of writing in a language). This can help you if you want to print a manuscript or magazine for example.

It is possible to name a property and apply it to differnet elements. This comes in handy if you want to print tables in landscape mode:

@page tables {
    size: landscape;
}
 
table {
    page: tables;
}

This is far more experimental and can not be used reliable. Check out this test case. Please see the specification for a more detailed explanation.

More information about the @page rule can be found at the Mozilla Developer Network.

With size you can specify the size of the sheet you want to print your document on. The initial value is auto which sets the width to a DIN A4 sheet with a size of 210 × 297 millimeters. You can target an expected DIN A5 sheet this way:

@page {
    size: 148mm 210mm;
}

Even though this is possibile you should let the printer defaults handle the size of the sheet, especially since DIN A4 is not used in the US for example.

Side note: Please be aware that it is still not possible to cut a sheet via CSS, thus it is only an expected size. I know this sucks! 3D printers might save us soon.

Page-Breaks

Both properties page-break-before and page-break-after specify when a page break occurs and when you do not want it to happen. For instance you most likely want to avoid page breaks after a headline:

h2 {
    page-break-after: avoid;
}

Possible values of page-break-before and page-break-after are:

  • auto – default value, no specified behavior
  • always – invokes a page-break
  • avoid – tries to avoid a page-break
  • left/right – single or double page-break to get the element to start on either the left of the right page, interesting when you want to print brochures or books.

Furthermore, there is the property page-break-inside which behaves similarly but only supports the values auto and avoid. While avoid specifies that there sould be no page-break within the element and auto does not specify a specific behavior.

Experimental Properties

The next few features are still in development or only supported by single browsers. Some of them are part of the (not really) new CSS Paged Media Specification.

Print What You See On Screen

The property -webkit-print-color-adjust: exact; only works in WebKit browsers (namely Chrome and Safari) and enables you to print a page exactly as it is displayed on screen. Mostly this means that you can print CSS backgrounds. But be careful, there is a bug when it comes to gradients: Gradients are not printed at all. Also it is not possible to define the property on the body element (Whaaaat? :/).

You need to use this property if you want to print a b/w-optimized logo as outlined earlier and you don’t want to include an image in the markup.

Other browsers such as Firefox allow users to specify whether they want to print background images and colors via an option in the print dialogue.

Widows And Orphans

To prevent single lines of text to be at the end of one page you can adjust how many lines have to be tied together with orphans. p { orphans: 3; } for instance requires at least three consecutive lines in a paragraph on the end of a page.

In contrast – only one line at the beginning of a new page – widows helps you out. So with article { widows: 2; } you will get at least two lines of text for an article on a new page.

Crop Marks And Page Bleed

Sometimes you need specific declarations on how to cut a sheet of paper. With marks it is possible to set marks via the values crop and cross while crop adds crop marks and cross adds fiducial marks.

If this property is set you can specify how far the printable area spreads out of the area defined by the aforementioned marks by using the property bleed while using one of the units defined in the values and units specification.

This property is part of the CSS Generated Content for Paged Media Module which is basically to really recognized by the browser vendors.

Boxes On Page-Break

The property box-decoration-break specifies how for example background, margin or border behave when the page breaks. There are two possible values for this property (also see the picture):

  • slice – default value, literally “slices” the box into two parts
  • clone – dupicates the styles that are applied to a box on each page

This is currently supported by Opera with the Presto Engine and will shortly be availabe in Google Chrome. Lennart Schoors wrote about this property a while ago on his blog Bricss.

In Firefox there is -moz-background-inline-policy which enables you to treat background images how you want to. But this is clearly only a partial implementation of box-decoration-break.

More On Browser Support

While the at-rule @page is supported by all major browsers except Internet Explorer 7 and was just implemented by Firefox a few months ago. Most other properties are far more complex:

  • You should use page-break-before and page-break-after only with its value always since the other values are not supported widely
  • page-break-inside is not supported in Internet Explorer 7.

You have to be aware that nearly all experimental properies lack support in most browsers and are only implemented by one major engine. For example orphans and widows are only supported in Internet Explorer since version 8 and Opera – which will soon be history as of their change to WebKit. marks and bleed is not implemented in any browser so far.

What Is Missing?

There are certain drawbacks when it comes to styling for print: Up until now there is no good possibility to define header and footer lines for your pages which would be very helpful for paginated printing. You can use pseudo elements of the body element which enables you to set a header and a footer on the first and last page. But this is by far not what is needed. You will run into this problem when you try to print tables: it is simply not possible without duplicate markup to print the thead of the table on each page (while repeating markup is not a real solution as you don’t know where a page breaks).

The funny thing is the specification of thead and tfoot states that it might be useful to repeat the elements on each page. Sadly no browser vendor implemented this yet.

But it is possible to create a solution for that. It could be a nice thing to implement JavaScript events that get invoked right before a page is printed. But as Simon Sapin states this is not really possible due to the mechanisms how browsers layout a page:

Page breaks happen during layout, much too late to do DOM manipulation (which invalidates and restarts layout). It’s really up to the layout engine to do this.

Also more properties for @page could be helpful to generate header and footer for each page.

Luckily the Paged Media Specification tries to tackle this problem. This specification has just become a Working Draft.

Here is an example on how you can implement a footer with the page count on every page:

@page {
    counter-increment: page;
 
    @top-center {
        content: "Headline, yo!"
    }
 
    @bottom-right {
        counter-increment: page;
        content: "Page " counter(page);
    }
}

The counter-increment property is a bit special with the keyword page – it increments automatically according to the specification, so you don’t need it at all.

That rocks, right?! Totally want this in browsers now.

Edit – 26.03.2013: Actually there is another possible implementation for fixed headers and footers using position: fixed; elements as Robert Weber researched. Unfortunately this only works in Firefox, Opera and Internet Explorer with several quirks. Please read his comment.

A Word On Mobile

These days it has become more and more popular to visit web pages from your smartphone or tablet but I have never seen anyone printing a web page from such a device.

I am not aware of a browser that has the ability to print a page. But maybe this will come in the near future. Let me know if you know more about this.

Edit – 25.03.2013: As Cãtãlin Mariş points out, iOS has a feature to connect to a wireless printer and print a website. This uses Apple’s AirPrint services.

The Server-Side

This post does not take any server-side rendering methods to create style sheets into account. However there are some several non-browsers, print-oriented CSS implementations: WeasyPrint, PrinceXML or AntennaHouse and others implement many CSS features that browsers don’t.

So take a look at these libraries if you are in need of more consitend

Conclusion

As it turns out it is possible to handle simple structured web pages with the provided properties for print stylesheets. But when it comes to more complex applications you will easily reach the end of these possibilities.

As a result of the work that the editors put into new specifications such as the Paged Media Spec we will be able to deal with better solutions in the future.

Thanks

A big thank you goes out to Adrian Roselli and Simon Sapin for providing very valuable technical feedback for this article. Apart from that I want to thank Thomas Caspers for proofreading the post.

The REM Fallback with Sass or LESS

Since a while now word has spread to use the CSS unit rem for font-sizes and values in CSS. Here I want to explain how you can use a fallback in Sass or LESS to get rem working in all browsers.

View Gist with mixins

Why rem?

Let’s look into what rem means. We know of the em unit which is relative to the font-size of the parent element it is defined on. This means if one of the parents in the DOM-tree changes its font-size, the font-size of the child element changes too. In contrast the rem unit is relative to the root element of the page (this means the html element). Thus it is possible to define a font-size once on the root and make all other sizes depending on this size. Please switch over to Snook’s blogpost explaining what rem is to get more information about it.

If you ask yourself why you should use em instead of px, Chris Coyier wrote an article on why he switched to em instead of pixels a while ago for nearly all properties using units in CSS. Read this to understand why em and thus rem is so important.

I would encourage you to use rem (or at least em) for properties like padding, margin and sometimes even width instead of pixels. It makes your design even more responsive.

The drawback of rem is that it is not supported in all browsers that are used, even though the support looks pretty good: Internet Explorer is capable of dealing with rem since version 9. The versions before need a fallback. It is supported on the major mobile browsers except Opera Mini. Let us have a look on how we can define such a fallback using Sass or LESS.

A Sass Mixin

In order to get the pixel-based auto-calculation working as a fallback we need to define the font-size as a variable in Sass or LESS.
The following examples are in Sass with the SCSS-syntax.

$main-font-size: 16px;

We can now use this default font size on the root element:

html {
  font-size: $main-font-size;

Now we define a mixin that provides a fallback pixel-based size of the property based on the variable we defined before and in rem for capable browsers.

@mixin x-rem ($property, $value) {
  #{$property}: $value * $main-font-size;
  #{$property}: #{$value}rem;
}

What the mixin does is, that it takes the $property and calculates the value in pixels. This simple mathematic function is part of Sass. The $value argument is a decimal digit.

I like to prefix my own mixins with x- to easily distinguish them from other mixins. This is a part of the Idiomatic CSS principles by Nicolas too. I think previously I prefixed them with a namespace (mostly it was the- as a prefix, so you get the-transition) – but since there is a better convention with Idiomatic CSS I switched to it.

This mixin can be called like in the following examples:

@include x-rem(font-size, 1.4);
@include x-rem(padding-left, 2);

The output that is being produced looks like this for the first example:

font-size: 22.4px;
font-size: 1.4rem;

You can use Sass’ round() function to get an integer output for the px-based output. But every browser is capable to round 22.4px by itself to 22px since it is not possible to display 0.4px after all. (LESS has the same function.)

A Few Words On The LESS Mixin

In LESS interpolation for properties is current not possible with version 1.3.x. The maintainers aim to include it in version 1.4. For the time being we need to define a workaround for properties which is basically a JavaScript function which returns a sting that consists of two properties instead of one, while the first one is - which is basically no property an thus disregarded by the browser. The second is the property that we want to use.

Here is the first line of the mixin:

-: ~`(function () { return ';@{property}: @{px-fallback}'; }())`;

This only works if the LESS compiler uses the actual JS library. It does not work with lessphp or other compilers that are not JavaScript based.

Final Words

And that is it. The mixin provides a decent fallback for rem-based sizes of all kind. Since CSS runs stable with this version of a fallback and overwrites the pixel-based value because of CSS’ cascade we can use it without any problems. It works in old Internet Explorers.

Life is easy with rem. So look at the Gist and use the rem-fallback-mixins.

Sass and LESS mixins

Credit

I want to mention that I first saw this technique used by Divya Manian a year ago (beginning of 2012) when working on the HTML5 Please API project. I am not sure who developed this technique or where it comes from. Please let me know if you have a link.

Addition: The Susy framework has a Sass mixin which lets you easily convert units including the rem unit and a fallback as described here. (Head-tip Fabian Beiner.)

Addition 2: Steffen wrote a Sass mixin which lets you use the short notation of properties like margin or padding. Even mixing values as px and rem is working. Cheers!

SASS vs. LESS

“Which CSS preprocessor language should I choose?” is a hot topic lately. I’ve been asked in person several times and an online debate has been popping up every few days it seems. It’s nice that the conversation has largely turned from whether or not preprocessing is a good idea to which one language is best. Let’s do this thing.

Really short answer: SASS

Slightly longer answer: SASS is better on a whole bunch of different fronts, but if you are already happy in LESS, that’s cool, at least you are doing yourself a favor by preprocessing.

Chris Coyier finds an answer to what preprocessor is the better one by pointing out what the advantages of each preprocessor are. And as it turns out SASS is winning the race because it has more power and better features. So if you are asked why you use SASS, you might want to link people to this post.

My Coding Style and Guidelines

After Harry Roberts published his HTML/CSS coding style I’ve decided to follow his call and write down how I like to code and what my guidelines for HTML and CSS coding are.
This article is only a way to describe what I like to do – but it is by far not a recommendation or something. I have not really tried to “canalize” the coding style I do before but it is about time to do so and to write it down. Please let me know if you think that there are ways to do certain things better or in a more understandable way through comments.

Harry points out some over all pretty solid ways to keep the markup readable which I use too. The major one is whitespace, I think. To be true, I love whitespace. But I’ll come to this later.

General

Tabs or Spaces?

Personally I’ve learned to use tabs instead of spaces just a few weeks ago. Lea Verou lists up some arguments, why she thinks using tabs is the way to go. But there are still some use-cases for spaces she describes.
At /gebrüderheitz I’ve discussed using spaces with Steffen before. He works a lot with PHP and uses Tabs since… – ever! I have been using spaces because I ran into some difficulties with tabs in the past where code was totally wrong indented and stuff. But at the moment everything runs pretty smooth and I am happy with how it is.

Lettercase

HTML5 and CSS let you write code how ever you want to: UPPER-CASE, lower-case, CaMeL-cAsE. So this is all the same:

<section id="a-lovely-header" class="contains-a-logo">
<SECTION ID="A-LOVELY-HEADER" class="CONTAINS-A-LOGO">
<SeCtIoN iD="a-LoVeLy-HeAdEr" ClAsS="cOnTaInS-a-LoGo">

You have to make sure you use the according class in CSS and id in JavaScript, because they are both case-sensitive.

I use lower-case exclusively. I’ve never tried to use anything different as it does not seem natural to me. Apart for that, WHO THE HELL WANTS SO READ UPPER-CASE ALL THE TIME?! IS THE CODE REALLY YELLING AT YOU? HAVE YOU EVER SEEN THIS IN A SERIOUS BOOK? Ok – to be fair, I’ve never seen a serious book with all lower case. But camel-case? C’mon…
Camel-Case in JavaScript is totally perfect though.

HTML

Harry names a view key parts of HTML styling which I use and some I really do not like.

Unquoted Attributes

I never write unquoted attributes. Harry states that this is something he does, because he can. Well… That’s true. But as he points out he has some rules where he quotes attributes for example for generated content or content that changes a lot.

His opinion on using double-quotes for all the attributes is obvious, anyway:

It is more consistent on the whole, but by introducing rules I make my own consistency; if you can get away with not using quotes, then do so.

For me the rule “Don’t confuse others” applies here: When another programmer who is not familiar with writing attributes without quotes has to edit my code in a later stage of a project or just when checking the source of a project and sees this, she might be confused with what I wrote.
Apart for that, writing attributes without quotes is error-prone.

An example: You use the Media Object as described by Nicole Sullivan for your styles and need a button, you will probably add a class btn to your link. The action that this button takes care of is the primary target of a website. Thus you add another class primary-btn to the class-attribute. If you don’t use quotes, you’ll have to add them now. It may occur that you forget them. And now what?! You are screwed. This will lead into searching your template over and over again until you find this nasty little mistake you made earlier. I don’t want this! I like code that’s pretty much straightforward.

To be fair I have to say, that I use a build script for my code before it goes into production which minifies my HTML-code and thus removes unnecessary quotes. But this does not change my development coding style.

Self-Closing Tags

Omitting self-closing tags is a thing I really love about HTML (over XHTML). You can omit the closing tag. Actually I’ve seen people not using self-closing tags on images or inputs but using them in meta-tags. I don’t know what the sense behind this might be.
I just do not use them anywhere.

Optional Closing Tags

This is a thing people may get confused about, too. Just a view days ago someone re-filed the issue of missing closing tags for HTML5 Boilerplate’s 404-error-page template because he was confused of the missing stuff I guess. That’s why I try to always use the optional closing tags – again: don’t confuse anyone. At least I try to.

I remember Paul Irish had a great usage of optional closing tags for tables where you can align rows by using whitespace, so you can see the table’s layout in HTML. Not working with generated data, though.

Here’s the example

<table>
  <tr><th>Name           <th>Country       <th>Nonsense
  <tr><td>Rick Astley    <td>England       <td>Rickrolling
  <tr><td>Chuck Norris   <td>United States <td>Roundhouse-Kick
  <tr><td>Emeli Sandé    <td>Scotland      <td>Singin – Fo realz!
</table>

Whitespace

Oh yeah, whitespace. As I already pointed out I love whitespace in my code. Everything is a bit more obvious when you divide it into small parts. It gets easier to scan the code I think. Comments help with this too.
I like to divide bigger chunks of a page with a lot of whitespace. For example if you have a content-area and a sidebar, I try to keep them separate by using whitespace.
Apart from that grouping elements like definition-list-entries helps a lot with the readability of code.

I’ve made a gist with an example-file. Check it.

CSS

Using ids in CSS is something I try to avoid but it strikes me sometimes and I just do it if there are already ids defined on some elements. Mostly these are identifiers for header- or footer-sections. But I think it’s better use classes for styling concernes and ids for JavaScript and other stuff.

Anyway… The next part will not be about vanilla CSS. I use SASS (SCSS) nowadays and recently re-factored a corporate website for one of our customers at /gebrüderheitz in SASS. I want to share the way I worked with a lot of CSS in this case and did it sometimes before.

Structure

The website has a lot of styles which had to be refactored. These were organized in one big file that has about three thousand lines of code. I do not like to have a file that has so many code and is not clear by looking at it at first.
So I have decided to split up several parts into different files.

Before the refactoring we made an online style-guide, defining the elements that appear on the side. This style-guide will be used in other projects for the same customer, too and is essential for a corporate website. We tried to define as much as possible but also let designers have a free hand at what they do.

For all SASS-files I use a folder-structure which looks like this:

+ CSS
  + elements
  + helpers
  + modules
  + page
  styles.scss

The styles.scss file has a brief description of the project, who wrote the styles (copyright…) and includes (with @include) all other files which lie in the created folders.

+ helpers

helpers contains a file with pre-defined mixins, another file with all the variables for the project, a reset (in my case this is most of the HTML5 Boilerplate CSS, which contains Normalizer.css) and some other helper-classes which I use via mixins or with SASS’ @extend-method.

+ elements

In the element folder I include files with styles for styling native HTML elements. I’ve got a file named typography which contains definitions for the general copy-text, headlines, links, quotes aso. Another file contains all stylings that are connected to lists in the content (unordered-, ordered- and definition-lists). This folder also includes the styles for forms and tables.

+ modules

I mentioned the style-guide we defined for this project. This was a great help for me when dividing the CSS into parts because I was able to see which modules were needed for the page: boxes, a paginator, an accordion menu, the navigation and some other stuff.
For each module I have an own file which contains the styles of only one modules. So when I need to change something that has to do with the paginator, I’ll head over to the according file and change the desired values. This saves me a lot of searching and scrolling through a file. Apart from that, Sublime Text’s “Find in files” (cmd + Shift + F) feature lets you search trough all files in a project which is pretty handy. Text Mate has something similar I think. And if your editor does not support it, fire up the console and grep for the things you want to find.

+ page

This last folder contains all files that add a separate styling for any page or part of the website. Typical content might be the general layout and the header and footer styling for a page. Furthermore I define styles for an area of a website in this folder – e.g. if events need more styles than defined in the modules section, or a contact-form that has some extended stylings.

And More?

We have not yet done the styling for the mobile version of this website and thus the styles are not yet included into the project’s folder structure. Styles that are specific for devices with smaller width will go into a mobile-folder.
Another thing are stylesheets for print or other media. I’ve not yet found a proper way to include these. If you have any idea for this, let me know.

Whitespace & Comments

Back to the main CSS styling guidelines for my projects.

Typically I try to avoid too much rulesets in one file but sometimes you need to do this to not split one feature into several files, which is not the sense behind this modal.
Comments are a thing that help everyone reading the defined styles to unterstand them better. Most of the class names are pretty obvious and thus don’t require any further explanation. But if you define styles that are not obvious at the first glance or you need to use browser-hacks in any form it can be helpful for other programmers to include a short comment. At least I do it this way.
I try to think about “other programmers” as the programmer I might have become in three month, when I will look at the defined styles again. If I don’t know what I did three month ago, how is anyone else supposed to understand it. This needs to be avoided.

Formatting

One thing Harry mentions is that he does not use a lot of whitespace in his rulesets. I am allergic of this style of writing. I like to have really clean styles as this:

.some-rule {
  float: left;
  color: #666;
  text-decoration: underline;
}

For vendor prefixes he indents every rule so he can use typing in columns. As I use SASS I don’t really have to care about this. But I like the way he does it. I’ve done it the same way when I used to write vanilla CSS.

Indenting is somehow essential for the CSS nesting in SASS. For rules where the nesting does not work I don’t indent though.

And A Lot More

This is not everything that applies to my HTML and CSS workflow / guidelines. I hope I can write more about stuff like this in the future and share more of my thoughts. Feedback on my thoughts would be great.

Also: If you have some time, write down what your way of coding is. Share it on Twitter with the hashtag #codestyle.

RECESS – A CSS cleaning tool build on top of LESS

Developed at Twitter to support our internal styleguide, RECESS is a simple, attractive code quality tool for CSS built on top of LESS.

Incorporate it into your development process as a linter, or integrate it directly into your build system as a compiler, RECESS will keep your source looking clean and super managable.

As I think reading the source is essential for developers to become good at what they do viewing this source in readable style is essential too. RECESS is a tool which helps you developing good-looking CSS with LESS. It is developed at Twitter and has now been open-sourced.

RECESS is a Node.js module and is maintained by @fat. You can find out more about it by viewing the source at GitHub.

BTW: I’ve decided to not minimize and concatenate my blog’s source anymore. So, feel free to dig deep!

About CSS Variables

Please read about the updated syntax of CSS variables in the first and second update of this post.

Since a little bit more than a month (as of the time of writing) there is a Editor’s Draft for a CSS Variables Module by Google (Tab Atkins and Luke Macpherson) and Daniel Glazman. Just a few days ago the Working Draft was updated.
The first draft was written in 2008 by Daniel Glazman but was not added to the official specification. The new WD extends this proposal by Glazman.

Disclaimer: This article is part of a small series about the latest CSS working drafts. The first article in this series was about the CSS Hierarchies Module.

CSS Variables

The CSS Variables Module Level 1 suggests to use variables for data that is reused in stylesheets. These key-value storages provide the possibility to store “meaningless” data as you can do in HTML: Variable keys consist of a data--prefix and the variable name.

Any property name starting with the prefix “data-” is a data property. Data properties are defined to be valid but meaningless as they are meant solely for allowing authors to pass custom data around their page, similar to the custom data attributes in HTML.
Defining Variables With Data Properties – CSS Variables Editor’s Draft

Using data- as a prefix for variables is still in discussion and may likely be changed to something more “connected” to variables ($ or &).

Edit: The mailing-list www-style is discussing the use of data and Ian Muir wrote an article about the problem.

Syntax

Variables are defined by mapping them to the :root pseudo-class. The WD does not really explain why the variables must be declared on the root-element. Maybe it’s because the data needs to be bound to an element to not “fly around” in the global scope (which does not really exist in CSS).
Defined variables can also be set on every other element and overwrite the existing value of a variable.
So this is how you set variables.

To get a specific variable, you do not declare the variable-name but you call data as a function on a certain property with the variables name (without data--prefix) as an argument.

An Example

So here is an example:

/* Set data */
:root {
  data-main-color: #bada55;
}
 
/* Get data */
.foobar {
  color: data(main-color);
}

As said before, variables can be overwritten for specific elements. So we can add the declaration of the variable to .foobar:

.foobar {
  data-main-color: #fe57a1;
  color: data(main-color);
}

The color of .foobar is now #fes7a1 and not #bada55.

Real World Examples

Well, as this is an Editor’s Draft and pretty new it’s not being implemented in any browser.

I’ve created a test case on dabblet with vendor prefixes which tests the two examples above. I’ve run this test on the major browser alphas and nightlies.

Even though variables are not natively supported by CSS in any browser yet, we can use a very similar approach: All CSS preprocessors support variables. Here is an example with SASS:

/* Setting a variable */
$main-color: #bada55;
 
/* Get the variable's value */
.foobar {
  color: $main-color;
}

Conclusion

We can use variables with preprocessors today which is pretty rad. As with the CSS Hierarchies Module CSS in the future may support ideas that come from implementations in preprocessors somehow.
I think most developers are happy about these adoptions and will likely use it. But as it will take some time for all vendors to implement this feature – and even more time until browsers that don’t support such new features vanish – we will have to use preprocessors to get variables in our CSS working.


Update 19.08.2012

Since I wrote the last update the Editors Draft changed: The var()-function changed to use the var-glyph $ as it is known from SASS (described above).

It is now possible to call variables like this:

h1 {
  color: $some-color
}

While it still needs to be defined with the var prefix:

:root {
  var-some-color: #aaa;
}

As Tab Atkins describes in his blog this is going to change back to the old syntax I wrote about in the first place as this causes problems with further implementations of CSS (like variables for selectors and the hierarchy model).


Update 16.04.2012

Since last week the CSS Variables Module Level 1 is an actual Working Draft of the W3C.

It’s now possible to define variables with the var-prefix instead of data which is still pretty complicated. I wonder why they not adept an existing concept as in LESS or SASS.

Thus the data()-function changed accordingly to var().

Furthermore it’s possible to set variables on a certain element but use them in a more complex definition. An example might be the usage as follows (while elements with class important and primary are divs):

.important { var-color: red; }
.primary { var-color: blue; }
div { color: var(color); }

Also nestings for variables are possible:

:root {
  var-color: #ddd;
  var-border: 1px solid var(color);
}

The bright and shiny future

As I think there still are some issues with this Working Draft I like the fast step forward in making this a WD in only a view weeks.
So sooner or later variables will be part of the CSS specification and will be implemented in browsers. I hope this will be very soon.

About The CSS Hierarchies Module Level 3

Since the beginning of February there were some proposals for the CSS3 specification. These proposals are not yet part of the specification and will likely be changed until they get adopted by the CSSWG. One of these drafts is the CSS Hierarchies Module Level 3.

So what’s the Hierarchies Module? And why “Level 3”?

The Hierarchies Module is not exactly new. It exists since the very first steps of CSS and was first released in Dezember 1996 with CSS1. The CSS1 specification is still up, so check it out if you want to.

When you write CSS you always use selectors to target the element you want to style. This works pretty much straight-forward: The right-most simple selector is the one which get the declarations assigned that are defined in the ruleset.
These selectors define a certain hierarchy in your stylesheet.
Note: Please make sure to read Tab Atkins’ Reference for CSS Spec Terms.

An example

Today you would target some links in a navigation like this:

#nav ul li a { color: #000; }

If you’re smart and your markup allows you to do so, you may write:

#nav a { color: #000; }

The li-elements need to be inlined as you want a horizontal navigation:

#nav ul li { display: inline; }

Furthermore the navigation should be aligned on the right and all the links centered:

#nav ul { text-align: right; }
#nav ul li { text-align: center; }

This leaves us with a lot of repetition for the selectors.

#nav ul { text-align: right; }
#nav ul li { text-align: center; display: inline; }
#nav ul li a { color: #000; }

With the Level 3 proposal by Tab Atkins Jr and Shane Stephens (working for Google) this is about to get a little bit easier. The existing system will be extended with some new functionality. This is why it’s called Level 3. (Also it will likely be part of CSS 3 – and not 4 or 10 or something.)

What’s new in there?

Lately you saw the rise of CSS Preprocessors. Everyone has an opinion on this. The thing why so many developers use them is that they help to organize the CSS-code you are writing.
Preprocessors have brought up another idea of CSS hierarchies. And with the CSS Hierarchies Module Level 3 this has been adopted.

The specification draft allows you to nest your rules and use the &-character to reference a parent selector in a certain rule.

Here’s the example from above with the new hierarchy:

#nav ul {
    text-align: right;
    & li {
        text-align: center;
        display: inline;
        & a { color: #000; }
    }
}

As you can see there are no repetitions for the selectors as you can reference them by just writing & and nest them properly.

How can we use this today and when will it be ready for the “real world”?

As you may guess this is not implemented in any browser yet.

As this spec is written by two Google-guys it’s likely that this will be implemented in Chrome in the near future. At the moment this is not working with Chrome 19 (Canary) or WebKit Nightly.
I’ve made this Dabblet to check if the module is supported in a browser or not. caniuse.com does not provide any data for the Hierarchies Module yet.
Aside: Check my Dabblet Chrome App to view all your latest dabblets if you’re a Chrome user.

Tab Atkins proposed another style for nesting. To reference the parent selector you use @this instead of the &-character. Peter Beverloo wrote about this a year ago. Also Tab Atkins has an article about his further plans. This variant was not implement either and is replaced with the new draft for the specification. Anyway you could view the dabblet I’ve made for this propose.

Preprocessors

As mentioned above CSS preprocessors offer the chance to use something like hierarchies in there own way. Here are two examples:

SCSS (aka. SASS)

#nav ul {
    text-align: right;
    li {
        display: inline;
        a {
            color: #000;
            &:hover { color: gray; }
        }
    }
}

Stylus

#nav ul
    text-align right
    li
        display inline
        a
            color #000
            &:hover
                color grey

As you can see there is a difference in how preprocessors treat the &-character as a reference: In the CSS specification draft & is obligatory in every nested rule you write to reference the parent selector. Preprocessors need them only if there is a pseudo-class or -element or a combinator (such as ~ or >) used for a specific selector.

As I stated in the introduction it may happen that the specification will be changed until it becomes final or is adopted by the CSS Working Group. I recommend you follow the discussions about this topic in order to stay up to date.
When this specification will be implemented by one of the browser vendors it’s just a matter of weeks until it will be adopted by the others I guess.

But, as the draft states, this is not yet part of CSS:

This document is purely an Editor’s Draft. It has not yet been adopted by the Working Group, and should not be considered to be part of CSS.

~ CSS Hierarchies Module – Status

Opinion

Personally I hope that referencing the parent selector with & will not be in the final specification as it is now. It’s not needed as the rules are nested anyway and preprocessors nowadays treat them better.

Anyway the new nesting is pretty useful as it reduces the redundancy of writing selectors in CSS. In connection with other upcoming specifications like the CSS Variables Module Level 1 this is what is needed and will be helpful for every web-developer once it will be implemented in browsers.

Pseudo-Elements in Print-Styles for References in Links

This morning @t3node asked me about something CSS-related. This was kinda new for me because he never did this before I guess… He showed me a website he had printed and asked me to explain him, how it is possible to show links in printed websites with their reference printed next to it. He was kinda upset why not every frontend-developer includes this in his/her stylesheet when it comes to designing a new website. I wanted to explain everything that’s related to this topic that I’ve ever heard of but he asked me to write this blogpost as he is not pretty used to CSS and stuff.

Styles dedicated to print

To get this feature for a website you need to define some print styles.

1. link-Tag

It is possible to load up a stylesheet that is dedicated to server styles only for media print with

<link rel="stylesheet" href="css/some-print-styles.css" media="print">

Where media="print" is the important part here as it tells the browser to apply all styles it contains only for print-views of the website. I do not recommend this method because of some drawbacks for performace:

  • The client has to load the CSS-file even if it does not need it
  • This implies another HTTP-request
  • Even though it is not a lot: the browser needs to render the styles

2. @import in CSS-file

Another possible way to render styles only in print is to include a file with @import url("some-print-styles.css") print. This also has drawbacks on performance. Even more as the link-method as files get blocked for downloading in your browser if @importis used.

3. Inline styles

For inline styles it is also possible to define an attribute media.

<style media="print">
  .element {…}
</style>

4. Media queries

My favorite method to include styles for print are media-queries. It is possible to add styles for print via @media print. Maybe you are familiar with this because of media-queries dedicated to mobile devices. Once you’ve set up this environment you can start adding some styles for any print of your site. I recommend to add display: none;for elements that are not pretty important in a printed-version. This could be the sidebar and the footer or the navigation. The thing why I’m originally writing this is how to include the reference of a link in a printed version of a website. So I’m just going for it. It is just one pretty little rule!

Pseudo-Elements for generated content

A good use-case for pseudo-elements:

a[href]:after {
  content: " (" attr(href) ")";
}

a[href] selects all links with the attribute href set and creates content :after it. attr(href) tells the browser to use this attribute as content. You may want to select a little bit different as you don’t want to display references in the navigation or so for instance. HTML5 Boilerplate makes use of this, too. These little features are why I love it so much. Go check it out and contribute. Chris Coyier has a pretty awesome article, tutorial and demo at CSS-Tricks which has nothing to do with print but describes the use of pseudo-elements and contentreally good. You should definitely read this.

Browsersupport

@media print is supported in all browsers for what I know. Except Internet Explorer 7 every browser supports :after at least good enough that content works with it. The bottleneck here seems to be attr(href). As I researched this it turned out that generated content with attr() is valid CSS 2.1. The spec adds a warningon this vary topic:

In CSS 2.1, it is not possible to refer to attribute values for other elements than the subject of the selector.

You will find more information on attr() in the CSS3 Specification. It seems as every browser (that is actually used) is going to support this except IE7 and below. I’ve set up this demo so you can test it in your favorite browser and edit it yourself. I would be glad if you share your results and thoughts on this topic in the comments.

Conclusion

As it turns out it’s kind of the right to support straightforward things. I believe everybody could at least add some default styles for print to a new website like HTML5 Boilerplate does by default. The little trick with pseudo-elements can also be pretty useful for other elements like abbr aso. Later on I noticed that @t3nodes website does not support this feature for print either. Maybe it will after he has read this post. My website and this blog do not make any special use of printed styles as I think it is not necessary that anyone prints out my blogposts. I don’t like to print thinks for myself as I believe that you could save some paper in regards to environment. But this is your decision – or the one of your customer.   Edit Thanks to Nicolas for his hint about the difference between pseudo-elements and pseudo-classes. You should also consider using ::after instead of :after. But be aware that IE8 does not support this.