Welcome to CSS Wizardry—Web standards design and development

When using IDs can be a pain in the class…

11th September, 2011 in Web Development

There have been a few articles flying about lately which tell you never to use IDs in CSS selectors. I always get a little concerned when articles like this command rather than advise, they often neglect to take into account context and necessity. I’m going to try and offer up one decent reason here as to why IDs might trip you up unnecessarily (and how you can avoid the pitfalls).

ID selectors are fine, valid and perfect for styling unique parts of pages. They’re HTML/CSS basics, you can use one ID per page and style the relevant element with #the-id-you-chose.

IDs, as well as being non-reusable, carry quite a high specificity, take the following:

<p id="intro" class="excerpt">Lorem</p>

#intro{ color:blue; }
.excerpt{ color:green }
p{ color:red; }

Even though we define #intro first—thus expecting it to be overwritten by subsequent matching selectors—it still takes precedence over any other rules. This is the IDs heightened specificity, and this is where you can come unstuck…

Reusability

One argument against using IDs is that they can’t be reused, but to my mind this is a weak argument. The whole point of using an ID is that it’s unique; if you want to reuse something you’d use a class. Developers know this, developers aren’t stupid so to tell them not to use an ID because it’s not reusable is, in my opinion, quite patronising.

Also, some things just can’t be reused. Some designs would be wholly impossible to have, say, two content areas in. You couldn’t reuse that even if you wanted to.

Wild card

That is wild card meaning a person or thing whose influence is unpredictable or whose qualities are uncertain and not to be confused with the CSS wildcard selector (*{}).

One of the main and, in my opinion, most valid arguments against using IDs is that they can introduce specificity headaches where you want them least, and it can be a total nightmare fighting your way back out.

Using an ID in a selector instantly adds a specificity wild card (note, not wildcard), and you might not want this effect. It is, in a way, similar to !important; it is a trump card that will override nigh on all other types of selector. You probably don’t always want this.

The best way to illustrate this is with a specific example.

Let’s imagine you’re building a site and one of the requirements is to have a reusable Twitter widget that needs to be placable wherever the client chooses. Let’s for example say they want to kick things off with having the widget in the header and also in-page, at the bottom of an article. The Twitter widget’s styling must remain consistent.

So, let’s look at some example code.

Here we can see that we have a small specificity problem, the #header a rule has a lot higher specificity than .tweet a and therefore the links in the widget adopt the header’s (unreadable) colour. Remember that the Twitter widget’s styling must always remain the same so this is not ideal whatsoever.

We can work around this by adding a new selector to the .tweet a rule Or, even worse, we could add an !important to the relevant declaration. Shudder…

Now, you don’t need me to tell you that this is far from a nice solution, as soon as that widget gets put in the #footer we may well have to add yet another selector, which will prove a maintainability nightmare. This is not a very future-proof fix.

This is where using IDs can be a pain for you, where a specificity trump is introduced.

A better fix: add a class instead of (or as well as) the ID on that header div, thus: http://jsfiddle.net/csswizardry/gTZGq/3/

That now brings the specificity gap way down to, well, zero. Removing the ID means that you now don’t have to fight yourself out of a self-induced specificity war.

I did mention that you can add a class as well as the ID or remove the ID completely. It depends…

Remove IDs completely?

We’ve covered where IDs can trip us up and be but they serve a purpose other than style-hooks; they can be used as fragment identifiers for marking landmarks in the page.

I’m sure you’ve seen ‘Skip to navigation’ or ‘Jump to content’ links in pages, and these wouldn’t work without our IDs so we need to keep those in as well as adding our new class.

So, as is the case with most development conundrums, it’s all about context. You know your context better than I, or anyone else does, so don’t let anyone else tell you what to do. If you want to keep an ID for completeness or for fragment identifiers then do, it’s totally your call.

Final word

So yeah, IDs aren’t evil, they’re perfectly valid and a blanket ban on them is stupid. Use your own knowledge and context of the project to use the most suitable and sensible solution.

Don’t stop using IDs, just be aware of where they can cause you headaches and know where to sensibly circumvent them. Anyone telling you not to use them at all is not wrong, but they’re definitely not right…

