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


Posts Tagged ‘tables’

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.

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 dictionary.com:

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.

Happy valentine’s

Saturday, February 14th, 2009

The funniest thing just happened:

I was adding this as my facebook status in one of the study pods at the library:
“Rhys is wondering why the amsterdam library has lots of signs up saying “2,000+ dicks”. 2,000 people and some dicks? More than 2,000 dicks?”

Just then a middle-aged man with his elderly father poked his head in to the pod and said in dutch something which must have been along the lines of “And look, father, in this modern library there are plenty of places where people such as this young genius can study hard”

Could there be a  better illustration of how the internet lowers our level of thought. From now on I will only have studious facebook messages.

On another note, I’m trying to choose a php framework to learn to use (akelos is the frontrunner), and used the website -www.phpframeworks.com to help me. Two interesting aspects of it are:

  1. The site is wider than my screen. I guess it’s really as wide asmy screen, but they forgot to account for scroll bars. A rare example of a website aimed at the programming community that takes advantage of the fact that most of us (though alas not I) have massive screens.
  2. It uses tables for its layout. After working for a day converting a site made with Frontpage to standards compliant, semantic xHTML, and revelling in the difference between the sites when I turn CSS off, it saddens me that everyone isn’t doing it. I mean, it’s actually quite good fun.

Happy valentine’s day