Archived entry | Matt Wilcox .net

CSS needs a bit of basic love

Don’t get me wrong, I love CSS. I live it. But, it continues to have irritating shortcomings at basic levels, and I can not for the life of me fathom why this continues to be the case, year after year. Basic things that designers ought to be able to do, but CSS won’t allow:

% is not a valid unit for the border-width property

You can’t use % units on border-width. That makes fluid boxes which maintain their proportions impossible. Quite why this was ever the case I do not know. It’s the only property I can think of that makes one particular length unit illegal.

The annoying thing is that this was brought up in a CSS WG meeting in 2008, even the actual use-case of fluid designs was mentioned. And then without any further thought or debate, it was dropped. Because “there aren’t use cases”. Utterly ignoring the fact that one was just mentioned, and that, much more logically, allowing % units would bring border-width into line with how everything else in the box-model works - thus bringing predictability and uniformity to it. Alas I think at the time the WG was so focused on “paving cowpaths” that they completely forgot that cow-paths are just well worn routes to get from A to B on the existing terrain. Cow-paths are not the most efficient, flexible, or desirable methods of getting from one place to another when you’re the person who can dig a tunnel and build a bridge. Besides, how can you get “prior examples” of using % for borders if % for borders don’t actually work?! Anyway, before my blood boils, let’s move on…

Clearing boxes that contain floats

It is ridiculous that this is still a problem. In order to stop a container box from collapsing if its contents are all floated we have to resort to hacky clear-fix’s that involve adding classes to markup that doesnt need classes, adding mark-up purely to clear other mark-up, or abuse overflow:hidden;? Still? The neatest solution is overflow hidden, but it comes with the niggling problem of hiding the overflow. You know, because that’s what it’s designed for, and it’s only really happy accident that it also ends up clearing the container box. Why is there not a for-purpose property to control this yet? All it’d have to do is the same thing overflow:hidden does, but without clipping the overflow. Because we often want to see the overflow.

widow/orphan control

Is a CSS property from the CSS2 era, which is part of the “paged media” specifications. Widows are a basic concept in typography, depending on the definition you read either the widow or the orphan can be taken to mean “part of a sentence that splits onto a new page” or “the last word(s) of a sentence that drop onto a new line”. Widow control in CSS only bothers about the first half of the definition, and is not valid for screen media (obviously). That second half of the definition? Ignored. Which means we are still subject to the ugliness of things like the following:

Imagine this is a heading - it's so wide the last word is going to
drop

Allow me to face-palm. Time to get this sorted.

Font handling in general

Font handling is ham-fisted, and needs a revision. One of the most glaring problems is evident with font-substitution.

In CSS you specify a list of fonts to use, in order of preference. If the first font isn’t available then it’ll try to use the second, and so on. Great. Except that CSS doesn’t take into account which font is actually used with any remaining font properties: it’ll set the same font-sizes, letter-spacing, word-spacing, and anything else as if you were using the font you really want. The problem there is it’s very likely that the substitute font will not share similar enough properties for the other font properties to make sense. 12pt Helvetica looks massive when used instead of 12pt Mrs Eaves. So, to get a similar feel you actually need to set Helvetica a few point sizes smaller than Mrs Eaves. But you can’t. Because CSS doesn’t allow you to have that control. It means that the more unique you are with your primary font, the higher the chance that a) a user doesn’t have it and b) the substitute fonts available on the system look ridiculous.

You could say that this is less of a problem now that @font-face is widely supported. But what happens when the font is not delivered properly? As can happen if you’re using a hosted service, especially one that relies on JavaScript.

We need to be able to have CSS adapt it’s line-heights, font-sizes, etc to the font in use, not just a blanket value. Fall-back fonts require different values. CSS can’t do that.

background-x and background-y

You can’t specify background-x and background-y independently, like you can with every other property. Which can make for some very tedious and bloated rules when you’re using CSS Sprites.

Larger scale issues

You can’t position relative to a given element, only to a positioned parent element. Making it impossible to truely seperate mark-up structure from display layout.

We’re still lacking constants, variables, and math. Bert Bos can argue they’re not needed until he’s blue in the face, but the fact remains he’s wrong. There are reasons that SASS and LESS were developed and are being used by designers not just developers. But as nice as they are, they’re just battle-field medicine and we need a real solution.

Entry Information

Posted:

Sat, 27th Aug 2011 at 09:08 UTC

Filed under:

• Web Development

Tags:

• css