Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Designer’s Wishlist

August 12, 2003

I’m currently subscribed to www-style, the W3C’s mailing list for CSS development. CSS-3 is being developed this very moment by engineers and programmers. Why aren’t a few designers involved in building a language meant for style? I honestly don’t know. Maybe none of us were ever asked. Maybe none of us ever volunteered.

Mike Pick started a wish list today with linked text boxes and alpha-channel runarounds, two features he’d like to see carried over from the print world. Both are logical to the designer, and already work in existing software applications. Here, then, are a few more to add to the pool.

Element Awareness

Visual design is all about proportion. If I have to guess at arbitrary values for text blocks of varying lengths, I can’t properly design how they relate to each other. I may want #elementTwo to be 500 pixels high because #elementOne is, but if the user has a different default font size than what I designed for, my plans go out the window.

If I was able to apply height: inherit(#otherElement); to a specific element, the problem would be solved.

Better Vertical Alignment

The vertical-align property has been around since CSS level 1, but it’s currently a poor concept in general use. You may only apply it to inline elements (and later, table-cell elements) — we need block-level vertical alignment too, guys. Why can’t we apply it to both?

Type Improvements

Credit where credit is due: CSS handles type really well right now. line-height and letter-spacing attributes and first-line/first-letter selectors go a long way toward addressing what designers traditionally do with type. But since there’s always room for improvement, here are two things I wish to see addressed. Compare the following:



It’s possible you’re scratching your head and wondering the difference, but trust me, typography geeks will see it. You may only see one intended effect, but there are two problems (assuming the size is the same!) with this demonstration.

The first is that I have no idea which font the top word renders in. Theoretically, you should be seeing Helvetica. But if you don’t have it installed, chances are you’re seeing Arial instead. The fact that I have to guess at this highlights a big problem. Typefaces are important, and to some designers, having to dish up Arial as a substitute for Helvetica is almost as reprehensible as serving Comic Sans as a substitute for Caslon. This problem isn’t really the W3C’s to solve, but someone has to figure it out.

A proprietary solution exists in Microsoft’s WEFT, but when was the last time anyone actually used it? Thanks to licensing issues involved in embedding fonts, the whole process of selecting a character subset from a font that’s actually safe to embed is almost onerous enough to invalidate the method.

The second problem with the above example is something the CSS working group can address. Notice the difference in spacing between the two words? The top is loose and looks about as good as setting type with any imaging program before adjusting. The second is tightly-kerned and far more refined. In Photoshop, as with any high-end design program, I can adjust the space between each letter individually. Yes, this is important.

While kerning in the style sheet would quickly become a burdensome task for any longer passages — and really, who kerns body text? — I should at least have the option of adjusting my display text; that is, my headlines. A possible interface might look something like kerning(5): -10, +5, -20;. The first value would apply to the space between characters five and six, with the subsequent values affecting those between six and seven, and seven and eight, respectively. Units could be percentages of an em, or for maximum obfuscation they could be full em values (and the designer would just have to put up with three-digit decimal values).

What do you want to see out of CSS? What kind of functions do you find in traditional design software that you wish existed in CSS? If the list grows to significant proportions in the comments, I’ll consider submitting some of these to www-style.

Reader Comments

Bob says:
August 12, 01h

I’d like to see true browser-based transparency of background colors without having to resort to alpha-trans PNGs (which fail in IE6 if used as background-images) or “semitransparent” GIFs comprised of a checkerboard pattern of transparent and opaque pixels.

Dave S. says:
August 12, 01h

Could this be what Mike is asking for?

Bob - I think is what you’re looking for.

Dave S. says:
August 12, 01h

I just realized that kerning is useless unless you know ahead of time that the font you’re kerning is the font the end user will see. Even a different font size will throw off your optical adjustments, thanks to anti-aliasing.

So in order to have kerning, there has to be a system in place that guarantees the end user’s browser is using the same font I’m kerning. I don’t see that happening. This is why img- or FIR-based text continues to be important.

Jai says:
August 12, 02h

Call me radical, but I want diagnals. I want the ability to take that rectangular div and stick it on a 45 degree angle. I don’t know if anyone else cares about this, but I think it would lend itself to some very cool designs… of course, then you’ll get the designer-wannabes creating whole slanted websites thinking that they are all cool, but in general- used in moderation- this would be mad cool.

August 12, 02h

Michael’s column idea is tops on my list. I’d love to be able to easily flow text into columns, and I think the ability for designers to do this would encourage more print-influenced design (which may or may not be a good thing).

At the risk of getting flamed for supporting Microsoft, I always really liked the filter: alpha (opacity=xx) interface to creating trasparency that you can use in IE5.5+. The concept is great, but the execustion leaves a bit to be desired. It sounds like CSS3 may include this sort of thing. I sure hope so.

I’d like to see a more robust text-shadow property, and I’d like to see a similar drop shadow property that can be used on block, as well as text.

“Stroke” is one thing I’d REALLY like to see. Granted, it’s similar to “border,” but you can’t “stroke” text with the “border” property.

August 12, 02h

With regard to “Element Awareness,” Internet Explorer actually supports something like the following:

p.caption {width: expression(document.getElementById(“img01”).width)}

Of course, I don’t think that’s the way CSS should do it.

Bob says:
August 12, 02h

“Bob - I think [url clipped] is what you’re looking for.”

Thanks, Dave. I actually had not looked at the proposed specs. (Could you tell?) That is in fact exactly what I’m looking for.

I guess the biggest obstacle to all of this is, as always, browser support.

Dave S. says:
August 12, 02h

For future reference (as much mine as yours) - is the list of CSS-3 working drafts.

Jeff — — the font-effect property coming up in CSS-3 offers outline, so stroke will be covered. I seem to remember seeing drop-shadow somewhere along the way, but I could just as easily be confusing CSS for IE’s filters or SVG on that point.

Personally, I’d rather see some of the layout problems resolved first before we get into frills like embossed text and drop shadows, but I suppose we’ll have to come to them eventually, and if they’re in the drafts…

Minh — I’ve never seen that before. The syntax leaves a lot to be desired, but the net effect is exactly what I’m looking for. Now to get that concept into a spec…

Mike says:
August 12, 03h

I’m afraid I don’t understand “junk element” - what does this mean? That a empty div would be specified in the HTML - although it technically would not be empty since it gets text flow?

re: angles:
Yes! Content rotation! how about

#yourblock p {text-angle: 45;} … heh.

I love this sort of thing - fantasy coding.

re: CSS Columns
Yes and no - it’s sort of like a table layout - and limited because of needing a containing box. Ideally you might want to link two entirely different absolute position divs…

Another to add to the list would be the ability to affect other blocks without using javascript or some such - so that a:hover changes content in a completely different block, for example…

August 12, 03h

In addition to the opacity property that Dave linked to, there’ll also be HSLA color values ( ). Opacity will make the text semi-transparent as well as the background, whereas you can set an HSLA value for the background-color property and keep the text completly opaque.

I’ve always thought that having a ::background pseudoelement would be helpful, because it offers more flexibility than even the background properties that CSS3 offers. For example, you could specify the background with the following:

h1#masthead::background {position: fixed; right: 14px; repeat: no-repeat; content: url(“bg.png”); border-right-color: aliceblue; border-right-width: 5px}

Mike says:
August 12, 03h

WRT font embedding and finer kerning control, well, native SVG support would help for that - and could potentially solve the FIR thing as well.

Of course, I don’t want to pull this discussion into the realm of the real-but-not-implemented - it’s just too depressing.

Seamus says:
August 12, 03h

Two things I would like to see:

1. A pre-adjacent selector. Very much like the adjacent selector now but it would apply to the element before not after.

2. A active-hover pseudo class. It would start once the active state is in effect and would persisted as long as it is in the hover or active state. Note: their is a :menu, but I do not think that is the same thing.

Adam Rice says:
August 12, 03h

Positioning of gross page elements is just too damned hard. a lot of people have done admirable work on figuring out how to do, say, three columns plus a footer, but this shouldn’t be rocket science. The current techniques of float, absolute, and relative positioning are powerful, but difficult to apply well. We need new techniques.

August 12, 03h

Here’s some more information on the Internet Explorer “CSS expressions”:

Dave S. says:
August 12, 03h

Adam — - CSS-based table model, introduced in CSS-2. Theoretically, that should address our layout problems.

Now, can someone remind me why we’re not using it right now? Browser support is my best guess, but I’ll plead ignorance here.

Claire says:
August 12, 03h

Adam, what Dave says and

although I’ve just been working on such a project (3 column CSS layout):
.. which did seem like overly hard work, it’s only because the cross browser “quirks” are coming into effect. The easy bit was the table properties ;)