By Harry Roberts in Web Development. Tags: , | 25 Comments »

Two titillating table tips

24th August, 2011 in Web Development

Yesterday I was taught two awesome little <table> tips from two friends, Steve Melrose and Jon ‘Barry Crayon’ Cotton. I can’t believe I never knew about these two, they’re so simple but really cool*

*The tips are simple, not Steve and Jon.

The first, which Steve alerted me to, is colspan="0" and rowspan="0" which basically just makes the cell (<td>/<th>) to which it is applied span all the columns/rows between itself and the end/bottom of the table respectively.

I tweeted about how cool this was when Jon replied with info about colspan="100%"/rowspan="100%" which is similar to the above but instead of meaning ‘the rest of’ it just means ‘all of’. This is great if you want a cell to always span the whole width/height of a table but you don’t always know how large that table will be.

See my fiddle!

As far as I can tell Firefox is the only browser that supports [col|row]span="0" but all browsers seem to support [col|row]span="100%". I’ve not been able to do any more thorough browser testing but if anyone can feed back that’d be great!

By Harry Roberts in Web Development. Tags: , | 2 Comments »

Building better grid systems

23rd August, 2011 in Web Development

With every grid system that gets released—and there are a lot now—I notice the same issue with nigh on every one of them; handling the extra margin/gutter on the last <div>.

N.B. This post is about the HTML and CSS that powers grid systems, rather than the columns, construct, system and layout itself.

The problem

If you have a grid system where each grid module is defined with a class of, say, .grid, you might have some CSS like this:

.row{
  width:940px;
  overflow:hidden; This is just for brevity. Please use a better clearfix: http://nicolasgallagher.com/micro-clearfix-hack/
  clear:both;
}
.grid{
  float:left;
  margin-right:20px;
}
...
.col-4{
  width:220px;
}
...

The most important thing to note is that every .grid has a margin-right of 20px, so—in a 16 column 940px grid system—4 × .col-4 actually equals 960px (4 × (220px + 20px)). This is 20px (or one margin) bigger than your wrapper.

The formula for a complete system is:

f = n(c) + n-1(g)

Where:

Basically, a full row comprises of n columns and n-1 gutters; we want one less gutter than we have columns. We need to lose a gutter somehow.

The current solution(s)

The simplest and most common solution is to use a class of .last or .end on the last or end grid column to remove its margin:

.end{
  margin:0;
}

This would give us:

<div class="row">

  <div class="grid col-4">
    <p>One box plus one gutter</p>
  </div>

  <div class="grid col-4">
    <p>One box plus one gutter</p>
  </div>

  <div class="grid col-4">
    <p>One box plus one gutter</p>
  </div>

  <div class="grid col-4 end">
    <p>One box only</p>
  </div>

</div>

This solves the problem, but it means the developer has to remember to add that class every time they construct a row of grids.

Another problem is that if a programmer needs to dynamically display, say, a series of images in a grid system, they need to do some scripting to say ‘if this is the x column then add a class of .end’. Not a massive overhead, but an overhead nonetheless.

The other current solution

Another solution I’ve seen recently is used on Twitter’s Bootstrap framework and a few other places. This solution is a little more elegant, but still not very robust.

It works by removing the margin-right:20px; from .grid and applying it as a margin-left instead. Then—using the dynamic :first-child pseudo-selector (:first-child is used as it has better browser support than :last-child)—you can target the first div in a row and remove its margin, thus:

.grid:first-child{
  margin:0;
}

This keeps your markup clean as you don’t have to include the special class and also means your devs don’t have to take the extra class into consideration, However, this is not without its own problems…

The smallest problem with using this method is that the :first-child selector is quite an inefficient one, but selector performance is another post for another time.

The most significant drawback is that :first-child only ever matches one grid in the row, meaning you can’t have multiple-row grid constructions. Take the following (crude) representations…

:first-child works out fine here as we only have a one-row-deep layout. The first div is the only flush-left div:

