<br /> doesn’t kill kittens

Not dead

I’m a backend developer, as (scarily) are all the developers that make up Icy Cow.  However, we’re making some web apps, and traditionally web apps have some kind of… er… bit you can see.  So I guess we’ll have to start writing more HTML and CSS than we’re used to.

I’m generally terrified of making changes to other people’s CSS.  I worry about making one tiny change to a font size or line height, and totally destroying the layout in some other, unseen, part of the site, or blowing up some archaic browser.

I don’t get the same sense of panic when maintaining python code.  Of CSS, I often find myself thinking “it shouldn’t be this fragile”.  Am I missing something?  Are there principles of software engineering that we can use to make scary CSS side-effects less likely?

When you’ve been writing software for a while, you realise that things like elegance, brevity, maintainability, optimisation and JFDI sometimes drag you in opposing directions.  You constantly have to make judgement calls about what’s most important for the bit of code you’re currently working on, the current and future system requirements, and the overall needs of the business.

Real frontend developers (rather than python hackers who dabble in it when forced) don’t seem to like this wishy-washy approach to the rules.  “You must not use inline styles.  Extraneous markup is evil. Every time you use a <br/>, a kitten dies.”

But since I’m not a real frontend developer, here are some of the cardinal sins that I’ve been committing – and why I’m not so sure they’re as evil as people say:

Inline styles: Just like inline code.  If you only use it once, and it’s only a small amount of styling, why can’t you just put it on the bit of markup it affects?  It’s much less effort to maintain and you don’t need to worry about side effects.  If you use it more than once, or need to style it in different ways for different browsers, then obviously refactor and put it into the stylesheet, just like making a function for code reuse.

Extraneous markup: Sometimes a few bytes of extra html can make everything so much less scary.  “You must not have markup that only exists to make your styling easier”.  Why not?  I’d much rather bung in an extra div than mangle some unsuspecting fieldset legend (or, heaven forbid, a definition list) in some way it was never intended to be used, and is almost certainly going to break in IE6.  Yes I can see why it’s “elegant” to apply all your styling to the markup that’s already there, but it’s a lot of heartache just to show off to people who happen to View Source on your page.

<strong>:  Why do people normalize this back to nothing, as if to punish you for using it? (Actually I could have a whole other rant about CSS reset/normalisation, but that’s for another time.) Anyway, <strong> is nice and sematically meaningful. <span class=”strong”> means nothing to web crawlers or assistive technologies.  I haven’t had the pleasure of listening to Jaws saying “I <strong>love</strong> you Jess”, but I’d like to think it would sound much more sincere with the right markup.

Line breaks: sometimes you don’t want to put your text into a paragraph, or make a div with its own special class and open up your stylesheet and put in some margins, and then test it across all possible browsers to make sure the margin is identical in Chrome and IE 5.5 and doesn’t get ignored in weird floaty edge cases.  Sometimes you JUST WANT A FRIGGING GAP UNDERNEATH IT.  And yes, sometimes I even put a &nbsp; after it, just to make sure.

So there you have it.  I’m happy to hear arguments from people more experienced than me in the ways of the useragent, and I might even change my mind, but only if the argument is more solid than just “Them’s the rules”.