You’re right it’s not rocket science but how come there’s so much “layout reservoirs” and basic questions still needing answered?

This is the next phase of CSS I think, it’s not so much what we’d like it to do but what we can Make it do, there’s nothing like skimming over the basics to make you miss important stuff.

But because we’re being ‘forced to make do” we’re learning the subject inside out and back to front.. I know that I am still learning something new every day.. and I like it that way.. because if everything were a walk in the park, then everyone would be doing it and this discussion wouldn’t even exist.. software would be taking our place!

So although I say carry on with the wish lists I know deep down it will make (me) us lazy when it becomes a mechanical task

August 12, 04h

Dave, I don’t think the CSS2 table model addresses *all* our layout problems. It allows you to reproduce certain table-based layouts, but to do anything complex (e.g. colspan, rowspan) you still need to use HTML tables in the markup. Even relatively simple layouts will often require a significant amount of presentational markup for CSS tables to work. (Generated content might help with this to some degree.)

taestell says:
August 12, 05h

“A pre-adjacent selector. Very much like the adjacent selector now but it would apply to the element before not after.” —Seamus

This is what I was going to suggest. ‘h1+p’ means a ‘p’ that directly follows a ‘h1’. ‘p^h1’ could mean a ‘h1’ that is immediately before a ‘p’. Of course, ‘^’ might not be the best character to use for this, that would have to be looked in to.