+~~~~~~~~~~~~~~~~~~~~~~~~~+
¦ +---+ +---+ +---+ +---+ ¦
¦ | x | |   | |   | |   | ¦
¦ +---+ +---+ +---+ +---+ ¦
+~~~~~~~~~~~~~~~~~~~~~~~~~+

In this following example however, :first-child will not work as intended as there are two flush-left divs but only one of them is the first child. This is where this method breaks, and more-than-one-row-deep layouts are not uncommon:

+~~~~~~~~~~~~~~~~~~~~~~~~~+
¦ +---+ +---+ +---+ +---+ ¦
¦ | x | |   | |   | |   | ¦
¦ +---+ +---+ +---+ +---+ ¦
¦ +---+ +---+ +---+ +---+ ¦
¦ | ! | | ! | | ! | | ! | ¦
¦ +---+ +---+ +---+ +---+ ¦
+~~~~~~~~~~~~~~~~~~~~~~~~~+

So :first-child kinda works, but not well enough. The solution…?

The solution

In short, the solution is to not remove that extra margin, but to hide the effects of it.

Essentially the real problem is that the combined width of a full row is one gutter wider than our container, right? Well what we need to do is make our container one gutter wider but disguise the extra width by using a negative margin equal to one gutter.

This can be a bit of a headf**k so bear with me. What we need to do is apply the gutter as a margin-left on the .grid, as Twitter do, but we’re not going to remove any of them. No pseudo-classes, no special classes, nothing. It’s gonna stay there.

We can hide the effects/breakage caused by the extra gutter by giving the container .row a width of all the columns and gutters combined and then a negative margin-left equal to one gutter to pull everything back across again, soaking up the effects of the margin-left.

Our 940px .row now becomes 960px wide to allow for the fact we are no longer removing the end gutter, then we pull it all back over by 20px to remove the visual effects of that extra width, thus:

.row{
  width:960px;
  margin-left:-20px;
  overflow:hidden;
  clear:both;
}
.grid{
  float:left;
  margin-left:20px;
}
...
.col-4{
  width:220px;
}
...

This way we can have multiple-row constructions and never have to remember the special .end/.last classes.

To see this technique in action head on over to inuit.css and poke about the page’s grid system using Firebug or similar. It’s most apparent in the list of features…

Roll your own…

To transfer this technique, you only need to know three things:

With these, your formula is simply:

.row{
  width: (number of columns * width of one column) + (number of columns * width of one gutter) px;
  margin-left: -width of one gutter px;
  overflow:hidden;
  clear:both;
}
.grid{
  float:left;
  margin-left: width of one gutter px;
}

So let’s create one using 12 columns that are 50px wide with a gutter of 25px:

.row{
  width:900px;
  margin-left:-25px;
  overflow:hidden;
  clear:both;
}
.grid{
  float:left;
  margin-left:25px;
}

Plugging in our numbers gives us a grid system that doesn’t require special classes, is totally flexible (you can move columns without needing to move a class around), and gives you more varied layouts (multiple rows).

I employ this technique on both inuit.css and Fluid Grids and it’s proved perfect so far. Robust, portable and lean.

By Harry Roberts in Web Development. Tags: , , | 20 Comments »

Good developers are illusionists

18th August, 2011 in Web Development

A major part of being a good developer is efficiency. Not just with efficient code, but efficiency in making your life easier, being cleverly lazy, and making code do the hard work for you.

A good way to be efficient is through illusion. A great example of this is faux columns; overcoming a complex problem with minimal code and a clever illusion. Faux columns is still, today, one of the best little bits of web development illusion which quickly solves a problem that would otherwise take a lot of time and markup. Illusion is efficiency.

Another practical example of this is something I helped someone out with recently and have actually built myself for use at work. I’m sure we’ve all seen search forms laid out like this before:

Incorrect structure

What we have here is a search button laid over the top of our text input. Or do we…?

If we were to use just <input type="text"> and <input type="image"> to achieve this effect here we’d need to use some positioning to move the button over the search field, possibly some z-index, some big paddings to stop text going underneath the button and, more than likely, a lot of hard-coded numbers, cross-browser issues and headaches.

