I'm here to let you in on a secret:

You are not alone. None of the rest of us can fathom CSS either.

There, I've said it.

In theory CSS is a great idea. By separating styling from the semantic content of a document, you allow the document to be appropriately formatted for the medium in which it will later be presented, you allow the presentation to be altered without having to amend the original source document, and because the semantic content can be pulled out on its own you can make that information accessible to the blind and other people with limited access to the stylistic content.

There are a few odd people with bulging eyes who reckon that CSS really is all this and more. They think CSS is the answer to all layout questions. If you sigh a bit and wistfully mutter about how tables were easy to understand, they spring to their feet insisting that despite all the available evidence, CSS is intuitive.

My arse it is.

The really notable thing about the solutions they offer to these gripes is that they are ghastly. Complex, verbose, requiring profound understanding of the relationship between the CSS and the DOM), or ingenious integration with Javascript. Often they break in exactly the same way that table based solutions break, and when they don't they are invariably more complicated.

That doesn't mean that I think that reverting to the use of tables is a good idea, it means that I think some more effort should be put into the usability of CSS. There are various problems of course - sometimes CSS has features that would make things terribly easy, but the browsers' support is too patchy to rely upon. Sometimes one just needs a better understanding of some CSS feature and then it really is easy (the selectors perhaps fall into this category). And sometimes CSS just plain sucks and someone should do something about it.

As a (mostly) server side software developer I neither know nor care whose fault it is. But I know that there are several features that I would like, and here is my wishlist:

1. Curvy corners
2. Vertical floats
3. Formatting for forms
4. Floats within elements
5. Graphical Buttons
6. Column support
7. Order Independence
8. Widths on inline elements
9. Addressing text within textareas
10. A pony

So let's look at those in a bit more detail. Please bear in mind that sometimes there really will be a simple solution to the problem that I'm just too ignorant to know about. If you spot one, please tell me the super simple solution. Be warned, however, that if it requires absolute positioning, or sixteen different cascading tweaks, the addition of eight <div> elements to my markup and some Javascript I will snigger.

1. Curvy corners.

There are a bizarre number of "fixes" for this - it confuses me to find people so ready to accommodate the deficiency. There are fairly obvious solutions involving bitmaps and Javascript. These tend to work well but degrade badly in the absence of Javascript or require lots of fiddling when you change colour schemes and sizes. Then there are the utterly nuts solutions such as the one that involves taking the bullet point symbol from one of the standard fonts and molesting it until it describes a suitable arc.

This problem is, happily, in the pipeline for a fix. CSS3 has a border-radius attribute that will provide this functionality. Firefox 3 (at least) supports it as the custom -moz-border-radius attribute which has the virtue of degrading nicely in other browsers, though I have no idea why they chose to use the custom name instead of including it under the standard name. Perhaps it breaks in some circumstances or perhaps it is just that CSS3 is not officially "standard" yet. I neither know nor care but roll on the introduction of the standard property.

2. Vertical floats.

Getting a piece of text or a div or a button to be positioned vertically in the centre of some other element (such as, say, the browser window) is inexplicably difficult. Typically any solution to this requires at least three elements where one should be sufficient (which is definitely a leak of the layout into the markup), taking the absolute size of one of them, and then finagling things probably by knowing the exact pixel size of the screen, the elements, or the text.

3. Formatting for forms.

One of my tips for fixing all that irks with CSS would be to buy two or three of those books describing machiavellian ways to conspire against the deficiencies of CSS (anything with "hacks" or "tips" in the title) and then beat up the standard until the easiest approach to implementing everything in the book could be covered in a pamphlet.

There are three ways to style forms with CSS.

The first is to use a table. I don't know if you have spotted the flaw in this solution, but it's this: forms aren't tables and excuse me but I think someone told us we werent supposed to be using the wretched things in the first place.

The second is to put the labels and the blocks onto different rows. That doesn't look too awful, but it's not very flexible.

