The web is still young, and still in development stages. Sometimes, it is easy to forget that. In ten or twenty years time, most of the standards now being worked on will be complete. XHTML, or whatever replaces it, will be well-created and slick, and coding a site will be a breeze. CSS, or whatever replaces it, will include the properties we need, and will be implemented properly on most platforms.

At the moment we still have something of a chance to have a say in the development of web standards. So in the interests of having my say, here are a few of the things I would love to see in a future version of CSS.

Backgrounds: background-top, background-top-right, background-right and so on

These properties are the ones I wish they would add quickest. Being able to define so accurately means that a large selection of current problems that need to be worked around in CSS will be no more. Boxes with curved corners and layered backgrounds become trivial - the web becomes more beautiful - and World Peace can't be far behind that.

The decision as to which background should show over another, should such a situation arise, would be made based upon the order these properties were specified. Thus, if background-bottom-right were specified last, it would show in front of any previously declared backgrounds for the same element. That means, as CSS properties that are not understood by the user-agent are ignored, that these properties (as with those below) will enhance the browsing experience for the users with up-to-date browsers, but will allow for graceful degradation.

Borders: inner-border and outer-border

The "border-style" property gives us a decent range of border types to use, but I would rather have a little more control. At the moment, you cannot define a border with two colours, for example. A thin black line around a white box, with a thick grey line outside it, for example, is impossible without extra markup. The inner and outer border properties would give that little bit of extra control - though I dread to think of what that will do to the box model!

Fonts: font-size-min and font-size-max

These two properties would allow the setting of, believe it or not, minimum and maximum font sizes. Relative sizing has pitfalls, and among those is that sometimes text can be unreadable on site because it is st to be relative to the user's default. Being able to set minimum and maximum sizes in pixels makes life much much easier for all.

Fonts: font-family-file

Something along these lines is already part of the CSS3 specification. While it will be some time before CSS3 is in widespread use, this can really only improve the web. Fonts are usually small files and while distribution of them is a tricky process (given that most of them are not free), it would be good to be able to define fonts with a font file on the server. A browser can then be set to accept or reject font files as the user wishes, and the specified font can be used - if the user wants. Otherwise, as now, a fall-back font can be specified.

Boxes: height: expand;

Block-level elements automatically expand to fill all available space horizontally, but their height is only ever defined by their content (and padding, etc). I envisage height: expand; to instruct a browser to display a block element in such a way that it fills all available vertical space.

Variables: @site-id

I'd like to see a small degree of variable use in CSS. Not much, because it is a presentation language, but a little. Things like being able to set specific styles in a user style sheet for a specific site are a great advantage sometimes, but rely on the user making use of useful ideas like the body id attribute with CSS Signing, which few authors currently do. A URL-based selector negates the need for that.

This would also mean that defining multiple styles for a site would become much easier. Instead of using server-side scripting, or a JavaScript style switcher, you could just as easily make use of sub-domains or URL-based variables in your CSS to determine which style sheet to use.

Specifications

Selectors and properties are different. I'd like to see the CSS standard split into two documents - one for selectors and one for properties. There is no need for them to be released hand-in-hand, and selectors can be added to a standard (and implemented in browsers) very quickly, for the most part.

Actual presentation properties take longer to define and much longer to implement in browsers. Having separate documents for these means they can progress independently, which I think would be a bonus. I appreciate that this might over-complicate things in some circumstances, but I think it would be worth it.

Better use of Mime Types

CSS should be sent to a browser, at the moment, as "text/css". But CSS1, CSS2 and CSS3 are different. There is currently no way for a user agent to tell a server what it can and cannot understand, and no way for a server to specify what it is sending back. Addition of mime types of "text/css1", "text/css2" and "text/css3" mean that, if you so choose, you can deliver a specific level of CSS to a browser. It also would mean people understanding the differences between the different versions. Most designers at the moment couldn't actually tell you one difference between the two versions of CSS so far released.

That's All, Folks

Those are my personal favourites - the things I would like to see added. Some of these are due to be part of CSS3, thankfully, and with any luck some will make it into whatever supersedes CSS3 in a few years time.