Please visit my new campsite listing site

Archive for the ‘css’ Category

Fonts are not quite the enemy

Wednesday, February 16th, 2011

Today I learned that there’s a lot more to using fonts  in a website than just including them with the @font-face declaration, and that maybe typekit has its uses after all.

I also learned that if I use a “Today I learned…”,  terse but link intensive format to write blog posts I’m more likely to bother to share something useful (at least this once). So more brief but bountiful posts to follow… maybe.

Batch including headscripts and links in Zend Framework

Thursday, September 16th, 2010

A bit of a dull post to break my silence with, but after a summer away, it’s back to the grindstone of earning a living through programming. Fingers crossed I’ll be given the opportunity to work again on a website I finished ages ago, fixing all the things I did badly and adding some enhancements.

I used Zend framework for the back-end of the site and first time around I had a very rudimentary grasp of how to use it, but no real in depth understanding of its finer points. I’m now finding that I did a lot of things the long way round (eg typing out JSONs by hand  rather than using the Zend_JSON class to build them automatically). One major bugbear I had was that I was adding all my javascript and css files individually to the document head, and that the syntax for doing so in Zend wasn’t really any more concise than just hard coding <link rel=”stylesheet” ….

So now I’m revisiting Zend the first thing I’ve done is write a couple of view helpers to batch add javascript and css files, which I thought I’d share here.


class Zend_View_Helper_IncludeStyles extends Zend_View_Helper_Abstract {

   public function includeStyles($folder)
     $results = array();
     $handler = opendir(getenv("DOCUMENT_ROOT") . "/css/" . $folder);
     while ($file = readdir($handler)) {
       if ($file != "." && $file != "..") {
         $this->view->headLink()->appendStylesheet('/css/' . $folder . '/' . $file);

class Zend_View_Helper_IncludeScripts extends Zend_View_Helper_Abstract {

  public function includeScripts($folder)
    $results = array();
    $handler = opendir(getenv("DOCUMENT_ROOT") . "/js/" . $folder);
    while ($file = readdir($handler)) {
      if ($file != "." && $file != "..") {
        $this->view->headScript()->appendFile('/js/' . $folder . '/' . $file);

It’s not what you say, it’s which font you say it in

Wednesday, March 3rd, 2010

I’m redesigning this site at the moment and one thing I wanted to pay closer attention to this time around was choice of fonts. Notwithstanding the fact that web browsers were, until recently, pretty shoddy at allowing you to use the fonts you wanted to, the main reason I hadn’t paid much attention to fonts in the past was that it’s so darn hard picking one, for a number of reasons:

  1. There’s so damn many of them
  2. There’s no relation between names and appearance (as opposed to, say, #f60283 being guessable as a garish pink, closer to red than to mauve)
  3. They’re difficult to preview and compare

So in the interests of productivity, quality and, dare I say it, working smarter, not harder, I’ve devoted some time to sorting out how I choose fonts, reduced to the following four steps:

  1. Organise your fonts in themed folders
  2. Find a good stand alone font previewer i.e. don’t rely on photoshop and windows’ poor tools
  3. Narrow down to a short list
  4. Use javascript to make quick comparisons easy

Read on if your curiosity is piqued.

1. Organising the fonts

Windows’s default font collection (and, I imagine, Apple’s too) and the collection of 2000 fonts I also use are organised alphabetically which is rubbish. Unless you have web design OCD you’re unlikely to want to narrow down your choice of font by it’s first-letter. But, on the other hand, it is difficult to categorise fonts; I’m yet to see a website do it effectively, and I’m not entirely happy with my choice. But in the end I plumped for the following: serif, sans-serif, script, stylised, symbol, stencil.

Stencil could easily fall within stylised, and stylised could easily be split into subfolders (Art Deco, Gothic, Celtic …), and I realised part way through that I should have a subfolder within symbol for fonts depicting alphabets other than Roman, but I think a minimal folder system would be serif, sans-serif and other. In the serif and sans-serif folders I included only sensible fonts you could print a book not aimed at children in, which I think is a useful distinction to make; often the hardest task when picking fonts is to find the one which is subtly different to other ordinary fonts, but somehow suits the design better than almost indistinguishable alternatives. Cutting out all the fancy fonts makes this task a lot easier.

So once you have all these folders put a copy of each font you have in one of them, and you’re ready for the next step. You don’t need to bother with installing them yet.

2. Previewing your fonts

My criteria for a good font-previewer are:

  1. Choice of text to use for the preview
  2. Choice of text-size and colour
  3. Ability to organise fonts how you want them organised
  4. Speed and ease of switching between one font and another
  5. Ease of installing a font

Windows’ control panel fails to meet conditions 1 and 2, and Photoshop’s built-in font selector fails to meet 3 and 4, and they both force you to install a font before using it. The best free solution I’ve come across for Windows which meets all 5 conditions is Fast Font Preview.

3. Short-listing

Once you’ve got Fast Font Preview installed you can start picking your shortlist. Simply browse to your organised font folders, click on settings to type in your sample text, adjust the font-size to what you want, and double click on any contenders. Once the font is opened you can install with one click. While the font is open you’ll also want to jot down its official font name.

4. Use javascript to make comparisons

This is where I stop being pedantic and hopefully can be of some use. Insert the following script into the head of your web-page-in-need-of-a-font, substitute your list of font names and the id/tag name of the elements to be affected and, hey presto, a handy font-switcher should appear, making choosing exactly the right font much easier. If your web page already uses javascript then add the body of the function to your existing onload event. (NOTE: It tends to work better in Google Chrome than other browsers as Google Chrome seems to be a bit more forgiving when it comes to font names).

window.onload = function() {
 var body = document.getElementsByTagName('body')[0];
 var id = '';
 var tagName = '';
 var fonts = 'Comma,separated,list,of font,names';
 fonts = fonts.split(',');
 var elements = (id)      ? [document.getElementById(id)] :
                (tagName) ? document.getElementsByTagName(tagName):
 var switcher = document.createElement('DIV');
 for(var i=0, il = fonts.length;i<il;i++){
 var buttons = switcher.childNodes

 function createButton(pos) {
   var button = document.createElement('a');
   button.innerHTML = fonts[pos];
   button.onclick = function() {loadFont(pos);};

 function loadFont(pos) {
   for (var i=0,il=elements.length;i<il;i++)
     elements[i].style.fontFamily = fonts[pos];
   for (var j=0,jl=buttons.length;j<jl;j++) {
   return false;

Display:run-in – why would you?

Monday, February 22nd, 2010

A while (about 2 years) ago I was reading quirksmode’s page on support for CSS display properties in browsers when I came across a hitherto unknown type of display – display:run-in;

Something with display run-in, if followed by a block level element, becomes the first inline-block of the next block-level element.

So if you have the code

<div style="display:run-in;font-weight:bold;">My run-in box</div>
<div style="display:block">My block box</div>

it should display as follows (though doesn’t in firefox or ie yet):

My run-in box My block box

Quirksmode poses the question: ‘Why would you want to do this?’

Well, I can think of a very good reason: starting a paragraph with a heading, such as the following:

Conclusion: display:run-in can provide a more semantic way of representing a paragraph which has it’s heading as the start of its first line. At present I bet everyone just wraps the heading in <strong> tags, but that’s not really what <strong> is for.

Or also for a definition list

Second argument in favour of display:run-in: Using display run-in, imagine this is a <dt> followed by a <dd>. How would you get the <dt> to appear inline with the <dd> without display:run-in?

So given that display:run-in is useful it’s surprising that firefox are yet to implement it, especially given that ie8 has already done so.

Well I never

Thursday, December 10th, 2009
Colouring in

Colouring in

If there’s one thing I know when it comes to web development, it’s CSS. I don’t always write it in the most organised fashion (though I like to think I do when I’m given a finished design to work from), but for over a year now I’ve felt that my knowledge about the bits of CSS that I use daily is pretty complete*. And for the bits I don’t have to use very often I an always find what I need on the internet.

So imagine my surprise today when I realised that there’s one area of CSS that I use everyday with a fetaure I was completely unaware of. I’d always thought that


meant “Make the text in the paragraph red”, but it turns out that that’s not the full story.

In all browsers, it seems, if border-width and border-style are defined for an element, but no border-color, then color also defines the border colour. But then if you define a value for border-color then color gets ignored when calculating the border colour. Even if you use another selector of higher specicifity to set a new value for color this still has no effect on the border colour. Here is a demo page.

But is it of any use?

Well, yes – it turns out it is.

Let’s say you want to define a generic button item as follows

.button {display:inline-block;border-width:2px;border-style:solid}

Then you can coordinate the text and border colour of the buttons by just using, eg

.cancel {color:red}

And this technique could be used for all sorts of generic elements where text colour and border colour are normally same. To use a different colour for the border it’s an easy thing to over-ride too.

Has anyone ever included both the British an d American spellings of colour this much in one article before?

* excluding newly emerging vendor-specific styles, eg -webkit-make-it-look-cool {}

Avoiding using a list when a table won’t do

Sunday, May 24th, 2009

The other day I neglected to mention how I had resolved the list/table dilemma on the site I’d been working on.

As I explained, the content fitted the semantics of a table more than that of a list, but Internet Explorer’s bugs in applying positioning to <tr> tags (up to and including ie8) prevented me from using a table to implement the design.

Or did it.

In the end I had two choices of mark-up for each item in the list:

  <li><h3><a title="Blue Reef Resort" href="duikhotel/Egypte/
... marsa_alam/Blue_Reef_Resort">Blue Reef Resort</a>
        <li>All inclusive</li>
        <li>8, 15 dagen</li>
        <li>Marsa Alam</li>


  <th colspan="3" scope="row">
    <a title="Blue Reef Resort" href="duikhotel/Egypte/
... marsa_alam/Blue_Reef_Resort">Blue Reef Resort</a>
  <td class="rating">
     <img alt="4 stars" src="/img/star4.png"/>
  <td>All Inclusive</td>
  <td>8, 15 dagen</td>
  <td class="location">Marsa Alam</td>
  <td class="price">vanaf €399</td>

The second example, combined with appropriate column headings, I figured gave the closest approximation to the real table structure of the content. And the presence of a <th> every other row does suggest that rows are to be taken in pairs (though I’m not sure this is any help to screen reader users).

The above means, I think, that I am closer to web design zen. I have rejected the false grail of table based design, and only now that I have mastered CSS and semantic structure can I claim to understand the table and start to mold it to my enlightened purposes.

In defence of jQuery browser detection

Friday, May 22nd, 2009

I read somewhere the other week that jQuery is deprecating its jQuery.browser method, which means that in the future (though not yet, as the method still works but will not continue to be developed/supported, and will eventually be dropped) you will not be able to directly ask jQuery which browser it is being run in.

The rationale behind doing this is on the face of it sound: The reason you want to check what the browser is is that you want to check if a feature of javascript is available in that browser… so why not just ask if that feature is available, then the question of which browser it is becomes irrelevant. This will enable your script to continue to function (most probably) even in the unlikely event that eg Microsoft bring out a patch for ie6 that makes it fully support javascript.

But there is a flaw in this reasoning. It assumes that the only reason you would want to serve some different script to a browser is because of flaws in the browser’s javascript implementation, but in fact there are other reasons for doing this too, principally the browser’s failure to render CSS correctly.

While the new method does include tests for boxModel (ie6 and 7′s incorrect rendering of the CSS box model being the principle reason behind serving different CSS to different browsers) and one or two other CSS bugs, this simply isn’t up to the task. The box model is broken in ie6 and ie7, but broken in different ways, so normally to fix a layout bug I will want to serve different CSS to both.

Using various combinations of, eg

! &&

you can still detect ie6 and ie7… but is this really an improvement on jQuery.browser?

jQuery.browser.msie && jQuery.browser.version.substr(0,1)=="6"

With jQuery.browser it is wholly transparent what you’re trying to detect, and if the code within the conditional’s braces contains a hefty amount of CSS rules your average developer should be able to work out the reason for the browser detection is to fix CSS bugs.

One other reason for explicitly detecting a browser (which I need at the moment as I’m developing a jQuery plugin) is that different browsers render form elements differently (the most obvious black sheep is safari’s making most elements look blue and glossy, but there are subtle differences in other browsers too). If I, say, want to fake a <select> element  by using a <ul>, and want it to look convincing in all browsers I need to supply each browser with differentiated CSS. jQuery.browser would be the obvious way to do this. No matter how many CSS bugs get fixed in browsers, how to render form elements by default isn’t specified by CSS/html, so there will always be this reason to want to detect browsers.

jQuery.browser is a very useful feature and it’ll be a shame when it goes.

CSS positioning and tables (or, it’s a list whether you like it or not)

Wednesday, May 20th, 2009

Marking up web pages semantically is normally more or less a doddle. Most tags are named (or have abbreviated names) that are straightforward. If you’re writing a  paragraph, wrap it in a <p> tag. If you’re writing an ordered list put it in an <ol>… and so on and so forth. And it’s actually less effort than typing eg <div class=”list”>.

But there are nevertheless lots of examples where the tags offered by (x)html seem hopelessly limited in their semantic meaning. Recently I worked on this site. On the home page is a list of holiday offers, and I ummed and aahed over how to mark it up for a while. Previously I would always follow the same practice – lists of complex items would be marked up as a list, and whatever more complicated markup needed would be placed inside the <li> items. But I’ve read somewhere that putting too much information within a list item can actually be a hindrance to accessibility,  so this time things would be different.


Design of list of holiday packages

The design superficially lent itself to a simple nested list:

  <li><h3>Blue Reef Resort</h3>
        <li>All inclusive</li>
        <li>8, 15 dagen</li>
        <li>Marsa Alam</li>

But it’s hardly satisfactory. The items in the sub-list are in fact properties of the particular holiday offer. In fact, the whole thing is more like a table, which becomes clear if we just move some bits around.

Modified design to show true semantic structure

Modified design to show true semantic structure

So to achieve the required design all we need is to hide the table header and move some of the cells around. The first task is easily completed with a display:none, but the second is alas not very feasible. While support for floating and positioning table, tr and td elements is supported in ie8 and other good browsers, in ie6 and ie7 there are big problems as they more or less ignore that the <tr> element is there. You can’t float a tr, you can’t give it position:relative (in order to absolutely position td’s within it) but, bizarrely, you can absolutely position a tr, though this is of limited use. Racking my brains for a use the only one I’ve come up with is in order to give you the ability to absolutely position the tr’s td’s absolutely in relation to the tr, but then you would need a different style for each tr to avoid them layering on top of each other. Which admiteddly could be generated dynamically as an inline style, so perhaps not all that hopeless a situation.

ie6 and ie7 also don’t support floating on table cells either, in case you were thinking that was an option.

As it turns out, I may have discovered a new bug in Internet Explorer 8. While writing this I set up a test page to make sure what I thought was the case was correct (turns out I was, in my main thesis, incorrect, as I thought HTML/CSS had no provision for positioning table elements). Here are 3 screenshots:

Correctly positioned table elements (firefox)

Correctly positioned table elements (firefox)

Incorrect table element positioning (ie8)

Incorrect table element positioning (ie8)

Incorrect table positioning (ie6/7)

Incorrect table positioning (ie6/7)

Once again, ie has problems dealing with relative positioning on tr’s. On the face of it it’s not as bad in ie8 as in ie6/7, but what’s happening is that instead of letting the tr’s confuse the positioning completely, it just ignores them, and goes ahead and positions relative to the next positioned ancestor, which is een worse if you look at where the cells get put relative to where they shoudl be – ie6 and ie7 nearly get it right (but this might be a fluke that a larger table would unmask), but ie8 is completely wrong.

The long and short of this article is that there are lots of instances where a table should be the natural choice of markup (given a little thought about what the content’s structure is), but once again thanks to Internet explorer, it’s going to have to be a nice idea that will have to be shelved for the time being.

So, unless you fancy individually positioning each tr with its own style rule, nested lists it is for now.

Zombie table resurrection

Friday, April 17th, 2009

A few months ago a blogger posted a now infamous post on the falilings of CSS as a design tool, and advocating tables be used instead (if you want to read why he’s wrong, this is probably the best riposte, quite rightly pointing out that he thinks because he is bad at CSS then CSS must be too hard to do design with, and you can justify using tables instead).

But what I found most notable about the whole debate was how he throws meaningless phrases around and no-one seems to pick him up on it.

For instance

tables have the correct semantics for doing layout

What on earth does this mean? From

Semantics: the meaning, or an interpretation of the meaning, of a word, sign, sentence, etc.

Well, what he seems to be saying is that tables’ meaning is “used for layout”, but the whole point is that they don’t!

In another article I think he reveals his not particularly investigative side.  In response to a comment:

> put your content inside a table, lose most users with disabilities

That is far from clear. I just did a Google search on “html accessibility tables” and got a zillion pages on how to make tables accessible. Even the W3C’s own web site says you can make accessible web sites using tables as long as you adhere to certain constraints.

Well, I did that search for html accessibility tables, and most, if not all, of those zillions of pages are about making html data tables more accessible. If you search for html accessibility tables layout you will find a lot of pages explaining why you shouldn’t use tables for layout as it’s inaccessible. The only article I could find condoning table use dated from 2002, in a time when dreamweaver still largely used tables, and the condoning was merely an acknowledgement that while the standard tools in the industry still used tables you couldn’t expect everyone to switch over overnight. In fact the article opens with a pretty good summing up of what’s wrong with tables.

So, why have I written this article, responding to something from a few months ago? Simply to illustrate that there is still so much junk been pumped out onto the internet on designing using tables that it is as hard as ever to find information on designing tables.

Nail on its head

Wednesday, April 15th, 2009
A man looking like santa hammering in a nail

I really think I’ve hit the nail on its head when it come to captioning pictures. I really do.

It always bugged me that there wasn’t a really semantic way to caption a picture, despite it being a very common use of words both on the internet and off (for instance, I caption everything I see by talking about it VERY LOUDLY), and this all came to a head yesterday on

And I hit upon the perfect semantic way of doing it. The picture on the right is a working example. The caption is actually a heading – a h5 in this case – above the image in the markup, but a combination of padding and positioning has put it beneath the picture.

Semantically if you put a heading above a paragraph/section then the heading should tell you what’s in that paragraphsection. Surely the same extends to images too. So my markup literally means “The following picture is a picture of a man looking like santa hammering in a nail”.

So here’s the bare bones code, though you’d obviously want to use classes and wotnot:

<div style="position:relative;padding-bottom:50px">
<h5 style="position: absolute; bottom: 0pt; left: 0pt;
           height: 40px; line-height: 14px; font-size: 12px;">Caption</h5>
<img src="..."></div>

Vive la moderate improvement in accessibility.

Finally, I realised today that because of web standards, my job will get easier with time – another 2 years and I won’t have to take ie6 into account… a few more after that and ie7 will be gone… and from ie8 it will be plain sailing. So the job will be easier, but much less fun.