Nic says:
August 12, 07h

I may have simply missed it, but I’d like the ability to change the orientation of text. My desires are simple;-)

Duc says:
August 12, 07h

Some designers ask for a lot of things and never stop to ponder how difficult some of those things would be to implement. Programming isn’t magic :) I’m both a designer and a programmer so I keep my designer wishlists minimal.

Dave S. says:
August 12, 08h

Duc - maybe that’s why Quark & InDesign cost hundreds of dollars. But I can’t imagine anything suggested so far could be more difficult than float, and we seem to have that one locked up. Does the W3C have an obligation to make sure their recommendations are easily implementable?

Stv. says:
August 12, 09h

Apologies if I’m repeating someone else’s. My eyes went fuzzy quickly so I just skimmed.

What I want more than anything else is the ability to easily flow text from one column to another. Kind of like what’s going on over at the International Herald Tribune site, or what happens in magazines. And I want it dynamic so as users expand/contract their browsers, it re-flows, and also if/when users change font sizes.

Apart from that? a really simple way to round corners on things. Particularly form elements. Call me crazy, but since I made my first form way back in the mid 90s, I’ve wanted to be able to round out the edges of my form elements.

Hmm..Oddly, and probably useless, but I’ve had reason to do it before is having non-rectangular boxes. Like a triangular or ovoid box, with borders,padding,margins that change shape to match (as opposed to fitting said shape into a rectangular box).

August 12, 09h

Another thing I’d like to see is:

clip: poly(coords);

August 12, 12h

Hi Dave… The linked text box idea (at least as Mr. Pick proposed it) has been proposed and shot down many times because it relies on a junk element. As you know from the FIR criticism, this is a bad thing.

