One of the advantages of the new tableless layout at microhowto.info is that it is now significantly easier to remove unnecessary elements from the page when it is printed. I think this looks better, and it certainly saves paper compared to the alternative of printing everything.

This is something I has previously implemented on codepolice.org using an HTML link element, but since traffic to the MicroHOWTO site is higher by a factor of 50 I wanted to check whether this is actually the best method.

It turns out that in terms of efficiency it probably isn’t, especially when the number of print-specific rules is small. Zoompf have a good explanation of the issues on their website (Browser Performance Problem with CSS "print" Media Type). In short, most if not all current web browsers download any print-specific CSS rules whether or not they are needed immediately, so placing them in a separate stylesheet merely increases the number of HTTP requests needed.

I didn’t like the idea of using JavaScript to load the rules because I strongly believe that users should be able to turn off scripting without penalty unless there is a compelling reason why it is needed. In this case the consequences are not too serious, but it still qualifies as an unnecessary and easily avoidable reliance on JavaScript.

I’ve written up three of the other possible methods — @media, <link> and @import — as a microHOWTO (Hide part of an HTML or XHTML document when it is printed), with some notes about their pros and cons. Both microhowto.info and codepolice.org have been altered to use single stylesheets with @media rules.

While preparing to launch the microHOWTO website last year my main priority was content creation. Appearance was not neglected entirely, but there was a limit to how much time could be justified on aesthetic considerations when the site was small and likely to have few visitors in its early days. What I did instead was ensure that the style and layout could very easily be changed at a later date without altering the content. This was achieved using an XSLT stylesheet to transform the content from XML to HTML, then using CSS to further style the content.
Since then the site has grown considerably and attracted a respectable amount of traffic. Because the style affect the usability of the whole site, a little extra effort now goes much further. A further consideration was that the topic-based index pages, which had been adequate enough for a few tens of pages, was not going to cope well with hundreds. I therefore decided it was time to review the design and look for opportunities for improvement.
As when writing software, I prefer to make changes to the site in small steps where possible so that any adverse effects (such as drops in traffic) can be more easily traced to their cause. My two objectives for the first stage of the redesign were to:

• avoid the use of tables for page-level layout; and
• prevent lines from becoming unreadably long when displayed in a wide viewport;

Both of these have now been achieved. The new layout is fluid for moderate viewport widths, but it will not allow the line length to expand beyond 60em or contract to less than 30em. (The trick needed to make it work was to set a negative left margin on the sidebar wrapper.) I'm not completely satisfied with the result yet, because in some tests the content came out about 30% wider than I would have wished, but even so it is a definite improvement on having lines of unlimited length.
Other planned improvements are to: