Please visit my new campsite listing site ukcampingmap.co.uk


Posts Tagged ‘float’

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.

egyptvakantie-home-page

Design of list of holiday packages

The design superficially lent itself to a simple nested list:

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

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.

The Nielsen OK/Cancel dilemma solved

Friday, June 6th, 2008

As this blog is merely a pretext to fill a web design portfolio website with regular content, I suppose I should knuckle down and write something related to the day job.

Jakob Nielsen, as well as being a good candidate for a Bond villain, is, according to many, the world’s leading authority on website usability, and as such I reckon he’s a good egg.

Contrary to what you would expect his website isn’t – in my humble opinion – very easy to use. The trouble is there’s very little sense of hierarchy, or use of visual clues. One of the golden rules of usability is that sticking to conventions tend to make things easier for the user, and he doesn’t make his navigation look different enough to ordinary content.

Also, despite writing a regular column on web usability, it’s infuriating that he does not publish a feed of this column, thus making his website more unusable still for RSS reader user s (which surely make up a higher percentage of his readership, given the subject he writes about appeals to people with an interest in all things good and webby). (Fortunately, somebody has used their initiative and put it right for him with this feed).

Anyway, one of his latest columns, on whether to put ok to the left of cancel or vice versa on web forms (the dilemma is that non web applications on apple put the buttons the other way round to windows) got me thinking about whether it’s possible to detect he operating system of a visitor, and change whether the buttons are floated left or right, depending on the OS, which would eliminate the problem.

And it turns out it is possible. One day maybe I’ll follow this post up with some example code.