Posted on

Debugging SASS in Chrome

In Firefox, viewing the original SASS line number directly has been possible using Firebug and FireSass. Similar, or even better functionality has very recently arrived in the stable release of Chrome. I just tried this out and it works wonderfully. See here for instructions:

How to make Chrome understand the SASS/SCSS in your rails app

Don’t worry about the Rails stuff, these instructions work just as well for stand-alone SASS. If you’re using Compass like me, you need to set sass_options = {:debug_info => true} in the config.rb file of your project.

If you look at your css files after doing the above, you’ll see they are quite a mess. From a comment by Paul Irish in the above post I learnt better stuff is on its way thanks to the upcoming SASS 3.3, and Source Map support in Chrome:

Debugging SASS with Source Maps

Exciting times!

Posted on

SASS, LESS and nesting overload

Both SASS and LESS are really nice tools for CSS developers. Both have the ability to nest selectors like this:


#header {
   h1 { font-size: 3em }
   p { font-size: 1.2em }
}

…which compiles to 


#wrapper h1 { font-size: 3em }
#wrapper p { font-size: 1.2em }

Nesting is really useful, just don’t go more than 2-3 levels deep. I’m currently wading through a bunch of code which was generated from LESS files, and the (huge) stylesheet is full of selectors like this:


html body #wrapper #header #access div.menu-header ul.menu li.menu-item-home.current-page-item a:link { ... }

You have been warned!

Posted on

On Pragmatic Responsive Design

Responsive design shouldn’t be just about checking screen width and removing stuff on mobile devices, even though this is what it often amounts to. I also admit to doing this myself. Designing with a mobile first approach is sensible, but we run into problems with the typical wireframes/photoshop/html pixel-perfect workflow.

Stephanie Rieger made this excellent presentation on pragmatic responsive design with lots of good points.

You should check out her other presentations too.

Continue reading “On Pragmatic Responsive Design”

Posted on

Committing to Good Markup

Solid, semantic and accessible HTML markup matters. When most people look at a web page, it doesn’t make much difference to them whether headings are coded with proper <h1> and <h1> tags or <span style="font-size: 20px">. Still, for someone using a screen reader, not to mention search engines and feed readers, it can make all the difference in making sense of a document. Luckily this specific issue is now rare, but in a world of plugins and cool themes that generate semi-adequate markup, we’re often not using HTML and CSS to their full potential in building solid, accessible and search engine friendly sites.

By we I mean me of course. WordPress is awesome, and it’s one of the few CMS’s around that has committed to accessibility on the admin end (I’m not saying it couldn’t be improved). Unfortunately tight schedules and the very fact that its so easy to whip up a site using a few plugins and occasionally ready-made themes means its very tempting to be lazy.

So here goes: I hereby promise to continue to build usable sites, with a renewed commitment to good semantic and accessible markup. Because the web should be for everyone (and there’s nothing like some sweet, elegant HTML is there?).

Posted on

Flexible fluid layouts with CSS and jQuery (Part 2 in series)

2012 Update: This techniques outlined here have been mostly outdated by CSS3 Media Queries, which I recommend using instead.

This is a follow-up to last week’s post, Should we design for wider screens?. In this post I’ll demonstrate with a simple example how easy it is, with CSS and a bit of jQuery, to make layouts that adapt to the many different screen sizes out there.

Example HTML

At the top level, my example HTML page has a #wrapper div, which contains a #header, #main div containing all the interesting stuff, and a #footer. The main section has #content, #primary, #secondary and #tertiary divs for the different content areas of my page. The first two content areas, #content and #primary are wrapped up in an additional #container div, but your own markup may obviously differ.

Prepare your styles

The basic idea here is to have different CSS styles for each width. The styles could be changed directly through jQuery, but that would quickly result in a lot of messy code. Instead, we’ll use jQuery only to change one class attribute. Initially I’ve added the class ‘normal’ to the body element to ensure a sensible default for browsers with JavaScript disabled, but we’ll also need styles for ‘wide’, ‘slim’ and ‘narrow’. This is easy to do with CSS descendant selectors:

Unfortunately versions 7 and older of Internet Explorer deal differently with percentage widths compared to most other browsers, and can result in some funny behaviour. I see two primary ways to deal with it: either feed IE 6 and 7 it’s own rules (e.g. a tested, fixed-width layout) or just make sure that the percentages never add up to 100 %. A nice explanation of this annoying feature can be found over at OJTech.com.

The jQuery

First of all I need to include jQuery, and perhaps the easiest way is to use Google’s jQuery for this. The main bit is a function, checkWidth() that (you guessed it) checks the width of the browser window and sets the body class attribute accordingly. The code below should be pretty self-explanatory.

In addition to this, all I need is some code that will tell the browser when to run the checkWidth() function.

That’s it! View the finished demo EDIT: I’ve managed to lose the demo at some point in time. Anyway a better and more flexible way of doing this is CSS3 Media Queries, and you should use them.

After starting to write this post, I read the latest issue (#200) of .net magazine and noticed a mention of a very cool way to do a similar trick using only CSS media queries! Media Query demo by Bruce Lawson. Haven’t tried it out yet, but I definitely will.

Hope you liked the post, feel free to tweet it, or leave a comment below.