Extending colborder in Blueprint CSS

Blueprint

For the last few months, when time has allowed, I’ve been working on a new CSS framework combining my favourite elements from Blueprint CSS framework and 960 Grid System but this week I ran into a problem.

I’m developing the adapted framework to use when I redesign my website later this year. When it’s completed I will also make it publicly available on my website to whoever wants to use it and adapt it.

This is what I want

On Friday night, while testing it, I spotted something about the original Blueprint framework that I hadn’t noticed before.

It was to do with the colborder rule. What if I want to do this:

12 columns of text

That is create two blocks of text, the first spanning six columns with two blank columns appended on the end, then a colborder (which as the name suggests is a border that span an entire column) and finally the second block of text which spans three columns.

Just to be clear, in this example I’m using an adapted Blueprint grid. The default grid uses 24 columns, but in this example I’m using 12 columns as fewer and wider columns make it easier to demonstrate what I’m talking about.

The code, I initially thought, would look like this:

45
46
47
48
49
50
51
52
53
<div id="column1" class="span-6 append-2 colborder">
  <h2>span-6 append-2 colborder</h2>
  <p>Lorem ipsum dolor sit amet, ... </p>
</div>
 
<div id="column2" class="span-3 last">
  <h3>span-3 last</h3>
  <p>Lorem ipsum dolor sit amet, ... </p>
</div>

My blank columns have disappeared

But testing this out, what this code actually gives you is this:

Six columns, a line, three columns

Hang on! Where are my two appended columns in the first block, the ones that should appear after the span-6 and before the colborder?

append-x and colborder don’t mix

To answer that I had to take a look at the Blueprint source code. As these three classes are to do with the layout grid these CSS rules span-6, append-2 and colborder are all defined in (my adapted) blueprint\src\grid.css:

58
59
60
.span-6 {
  width: 460px;
}
106
107
108
.append-2 {
  padding-right: 160px;
}
138
139
140
141
142
.colborder {
  padding-right: 49px;
  margin-right: 50px;
  border-right: 1px solid #eee;
}

So, in order:

  1. span-6 class is setting the width of the content to 460px.
  2. append-2 class is setting a padding-right of 160px.
  3. colborder is then overwriting padding-right with a width of 49px thereby making our appended two columns effectively disappear.

A new rule is required

I really wanted a solution that didn’t require any extra mark-up. Because I realised that this could be achieved with this code:

45
46
47
48
49
50
51
52
53
54
55
<div id="column1wrapper" class="span-8 colborder">
  <div id="column1" class="span-6 append-2">
    <h2>span-6 append-2</h2>
    <p>Lorem ipsum dolor sit amet, ... </p>
  </div>
</div>
 
<div id="column2" class="span-3 last">
  <h3>span-3 last</h3>
  <p>Lorem ipsum dolor sit amet, ... </p>
</div>

but that has an extra level of div tags.

After a little pondering, and a little scribbling on a scrap of paper, I realised that the solution lay in writing a new CSS rule that would prepend a colborder before the second block rather than append one after the first block.

In keeping with the append/prepend terminology of Blueprint I decided to call the new rule precolborder. The 12-columns version looks like this:

145
146
147
148
149
.precolborder {
  padding-left: 49px;
  margin-left: 29px;
  border-left: 1px solid #eee;
}

The 24-columns version (compatible with the default Blueprint CSS framework) looks like this:

165
166
167
168
169
170
171
/* Border with more whitespace on left hand side
    of a column, spans one column. */
.precolborder {
  padding-left: 24px;
  margin-left: 15px;
  border-left: 1px solid #eee;
}

and so our HTML now looks like this:

45
46
47
48
49
50
51
52
53
<div id="column1" class="span-6 append-2">
  <h2>span-6 colborder</h2>
  <p>Lorem ipsum dolor sit amet, ... </p>
</div>
 
<div id="column2" class="precolborder span-3 last">
  <h3>precolborder span-3 last</h3>
  <p>Lorem ipsum dolor sit amet, ... </p>
</div>

which looks like this on the rendered page:

Text spanning six columns, two blank columns, a border and then text spanning three columns

Which, if I’m not mistaken, is just what I wanted.

Feel free to use it if you like.

Why web standards matter

Screenshot of web code
Screenshot of web code, as viewed in the excellent Firebug add-on for Mozilla Firefox.

These last couple of weeks I’ve spent much of time, both at home and work, puzzling over a coding project I’m currently working on at the University; which is partly why my blogging activity has been more intermittent than usual.

Baseline browsers