I recently had a proposal to overcome this; you may have seen it if you were on www-style at the time. It basically proposed the introduction of a new pseudo-element that could be style independently of its content-parent.

Here’s the post:

Unfortunately, there is no formal way for members of the public to propose new additions to the drafts, so I’m afraid my proposal went under the radar. I got absolutely no response to it on the list.

I’m posting it here not as an attempt at self-promotion (well, maybe a little:) but because I agree with you and Mr. Pick that this is an important addition to CSS. We designers have been trying to push this through for years. What do you think?

PS. I agree with the rest of your wishlist.

August 13, 01h

I think it is more important to get consistent and complete browser support for CSS2 before concentrating on CSS3. However, I’d like to add my own wish to the pot.

I am sure that many people will gasp in horror at this proposal. I would like to see the ability to make radial and linear gradient fills on colors (text and background), through the entire specrtrum and opacity range. I would suggest that start and end points could be specified using the same values associated with background-position.

I am certain that this would be programmatically awkward, since it would require a dynamic redrawing of the gradient(s) during a viewport resize. However, both SVG and Flash are capable of it, so it should be possible.

Dave S. says:
August 13, 01h

Simon - it is, but that’s not up to the W3C. Since there’s nothing they can do to speed adoption of recommendations, the best they can offer is continued improvement of those that exist.

Your gradient fill idea is something I’ve considered too, but when I think about how much extra work goes into making a gradient actually work well in Illustrator or Photoshop, I realize that if CSS did them they would almost assuredly be relegated to amateurs just cutting their teeth on CSS.

Steve - should be more or less what you’re looking for. The caveat being that I doubt it will ever apply to form elements - those have always been considered part of the operating system, even though Mozilla goes to great pains to render them otherwise. That we can style them somewhat is, I believe an extra ‘feature’ that’s not W3C-governed.

August 13, 01h

I don’t know about the support, I think there isn’t any :), but you can tell a browser what font to use and if the user hasn’t got it, the browser will download it instead:

And that with pure CSS. About the tranparacy, you can do it with todays browser only CSS (Opera hasn’t got any support):

opacity:.5; /* CSS3 */
-moz-opacity:.5; /* Moz */
filter:alpha(50); /* IE, most ugly solution */

August 13, 02h

@ Stv. do you mean this: ?

@Dave, with the @property I linkek at above, kerning (what is it?) will be posible I think. But it should only be possible if the above @ thing is applied.

Off-T: Could you make the box “remember me” checked by default?

August 13, 02h

“when I think about how much extra work goes into making a gradient actually work well in Illustrator or Photoshop”

To be honest, I was thinking of it more from a perspective of depth. I use gradients to make things look a little more three dimensional.

Another “wish” I have would be the ability to style IFRAME content. This could also extend to html object data. An example of what I mean can be seen on Tantek’s log - - he imports text/html using <object>, but he has to apply a separate style sheet. It would be cool to be able to style such data in the context of its ‘parent’, would it not?

Dave S. says:
August 13, 02h

<iframe> actually lasted up till XHTML 1.0 Transitional - it’s been dropped from Strict and 1.1. I doubt the CSS-3 working group is much concerned about it at this point.

August 13, 02h

I know the <iframe> element isn’t much of a concern, but surely the <object> element is.

Incidentally, has anyone had any success with using CSS to alter the z-index value of an object? I tried to get some imported Flash (Satay method) to appear beneath other elements, but I failed to succeed. With the exception of IE/Win, the object always seems to appear on top.

You can see an example of the problem at this temporary page (resize browser window):

August 13, 04h

Stv., Dave linked to the future border-radius property in CSS3. Mozilla currently implements a -moz-border-radius property. You can find out more about it at . Mozilla’s rendering of rounded corners is a bit rough, though. Of course, you wouldn’t notice that unless you specify very rounded-off corners.

Seamus says:
August 13, 05h

Instead of just being able to use just solid colors to fill text, it would be nice if their could also be an image fill for text. This would be nice for headers.