The third requires you to know exactly what the maximum width of things will be and then specify everything in terms of absolute positioning or pixel sizes or something. Which obviously doesn't work if you're building anything that has dynamically generated field labels such as, for example, internationalized content. Sometimes I wonder if the CSS designers ever actually built dynamic websites for a living or if they were only ever in charge of static content.

Oh, there's a fourth way of course, which is to just accumulate the form elements in any old order, or bung a line break in, or - all sorts of things. But they either look rubbish or they require you to add elements to the document for styling in which case stuff it, let's just use a damn table.

Perhaps there really is some marvellous way to do all this nicely and handle dynamic content properly, but if so it's not obvious and don't tell me it is because if the subject can generate 150 different articles describing completely different approaches to the same problem, then the "correct" solution isn't obvious and don't pretend otherwise!

4. Floats within elements.

I know you can float things within elements, but the results are never quite what you expect. The most irritating side effect is that the element suddenly decides that it has no other relationship with its daughter element and inconveniently resizes itself. I want a simple mechanism to say "float over there, but you still dictate the minimum height of the line you're on" withouth my having to tell the parent that in pixels or something.

I kind of hope this is one of the ones where I'm just ignorant of the nice simple solution.

5. Graphical Buttons.

Why on earth do we have to do Javascript to use a bitmap as a button? Even Visual Basic knew that users wanted pretty buttons back in the late pleiocene. Ok, I personally hate graphical buttons in general, but it's not that unreasonable.

6. Column support.

Again there are a lot of smart hacks to get newspaper-style columns out of CSS and again they fail for a variety of reasons none of which are down to a lack of ingenuity on the part of their proponents. Can we just have a nice simple "display in columns" widget please?

Yes, I know that's tricky for all sorts of reasons, but that means it's a good idea for you to standardize it so that we can all rely on a few browser-based implementations instead of requiring thousands of other people to reinvent a technology that was basically quite well thought out in 1455 by Johannes Gutenberg.

7. Order independence.

The order in which unrelated elements are placed within a document affects a lot of the results when that document is rendered with a particular style sheet. This just bugs me because it illustrates that there is still a significant relationship between the structure of the document and how it will actually be styled. Why, when writing my document, should I need to know that the sidebar for a page has to go after the menu for a page and not before? As far as the semantics of the text are concerned, the ordering is irrelevant!

8. Widths on inline elements.

Sometimes, just for the hell of it, or for (surprise) formatting purposes, I would like to be able to dictate the width of an inline element. Why is that so wrong?

You know, instead of demanding that we have a use for every bloody feature before it's allowed to creep into the spec, why not just make everything as consistent as possible? It will make it easier to implement, trust me. If block level elements have widths and there's no conspicuous reason why inline elements can't (note - no moral judgement required) have them slap it on. Pretty please?

9. Addressing text within textareas (and other elements).

A personal bugbear this. Go and take a look at those whizzy Javascript plugins that turn a textarea into a syntax highlighting editor. Lovely isn't it. How does it work? Well, it takes the textarea, deletes it from the document, and substitutes in an IFRAME containing a document to which markup is added, and then.... GAH! It's actually frightening that anyone got it to work at all (let alone well) given the appalling kludgy nature of the hack required.

Just give us a way to say "make line seven of this green on black from the 9th character through to the 15th" and while we're at it let's have some mechanism in the DOM for figuring out the cursor position in a textarea that doesn't require us to know the number of characters, the number of line breaks, the font metrics, and do a sum. Is that too much to ask?

10. A pony.

So here's the philosophy behind all this whining. Unlike most "web designers" I expect the contents of a web site to be dynamic content instead of arbitrarily pre-determined text, and I expect them to degrade completely gracefully when Javascript is turned off. Seriously, all of the above derive from that expectation. If I give up those expectations I can solve all my problems with the hacks available - but I can also go back to using tables, and frankly that is a much more attractive proposition.

Oh and while I'm complaining, can someone make an HTML form file upload capability that doesn't look like it escaped from a Borland Turbo Jaquard Loom application circa 1645 ?

Ok, I'm done and I promise that I'm going to have a lie down for a bit now. Complaints and "oh it's so easy you dumbass all you do is..." to dave@paperstack.com