For this particular project we set a baseline of which browsers we would support, based in part from the visitor information we gather on the University’s homepage. This collects information about which browsers are being used, the user’s screen resolution and the number of colours their computer will support; no personal information is gathered. Having examined this data we decided to support Safari (Mac OS X), Internet Explorer 6 and 7 (Windows), Mozilla Firefox (Windows, Mac and Linux) and Opera 9 (Windows, Mac and Linux).

What happens when you have to support IE6

That we have to support IE6 — because many of the PCs at the University run Windows 2000 which will not run the newer IE7 — has had a serious impact on our coding time. Here’s what happens on a typical day as I work through our specifications list:

  1. I spend maybe 30-60 minutes coding one particular aspect of the site, e.g. page layout, using standards-compliant CSS.
  2. I test it in Firefox 2 – it works.
  3. I test it in Opera 9 – it works.
  4. I test it (by sending the code to colleagues) in Safari and Linux Konqueror – it works
  5. I test it in IE7 – it (usually) works.
  6. I test it in IE6 … and then say something like “Oh dash it!”
  7. I spend anywhere up to 3 or 4 hours ‘debugging’ it to find out exactly why IE6 won’t render the page correctly. This usually involves either adding an additional CSS statement (e.g. width: 200px;) or completely rewriting the code from scratch.
  8. Repeat with the next element on my project spec.

As you might imagine, this can get quite tedious.

Acid2 Browser Test

The problem lies in the way that different browser manufacturers have interpreted the web standards as laid down by the World Wide Web Consortium (W3C). These standards, published as W3C Recommendations, are guidelines for, amongst others, browser software developers so that they know how their products should properly render web pages.

And as you might guess, some are better than others. Some follow the rules closely; others are a little more relaxed. And to test how compliant a particular browser is the kind folks at the Web Standards Project have provided an online ‘acid test’, called the Acid2 Browser Test. Using XHTML and Cascading Style Sheets — so no graphics, just div tags and background colours, and stuffâ„¢ — it tries to display a smiley face with the words “Hello world” above it.

Acid2 Browser Test results

Here is how the four Windows browsers I mentioned before (Firefox, IE7, IE6 and Opera 9) fare with the Acid2 test:

Firefox 2

Firefox tries the Acid 2 test and almost passes

As you can see Mozilla Firefox does not too badly. At least, it looks sort of like a face, even it is wearing a mask. If it were a film it would probably be Girl Interrupted.

Gran Paradiso (Firefox 3) Alpha 2

Firefox 3 passes the Acid2 test

Thankfully the core layout code has been rewritten for Firefox 3 (currently in Alpha) which fixes the problems evident in Firefox 2′s rendering of the Acid2 page.

Internet Explorer 6

IE6 fails the Acid 2 test

The troublesome Internet Exploder 6 utterly decimates the page. It should perhaps be renamed Internet Exploder and left in a drawer to gather dust. Would you believe this is the world’s most popular browser? Look what it has done to some nice programmer’s code! If it were a film it would probably be [insert name of gore-fest horror pic here].

But worry not, Microsoft improved things and released …

Internet Explorer 7

IE7 tries the Acid 2 test and fails spectacularly

The latest (and greatest?) version of the mighty Microsoft’s browser, Internet Explorer 7, which erm … well, to be honest, fares only a little better than its little brother (browther?). If it were a film it would probably be the sequel to [insert name of gore-fest horror pic here]!

Opera 9

Opera 9 passes the Acid 2 test and shows a smiley face and Hello World!

And then Opera 9 steps up to the plate and delivers 100%. That is how the page should look. If it were a film it would be your favourite feel-good movie, one that you could watch day-in, day-out. Lovely.

Konqueror (Linux)

Konqueror passes the Acid 2 browser test

And since I know you’re all wondering the same thing: “But how well does the Linux browser Konqueror do on the Acid 2 Browser Test?” I’ll tell you. It passes with flying colours too. (Thanks to Mike for the image.)

Safari (Mac OS X)

Safari passes the Acid 2 test

And good old Apple also manage to get their browser to pass the Acid 2 Browser Test with their Safari browser. (Thanks to “a mate” of Mike for this screenshot.)

The moral of the story

Imagine if your tv did this to the programs, videos or DVDs you watched. Viewers wouldn’t stand for it. So why do web users stand for it?

The moral of the story is don’t use Internet Explorer, use something better. I can thoroughly recommend both Firefox and Opera, which I’ve been using for a good few years now.