DutchCelt says:
August 13, 10h

I seen a number wishes fly by and on the top of mine is importing fonts. Nothing new in CSS land, but supporting it would definitely be new. Multicolumn layout would also be nice. Michael Pick and James Craig and the W3C have their own idea’s on how to do it. But I see them all living and working together. Isn’t that nice ;)

Eugene says:
August 14, 02h

I’ve never seen this mentioned but I think it woud be great if we could have text wraparound applied to absolutely positioned elements (sort of like what is done with float elements). That way, you can place pull-quote elements after the article body in the HTML instead of interrupting the body of the article. Then with CSS, you can place these elements wherever you want and have the articles automatically wrap around. The margin properties of the element specify the wrapping box.

#pullquote1 {
wrap: #article; /* multiple elements can be specified */
wrap-position: left; /* or right, both, no-wrap, none */

Also , there should be a way to position elements based on other completely unrelated elements. That way, you can align stuff with respect to each other and without needing to define container elements with position set to relative.

Tao says:
August 14, 09h

My proposal should be simple.
I’d like to be able to set an element to have a width or height that just takes up the available space without breaking.

To explain, imagine two divs #one and #two.
I give:

#one {
width: 300px;
float: left;
background-color: yellow;

#two {
width: fill;
float: left;
background-color: red;

This would produce a 300px yellow element followed by a red element that will take up that rest of the width of the containing element. In case they are both top-level elements that could mean the full width of the browser. If the browser gets resized this element will resize with it.

By having something like this it becomes much easier to create multi column layouts with fixed-size columns in them (for instance a menu bar)

As far as I know the only way to do this now is to work with absolute positioning or nasty margins.

Dave S. says:
August 14, 09h

Tao - what’s wrong with width: auto;?

Adam Rice says:
August 14, 10h

Claire–Thanks for the demo–that’s a useful approach (I recently saw a demo of the reverse–rendering tabular matter in a non-tabular form). As others have mentioned, I’m not sure that’ll solve all our layout problems. I’ve occasionally wanted to be able to “magnetize” a div to one edge or corner of the window–or another page element–and have everything work its way into the middle to determine spacing. This is kinda-sorta possible now, but not easy.

One other idea I’ve had is more flexible selector matching. I suppose the ultimate would be GREP matching.

Standards adherence, of course, is the big one, but that’s not the W3C’s problem.

Tao says:
August 19, 02h


Pardon me if I’m wrong, but width: auto does not produce the intended effect. At least not in Moz, nor in Safari.
width: auto just produces a div of the size of its contents here.
Maybe I’m missing something but:

.one {
width: 200px;
float: left;
background-color: purple;

.two {
width: auto;
float: left;
background-color: yellow;


produces a purple div with the proper width, followed by a yellow div that does not fill the available space (i.e. the rest of the width of the browser window).

Any ideas?

August 19, 08h

Another one:

I’d like to be able to use “position: fixed” within an absolutley positioned box.

For example: say I have a wrapper that contains all of my page elements:

#wrapper {
margin: 50px auto;
width: 750px;

And a small box inside of that that display, say, the lastest news headlines. I use overflow: auto to add a scrollbar if necessary.

#newsBox {
width: 150px;
overflow: auto;

Now, say I have a header that I want to always sit atop the newsBox, even if the user scrolls it:

#newsBoxHeader {
position: fixed
width: 100%
background-image: blah

This currenty doesn’t work (that I can tell).

August 20, 12h

Mike – “the ability to affect other blocks without using javascript or some such - so that a:hover changes content in a completely different block, for example…”

This isn’t a presentational issue, it’s more a part of a page’s behaviour, and so is suitably achieved with JavaScript.

For my money, I’d like to see a ::first-word(n) pseudo-element, which would be useful in creating the ‘first few words of an article in small-caps’ effect so common in print, and currently only achievable by wrapping a span around the first few words of your opening paragraph, since typically you don’t want the effect to continue for the whole of the ::first-line.