This month was a very special meetup for London Web Standards – it’s 5th birthday celebrations! Yes, it’s hard to believe that 5 years ago in October three guys met up in a North London pub to talk about the web. To celebrate this momentous occasion, Imogen Levy baked us a massive 7-layer London Web Standards Cake (British Bake-off contender next year 2013 for sure). Imogen, thank you so much (from all of the LWS Organisers)!
It was also a big LWS for me personally, as I took the stage to talk about a pet topic of mine: Less, Sass and CSS Pre-processors. Gotta say, I had a lot of fun and got some really great questions and comments from the audience. I’ll definitely do it again.
So, the sketchnotes service is at half capacity today, it being quite hard to do sketchnotes of my own talk. The notes this month are of Peter Gasston’s talk on The CSS of Tomorrow, covering future specs that will bring some of the features from Less/Sass to CSS, and hugely improve the way we layout websites (finally!).
My Sketchnotes from Peter’s Talk
The CSS of Tomorrow – Peter Gasston
Thanks again to everyone involved, we truly celebrated LWS’s birthday in style.
My CSS bookshelf is now available on github as an easy download if you want one yourself. Given that the code is now 2 years old it’s showing its age somewhat, so I’ll give it a spruce up over the next few weeks. Things like:
- Removing the jQuery dependency (as I know a lot more JS now)
- Using a CSS pre-processor on the stylesheet
- Adding CSS gradients for the spines of the books, because there’s no need for images for most of them
Take a look at the project and let me know what you think in the comments
Simple premise: web sites are designed for the screen, they are meant to be viewed through a computer and that’s about it. Still, most people want to print out a web site at some point and your design probably won’t look very good. Print media strips out all backgrounds and forces a page width so large fixed width sites simply won’t print all their detail.
The simple answer to this is print stylesheets using the media=”print” or @media print options. This is covered in great detail all over the web, and so the basics of print stylesheets won’t be told here. What I’m going to cover is how best to debug those print styles so that you can quickly edit and get a good print stylesheet together.
Why can’t I see you!
My number one issue with debugging print styles is having to use print preview to show what the effects of a print stylesheet will look like. It can take a long time for older browsers (IE6) to render print previews and it’s just not necessary.
Simple remedy: when debugging, make your print stylesheets media=”all” to see live previews of what the effects are.
This isn’t ideal, especially if you’re debugging on a live site (though if you are, you really should get a development environment). So, thankfully, there is an alternative, in the form of the Firefox Web Developer toolbar.
In the image above, I’m using the web developer toolbar to display my print styles, reducing my web page to what print preview will see. You should also tick the “persist features” option or you’ll have to keep turning the print stylesheet on each time you visit the page.
This technique has additional benefits, in that Firebug, the web developer’s best friend, picks up the print styles as if they were the only ones available. This allows you to experiment with the stylesheet on the fly, speeding up development time.
What about IE?
Due to the unique way that most developers are funded, you will still have to deal with Internet Explorer. IE 8 is pretty good at print styles, using the “fit to width” option by default, which gets around most of the awkward layout problems. However, IE 6 doesn’t have this facility, so layouts often go wrong. Here’s a few workarounds for common problems:
Make yourself an IE 6 only stylesheet. In the spirit of graceful degradation, use conditional comments to target the offending browser with its own stylesheet. This allows you to target IE6’s inflexible width issue without damaging the other stylesheets. Put something like this in your site:
Make all your IE 6 specific changes in this file. As with the first technique, you may want to change the media to “all” to see what happens without using print preview.
My content goes off the page (to the right generally) and doesn’t come back
With a print page in portrait mode, you only get about 70% of the screen space. In this case, content simply overflows off the page and can’t be retrieved. Instructing your users to print in portrait mode alleviates this a little, but isn’t ideal for most clients.
If you have a fixed width layout, start by changing all of these pixel values into percentages. IE printing responds quite well to this in both landscape and portrait. If this doesn’t have the desired effect, consider removing and floated columns that you may have, allowing the sections to naturally flow beneath each other. Whilst this isn’t ideal, it can prevent content loss.
There’s a blank page in my printing / nothing appears when I go to print preview
This is an odd one. This can be caused by improperly clearing floated elements, so check those out. A good way to debug this is to turn off any custom styles that you’ve added (i.e. make sure your main stylesheet is set to screen, or comment it out) and see if the content prints. If it does, build your stylesheet back up until you find the problem.
If you still don’t see anything, it’s likely there is an in-line style causing the issue. SharePoint has tendency to add “height: 100%” to a few elements, which to most browsers means absolutely nothing, but IE6 takes seriously. Set that to “height: auto;” and you should get all of your content back again.
I’ve got some VML (IE’s Canvas implementation) that I need to hide but can’t
Sad news here, I don’t believe you can hide it in print stylesheets. If anyone knows how to do this, please let me know.
Don’t forget: printing is about the content
A printed page doesn’t have to look beautiful, with rounded corner borders or large images; the content should be laid out simply and should flow correctly. Use these techniques to get that right and all your print styling headaches will go away.
CSS has gone through many trends and phases in web development. Certain trends are welcome, like conditional stylesheets and developers refusing to do them for Internet Explorer 6. Other trends can have leave a web application with a disadvantage for the rest of its life, yes, in-line styles, I’m looking at you.
This is all well and good, people learn from their mistakes and in the end, best practice comes out. The latest trend seems to have brought us full-circle.
About a year ago, HTML was plagued by a trend known as divitis (div-eye-tiss), a syndrome where a web page was seemingly marked up entirely in <div> tags, making a mess of the markup and producing un-readable pages. This was mainly produced by new web developers who had just moved away from the safety of table-based design and into the world of web standards and can be easily remedied with some education on elements other than <div> and <br/>.
This disease now seems to have mutated and crossed over to CSS in a trend I’m calling classitis (class-eye-tiss). It’s easy to diagnose: the first sign is in the HTML. Look closely at each element, it may have a class attached to it. If it does, does the one above have the same one? If this repeats all over the page, you may have classitis. In the navigation of your site, do all the list items have the same class name? You may have classitis. The way to tell for sure is to dive into the CSS: If the styles are predominately classes (i.e. are “.className”) with ancestor selectors being few and far between, then you have classitis.
The root cause of such a syndrome relates to modern web programming languages, notably ASP .NET. I’ll try to explain:
ASP has a number of helpful server-controlled elements which when processed turn into regular HTML elements. These all have their own unique identifier, but this is the reference for the server, not for CSS. Therefore, each of these elements can have a CSS class applied to it, and developers use this constantly. The real kicker is that ASP encourages you to use its own controls rather than standard HTML elements, making this disease especially prevalent amongst users of ASP. What makes this even worse is that ASP has been the default option for enterprise level applications for a while now, and Microsoft have made ASP accessible to new users with the Express editions of Visual Studio. It’s now easier than ever to start coding badly.
Is classitis really that bad? Well, no, but it’s what it comes with that can cause problems. A recent web site template that I was given by a company that shall remain nameless, was riddled with classisits, even so far as that there was an individual class for each font type and size. Surely setting a single class for the body would be easier and using ancestor selectors after that would provide for simpler HTML. The real problem here is maintainability: my task was to add another page which used a three-column layout rather than their two-column one. I’ve ended up duplicating their code to make my new layout fit, even then, changes made to their stylesheet won’t be reflected in my layout.
It’s a sorry state of affairs, but the remedy is simple, learn to use HTML elements properly. Some developers seem to forget that <html> and <body> are tags like all the rest and can be used to dictate the styles of the whole page. For users of frameworks like ASP, remembering that there are more elements than the ones the framework provides is very important; though don’t rely on the visual designer. Classitis is curable, and education on its prevention is important. Lets hope it’s caught before it becomes a pandemic.