If you like customizing your software, with various add-ons, then choose Mozilla Firefox. If you just like a fast, attractive browser that shows things the way they should look then download and install Opera 9.

If you’re using Mac OS X then you are probably using Safari already, which I believe is pretty cool. And if you are using Linux then you’ve probably already compiled the Konqueror source code and installed it on your über-geeky homemade distro yourself, and I’m preaching to the converted!

You know it makes sense.

Geek adventures in Glasgow

Glasses

Yesterday I travelled through to Glasgow (by railway) to attend the Scottish Web Folk forum meeting at the University of Strathclyde.

The Scottish Web Folk group is an open forum for all the web managers and web developers from the 22 Scottish Higher Education Institutions. Yesterday’s meeting was attended by representatives from

(Apologies if I’ve missed anyone.)

Of course, before I got there I had to make sure that I wasn’t killed in transit.

Shortly after leaving Queen Street station I stepped out onto North Hanover Street, en route to the University of Strathclyde’s Collins Building on Richmond Street, only to be stopped suddenly in my path as a Strathclyde Transport bus came swinging around the corner.

I stepped quickly back onto the pavement and stood looking at the side of the bus, which had paused, unable to turn the corner completely because of a car on the opposite side of the road which had stopped for the traffic lights.

Right in front of me — blocking both the road and my line of view — was a lingerie advertisement for Matalan: five or six scantily-clad ladies, who would have caught their death (not to mention would have been arrested) if they had been wandering around Glasgow in person dressed that way.

Imagine if the bus had knocked me down, I thought. Imagine if that had been the last thing I’d seen as I shuffled off this mortal coil. Depending on one’s theology, in comparison heaven may have been a sorry disappointment! But thankfully for me it wouldn’t have been, and since I wasn’t mown down in my prime I’ll live to see another day (and presumably another similar advertisement on the side of another similar bus).

The first item on the agenda at the Scottish Web Folk meeting was an excellent presentation by someone from SAC about CSS which led to a minor debate as to whether the XHTML <br /> tag is a block-level or an inline element.

David, who was making the presentation, had copied a list of block-level elements from somewhere which had included the BR tag. A number of us questioned this and so I decided to settle the matter and sent a text to Any Question Answered (63336).

Ten minutes later I had a reply:

AQA: Within XHTML the <br /> tag is a block element. Block elements define a discrete block of text, whilst inline elements are used to style content.

Which is just so wrong on so many levels (‘block’ or otherwise!). I suspect yet another £1.00 refund winging its way to me shortly from AQA.

Here’s what the W3C — the internet body that sets standards, such as HTML, CSS, etc. — says about inline elements. This is from section 3 “XHTML Semantic Modules” within the document “Modularization of XHTMLâ„¢“:

3.3. Inline modules

Inline modules defined elements and their attributes that, when used in a document, effect their contents but do not cause a break in the rendered output.

Within both block and inline modules there are three subcategories of module:

  1. Phrasal
  2. Presentational
  3. Structural

And paragraph 3.3.3 shows that <br /> is an inline XHTML element:

3.3.3. Inline Structural Module

This module defines inline level elements to help control the structure of their enclosed content. Elements included are:

  • bdo
  • br
  • del
  • ins
  • span

So, David owes me a new kidney (he’d offered me a pint, but I don’t drink because of my dodgy kidneys so I felt that that was the next best thing) and AQA owes me a quid!

A fine day all round, then.

(Incidentally, the early time of this posting (pre-05.00 am) is courtesy of a nocturnal “meet the neighbours” incident involving our two cats and another similar beast in the utility room.)

A great !DOCTYPES resource

Doctypes table showing information about how browsers support different codes

Whenever I’m developing a new website and I encounter something that just doesn’t look right when I compare how it renders on different browsers, one of the first things that I check is the !DOCTYPE of the document.

There’s been a major push in recent years for websites to validate, that is the code behind them should be written to a standard, that follows the proper rules as set by the World Wide Web Consortium (W3C). And one of the conditions for a webpage to validate is that it contains the correct Doctype for the kind of page that it is presenting. The Doctype essentially tells the browser which rules to follow when rendering a page on the screen. (And you thought that web browsers were simple pieces of software!)

Besides the Doctype list at W3C I’ve found this page to be very useful: Doctypes and their respective layout mode.

The page author, Matthias Gutfeldt, has presented a very useful, usable table indicating how different web browsers handle each Doctype declaration. I have ‘printed’ this page to PDF to keep on my PC as a resource, even when I’m not connected to the Net — I’ve copied it to my Psion too. A fine resource.