Enter the magic of illusion. Here’s how I tackled that problem:

Correct structure

Instead of trying to make two sibling elements appear as though one contains the others, why not spoof the effect with an element that does contain it; the <fieldset>?

If that doesn’t make sense, I’ve made a demo of this on jsFiddle as well as hosting the code. Be sure to pick through it with Firebug or similar to actually get what’s going on.

This method works perfectly in IE7+ (not checked IE6, but nor have I walked my dinosaur today) and all other browsers.

<!-- HTML -->
<form id="search-form" action="#">
    <fieldset>
        <legend class="accessibility">Search our archives</legend>
        <label for="search" class="accessibility">Search terms</label>
        <input id="search" placeholder="Keywords&hellip;" type="text">
        <input id="btn" type="image" src="http://dl.dropbox.com/u/2629908/misc/search.png" alt="Search">
    </fieldset>
</form>

/* CSS */
.accessibility{
    position:absolute;
    left:-9999px;
}

/* Form */
fieldset{
    padding:0;
    width:275px;
    border:1px solid #4885d8;
    background:rgba(0,0,0,0.25);

    -moz-border-radius:4px;
    -webkit-border-radius:4px;
    border-radius:4px;
    -moz-box-shadow:0 0 10px rgba(0,0,0,0.75) inset;
    -webkit-box-shadow:0 0 10px rgba(0,0,0,0.75) inset;
    box-shadow:0 0 10px rgba(0,0,0,0.75) inset;
}
input{
    font-size:1em;
}
#search,
#btn{
    float:left; /* Make the fieldset hug the inputs */
    cursor:pointer;
}
#search{
    width:200px;
    padding:15px;
    background:none;
    border:none;
    color:#fff;
}
#search:active,
#search:focus{
    outline:none;
    cursor:text;
}
#btn{
    float:right;
    position:relative;
    top:9px; /* Some unfortunate hard-coded numbers, but these will need setting/altering accordingly. */
    right:9px;
    width:32px; /* Same width and height as original image file. */
    height:32px;
}

We’re building a form, we have <fieldset>s and other great little semantic elements all over the place. Let’s put these to work and achieve this effect with some illusion… Why wrestle the button and input to sit awkwardly when you have a wrapper already there with the <fieldset>?

Be clever, use illusion to create the desired look using other, more robust elements. Think outside the box and see where other elements/bits of markup can be used to make a more sturdy build and make your life easier.

Any more good examples of this kind of thing that anyone’s built? Let me know!

By Harry Roberts in Web Development. Tags: , | 9 Comments »

Updated CV

8th August, 2011 in Personal

Last week I got round to updating my CV, adding on my new job at Sky. I decided to take the opportunity to do something a little different with it this time round.

Being a web developer, with a strong focus on CSS, I chose to make the CV relevant by writing it as (obviously made-up/invalid) CSS.

Initially I actually just wrote everything out in one giant <pre> with <span>s just for colouring in, a little like this:

<pre>
/*------------------------------------*\
    PERSONAL
\*------------------------------------*/
#me{
    name:"Harry Roberts", Harry;
    age:21years;
}
...
...
</pre>

So far in I thought that that seemed a little too easy/lazy, and it also came with the massive issue of not being semantic, meaningful or just plain proper markup. A CV is a series of headings and lists, not a single block of preformatted text.

I got to work rewriting, refactoring and tidying and marked it all up properly, and moved any braces, comments and quotes etc out of the HTML and into the CSS making massive use of the content:; property.

The resulting document is a semantically sound, properly marked up CV that is transformed into a CSSesque appearance using, well, CSS.

CSS is so humbly powerful…

So, what does anyone think? Good idea? Too novelty? Seen any other cool developer CVs?

N.B. it may be worth noting that even though I’ve updated my CV, I’m not looking for a new job.

By Harry Roberts in Personal. Tags: , , | 11 Comments »

Hi there, I am Harry Roberts. I am a 21 year old web developer from the UK. I Tweet and write about web standards, typography, best practices and everything in between. You should browse and search my archives and follow me on Twitter, 7,791 people do.

via Ad Packs