I have been dying for some Generated Content implementation. Seems like both spec editors and implementors have forgotten about the awesome features of replaced content

1. A new height unit based on the number of lines of content.

Example:
element { min-height: 2lines; }

2. Define a section of a larger image and repeat this in the background.

Example: Image size is 200×200 pixel but I want to repeat just a 20×50 pixel (top left) section of it.
element { background-repeat: repeat(0,0,20px,50px); }

literally meaning…repeat(x-coordinate, y-coordinate, width, height)

Voor CSS variables and Nested selectors I use xCSS.

A thought provoking article and some really interesting comments – thanks.

My favourites:

@drew’s suggestion of inherit:none.

Superior control over text – particularly hypenation and justification (As discussed here but without javascript – http://www.alistapart.com/articles/the-look-that-says-book/)

I’d quite fancy a text stroke

and maybe a text pattern fill where the solid fill of the text is replaced either by a pattern – or even – negative space! – oh to dream :)

Variables were high on my list but I’m probably going to have to consider the use of SASS after the insightful comments by @Rupert.

Mozilla has a nice pseudo-class :-moz-only-whitespace that matches an element that is empty or contains only whitespace. CSS3 does have an :empty pseudo-class but it must be empty of all DOM nodes, include text nodes. I’m sure every designer has come across a need to destroy nicely nested and organized HTML to wrestle white space in empty nodes — it’d be nice if Webkit et all followed suit and it got into the standards.

I have frequent daydreams about the thought of variables in pure (non-JavaScriptified) CSS. Variables = tiny stylesheets.

Universal adoption of the Flexible Box Module would be high up on my wishlist too.

For me, I would want regular expression selectors, with backreferences available for use by the rules inside!

Great round up, Yaili :-)

The thing I have been wanting for ages is some kind of flexible font size control, much like the minimumFontSize property in XCode. This would allow much more flexibility when working with dynamic content, from a CMS or webapp, as well as multilanguage websites.

My second request has already been noted by Drew.

And I’d love some inset box shadows, as well as shadow knock-out beneath a box-shadowed or text-shadowed element.

Heya, Tab Atkins here, member of the CSSWG. Allow me to address each of your requests, arbitrarily reordered to suit my whims:

* CROSS-BROWSER IMPLEMENTATION OF FONT-SIZE-ADJUST
* CALC
* INDENTATION AND HANGING PUNCTUATION PROPERTIES
* TEXT ALIGNMENT AND HYPHENATION PROPERTIES
* IMPLEMENTATION OF THE ::MARKER PSEUDO-ELEMENT

These are all pretty much a matter of time. All of these properties will move through the standards process and be implemented as browser vendors decide to pay attention. So you don’t have to take any particular action, except maybe to bug (with actual bugs, like in their bug tracker) browsers to implement the ones you care about most.

* MORE CONTROL OVER OVERFLOWING TEXT

This is an area where we could really use some use-cases so we can figure out exactly what controls are needed. If you could produce some pictures or samples or whatnot where you would really have liked some auto-generated ellipses, it would be great if you could send them to the www-style@w3.org mailing list.

(It’s also a spec that needs more editor attention – CSS3 is kinda big and we don’t actually have enough editors to work on all of it at once, unfortunately. But it’ll be done eventually.)

* SELECTOR GROUPING WITH -MOZ-ANY
* PARENT SELECTOR

Both of these should show up in Selectors 4, once someone has enough bandwidth to write the spec. I’m pushing for the latter to be a :has-child(selector) pseudoclass.

* MORE CONTROL OVER STYLING FORM ELEMENTS

Tantek is back at Mozilla and has picked up his former editorship of CSS3 UI again. Better control over styling form elements is explicitly one of his goals for CSS UI 4. Expect some stuff to start showing up in this area in the coming year.

* FLEXIBLE BOX LAYOUT

I and Alex Mogilevsky (from Microsoft) are working on a minor rewrite of this spec right now to take it slightly further away from its XUL roots and make it slightly more useful within the context of modern webpages. After that, expect to see more implementations showing up. Fun!

* NESTED SELECTORS
* VARIABLES

Here at Google we’ve got a group putting together a new experimental implementation of variables, along with mixins, namespaces, and selector nesting. That’s why Webkit’s previous variables implementation was removed last month – it was just some cleanup at the start of the project. A spec proposal for the CSSWG should be following soon.

* STANDARDISED COMMENTS

As you say, this isn’t really a CSS issue. We just need a tool to show that adding metadata in a standardized form to your CSS files is useful, and then for that tool to become ubiquitous. Something like Doxygen.

Nice read. I am sad to see how many readers did not know about the stuff Mozilla is pushing.

Open Type Font features is another one that deserves mention.

http://hacks.mozilla.org/2010/11/firefox-4-font-feature-support/

I suspect designers have an Apple bias that makes them overlook stuff not coming first in Safari.

A small nit:

-moz-any(section, article, aside, nav) h1

Should be:

-moz-any(section, article, aside, nav) -moz-any(section, article, aside, nav) h1

To be functionally equivalent to the other example.

Whenever I see mentions of variables and functions in CSS, the use cases for them appear to be identical to a #define in C rather than a genuine variable or function. In other words, what CSS authors are asking for are macros, not variables or functions.

In that case, this problem has already been solved with LESS. You create your macros as a less file and then, just like in C, compile it into a format the browser understands.

This, to me, looks like the ideal implementation and is superior to integrating that functionality into CSS itself. Otherwise, we push the burden of compiling onto the server on each page request or, even worse, the browser itself. You might not think of it as compiling because it is handled for you, but that is what would happen.

Hey Inayaili, I’ve been using text-overflow:ellipsis a lot recently even more so with fluid layouts I do. I would really like to be able to chose x line ellipsis. I didn’t know that webkit have already dabbled at this. Going to have a play in the morning to see what support is like. Thanks.

I didn`t know about this moz-calc() and moz-any() stuff at all.

I`m with you wishing all those features to be massively adopted by the browsers soon :)

Great list. I personally would like a ‘full’ value for height. This could do what you would expect 100% height to do. Though I have to admit the CSS table stuff does this.

It would be great to have ‘//’ create comments for CSS too.

I’d like to have a pseudo-selector that can select the inner text node of an element. Like <code>::text</code> or something.

Thanks Yaili ~~ Very attractive wish list .
especially the calc perperty, I love this “100%height”;
Wish css could support the % height and width that could help us forget the table layout.

I’d like the ability to simply vertically align text in a block element.

I know we can cheat with table-cell but it just doesn’t feel right.

I agree with Inayaili … lack of good typographic control on a websites is a major shortcoming. Thank goodness we can now start to use webfonts with some confidence. It’s just layout which is lagging behind.

Great list. Thank you.

As for the calc() fuction, I believe the given example can be accomplished quite easily with simple css2.1. Usually a fixed-width float and a margin (same size, same direction) will do the trick.

One thing missing from the list (and on top of my own list) is more control over css background images. I would love to make better use of css sprites but until I can somehow dynamically crop a specific part of the image and only show that part css sprites are only useful in borderline cases. I try to make my css as flexible as possible, so hiding other parts of the sprite based on px values is not something I generally do.

I second Drew’s suggestion, but I fear widespread misuse.
People who don’t understand cascading will use it in every declaration.

A mighty fine wish list you have there, and I am really pleased to see the amount of typographic wishes you have made. I know what you mean with dreaming about the < parent selector (I can think of a few instances where that could’ve been useful), but this would defy the cascade, and we would end up just calling CSS simply SS.

@Drew – inherit: none; Beautiful, that isn’t something I have thought about, but yes, that would be immensely powerful.

Great list!

Variables and parent selectors are definitely my top requests.

calc() looks like a much better version of the old IE expression() rule, which was really a way of shoehorning JS into CSS and required JS enabled on the browser. It was messy, but it’s usefulness was there for all to see, so it’s great to see this being revisited.

I have yet to play around with LESS and SASS but it’s fantastic that they are innovating with stuff that will hopefully make it back into the CSS spec.

Always great to see forward-thinkers like Inayaili getting us involved in what ‘could be’, and possibly, ‘should be’.

There are a lot of proposed solutions here that would be an excellent time-saver for designs & developers, and it’s swallow the idea that even if some of these were to start being implemented into browsers, the adoption by the majority would take a long time.

But it’s a nice glimpse of what kind of new features CSS might adopt in future. Thanks, Inayaili!

This is a nice list with some good ideas, particularly font-size-adjust, calc() and variables.

I’d like to add, and reiterate JulienW’s comment: vertical alignment vertical alignment vertical alignment vertical alignment! I just can’t believe we are still having to contort ourselves so hideously just to get some vertical centering going on.

Have you seen LESS? http://lesscss.org/ it is a good way to integrate variables in you CSS code. (and saves you a lot of troubles)

Have a Merry Christmas and I hope your wishes come true!

Great comments, and great ideas, keep them coming! :)

@Kevin Dees — You can do that with Less now, not sure about Sass.

@Julienw — That’s a really good idea, it would make my life a lot easier.

@Drew and @Tom — Agreed, and agreed.

@Jordan — It has actually quite good support, surprisingly. I’ve started using it in projects where the audience is mainly web devs and designers.

@A.Nelia — Less is mentioned with great prominence in the article ;)

I definitely agree with the whishlist, and thank you for letting me know about the -moz-any() thing.

My #1 whish is something like -moz-any, something to reduce the duplication and amount of redundant selectors you have to write.

My #2 whish is to make the order in which classes are added to an element matter – to not ever have to use !important.

CSS variables are something I’ve been looking into for one of my new CSS projects. While researching I managed to dig up some interesting information (well, I thought it was) that I thought I’d share with you all.

There’s actually a draft proposal for a CSS Variables spec written by Dan Glazman (W3C CSS WG chair) and David Hyatt (Apple) that was published in 2008.

Apparently, this spec was implemented in webkit but was not enabled in the versions used in Safari or Chrome. Unfortunately, it looks like CSS variables were completely removed from webkit last month – hopefully this isn’t the end of them!

I also found an essay from a W3C WG memeber that highlights some of the negatives of CSS varaibles: Why ‘variables’ in CSS are harmful.

Personally, I like the idea of pre-defining data in CSS but I believe the term “variables” is incorrect. I think “constants” better describes their purpose since their contents cannot be programmatically modified once declared (using something like JavaScript)

Great list, lets home your wishes come true. :D

I’d like transitions to work on :before and :after. Also box-shadows to be able to be manipulated differently (eg: the curled shadows) would be brilliant for adding different shadow effects and being able to keep a fluid layout without it messing up.

I have been using Sass and Compass for one year and I never looked back. Sass gives you variables and calculation, compass has a number of abstracted mixins to deal with cross-browser implementations. It takes one line to get a cross-compatible css3 gradient.

Also, it compiles, so you can pass you css stuff to colleagues who don’t want to use sass.

I know some people see Sass as a ‘developer tool’ in a world of designers, but give it a try, your stylesheet will get shorter, faster to maintain and more optimized when loading.

Davide

what about a crossbrowser support of background-position-x and background-position-y? They would be a great improvement on complex sprite-based design

Great whish list and thank you for writing about moz-any() and moz-calc() as i did not know about.

One thing I’m looking forward to is more control over generated content.

A simple example of this would be:

input:invalid:after { content: ‘ invalid’; }

But we can use generated content on form elements :(

Here’s one thing you can scratch from your wish list: calc() is supported in IE9. Without a prefix. OK, you still can’t use it in WebKit, but I’m sure that’s only a matter of time.

Flexible Box is more problematic, unfortunately. Although implemented in Gecko and WebKit, there are a lot of inconsistencies between the two. Also, the W3C have just announced that the whole module is to be revised; there will be a lot of changes, not least that the names of all the properties will change. There was limited support for Flex Box in an earlier IE9 preview, but that’s been removed – probably because of the proposed changes. This is extra annoying because I just wrote an article about Flex Box for .Net magazine!

Nice list! I would also like to see a kindof “previous”-selector

You have like:

div.left.hideRight + div.right {
display: none;
}

I would like:

div.left – div.right.hideLeft {
display: none;
}

And maybe a “++” and “—” selector for selecting all siblings?

Kind regards

And what about something like this?

img[width>=150]{}

There are attributes that are integers, not just strings.

Nice list, though parent selectors would suffer from serious performance issues:

http://snook.ca/archives/html_and_css/css-parent-selectors

I would looooooooooooooove the CSS3 spec of the attr() function to be adopted. There is so much potential here. There isn’t enough clamor going on about it.

See my post about attr()

Good, non-hack vertical alignment.

More precise letter-spacing control.

Great article. Well said.

As Jamie said, the calc() method seems very similar to the MS expression() rule. But besides the fact that it was vendor-specific, it’s advised not to use it because it’s a horrible performance drag.

For MSIE, the expression was evaluated every time the browser was resized and every time the mouse moved in the browser window. Avoiding the use of these epxressions made Rule #7 of Yahoo’s High Performance Web Site Rules (http://developer.yahoo.com/blogs/ydn/posts/2007/07/high_performanc_6/).

Do we know what kind of performance drawbacks -moz-calc() brings?

Nice article, but there is an error on the section about -moz-any. The correct selector should be:

-moz-any(section, article, aside, nav) -moz-any(section, article, aside, nav) h1 { font-size: 24px; }

One of the things the designers I work with bring up time and time again is typography widows. In this I mean the times when a single word is left in a paragraph or heading. Would be nice to control this better without using some JavaScript hack (such as adding &nbsp; between the last two words).

Note: CSS widows is something quite different and controls page breaks when printing.

I wouldn’t mind a “float: center;” to compliment left and right.

Also, I’ve had a few times where I wished that css could do simple math that looks a bit like this: “width: 100%-.5em;” (when used with a .25em border). That would allow greater control of the box, especially if the margin is set to “0 auto” for centering.

Per your request for variable font-family font stacks. You know you can just use the @font-face property and list your font stack as local() options. Check it out: http://pastebin.com/Z24bjxRX

The :any pseudo class, variables and CSS3 macros are implemented in my CSS pre-processor CSS Crush

I use on all the sites I work on now. Makes writing CSS a much more pleasant experience!

It’s a good article and there have been lots of quality response as well.

I, too, can’t wait for implementation of the calc() function in Webkit.

One thing I’d like to see is greater control of list images (and perhaps some more border styles – why so few?)

The Flexible Box Model just blew my mind. I’ve been looking for something like that for YEARS.

Lars:

I suspect designers have an Apple bias that makes them overlook stuff not coming first in Safari.

I don’t necessarily agree with that – there’s a lot of support for Firefox. I think it’s simply that Mozilla aren’t as good at communicating the cool stuff they’re doing.

I think that the absolute best improvement that could be made to CSS would be a way (a syntax) to specify how a browser should behave when a style is applied.
While some might argue that CSS shouldn’t describe behaviour, this would effectively allow us to get rid of the countless ugly JavaScript hacks used in 99% of the websites out there.

We’ve corrected the @-moz-any()@ example – that was a production mistake, sorry folks. It was correct in Yaili’s original submission.

Tried to make a comment yesterday but something must of went wrong. Looks like Tab did a much better job of some of the things I was going to say.

Back in 2008 they did have some examples of CSS variables in a nightly build of webkit (since been removed as Tab said above).

calc() support is also in IE9 but without a vendor prefix which is an incredibly stupid move by MS (hopefully they correct this to atleast -ms-calc before stable release), it only supports very basic CSS units at the moment (px and ems but not % etc). I did a demo a while back when playing around with it, should work in IE9.

True fact: if you pick up Yaili, turn her upside down and give her a shake, css falls out…

Great article. My personal wants: hanging-punctuation, calc and a parent selector.

Interesting to note the number of typographic wishes. CSS has obviously come a long way in the last year or two on that front but still has some way to go. Great to see Tab responding too.

Maybe one day we’ll be able to use a word processor to style our content and have a ‘save to web’ option… oh hang on, wait… ;)

“CSS compilers such as Less or Sass let you do this already, but not everyone wants or can use these compilers in their projects.”

I’m not sure “can” should be part of this sentence. SASS comes as a Ruby gem and can run on any OS. So unless your paranoid IT department refuses to install Ruby on your machine, there’s really no reason you can’t use it.

How about the ability to comment out single lines of code by just using two slashes “//” like in JavaScript and several other languages?

Very nice Yaili! I’ve recently used text-overflow in my latest project and although it’s not the most ground-breaking of implementations, it adds a nice little touch to a layout.

My only wish would be for webkit to fix their meter display, as it’s broken some of my sites.

Nice list!

The top things in my wishlist would be:
* CSS3 attr() implementation (attr() in CSS3 does so much more than in CSS2: http://www.w3.org/TR/css3-values/#attribute)
* Cross browser calc() implementation
* Allowing CSS functions like attr() and counter() in calc(). I wrote a blog post on this a while ago: http://leaverou.me/2010/09/on-attr-and-calc/.

I’d really love to be able to apply blending modes to transparencies via CSS.

A few simple, often used animations which don’t require lots of parameters would be nice too. Like the default jQuery animations?

I think most of my wishes have been covered, it was fun thinking about the future, I hope these wishes become feasible and not just dreams.

Don’t forget CSS gradients on text.

That, on its own, would create world peace.

The < selector would be really great, but I think this will never (I mean not in the next 10 years) happen, because of the way browsers render the css file. :-(

@Rupert: No, there are actually very good reasons to want proper variables rather than macros. Javascript access, for one. Why should it be easy to set up a var(header-color) in your stylesheet and change it in the CSS, but not in javascript?

Plus, proper variables usually imply the familiar last-wins semantics of CSS, which we like.

Vendor prefixes irk me. I understand why they’re useful, but I think it would be great to be able to tell a browser that you trust it’s implementation of a particular property. E.g.

@browser {-moz-trust: border-radius, linear-gradient;}

Then you’d be able to use the standard declaration.

Of this list, I would most like to see calc() and the parent selector.

calc(), parent selector and variables are my favorites

Most of the time people request a parent selector, it turns out they could have easily solved their problem in a different (CSS) way. Maybe that’s why nobody seems to listen to them.

Just yesterday I stumbled upon a great use case for the parent selector. Suppose you’ve got the following markup. (Which, in my opinion, is the only right way to mark up forms while being able to style them in every way you like. Tables? Definition lists? Ha!)

<div class=“form-row”>
<label>Name:</label><input type=“text” name=“name” />
</div>

Now, if you want to highlight the label along with the input itself when the input has the :focus, you can only rely on JavaScript.

In this case, it would be great to have something like input:focus < .form-row { … }

Maybe the problem is that selectors generally don’t allow parent elements to sit on the right of a child (Some CSS1 grammar stuff you can’t take back or something..?). That’s not an excuse; in this case, you could do the same thing with a pseudo class: .form-row:contains(input:focus) { … }

Is there anything on the W3C mailing list about this topic?

(BTW I haven’t read the other comments.)

Brilliant list. Loving it.

I can perfectly live without all of this (maybe the calc looks promising), but i miss very often floating to bottom (e.g. something like: float:bottom-right; Or even better some way to set position absolute, so that it would not be “removed” from the block, but i could position it anywhere and the text (and anything else) would wrap around it

There are some good mentions of stuff that would be really useful (from everyone[nested selectors, parent selectors, blending/gradients, better text controls]).

It’d be good to see some actually become part of the CSS spec.

I’d like to have:

- Better Selectors/Nested Selectors

- Cross-browser: text rendering & effects

- Browser Selectors
ie-6 #wrapper #header { …
moz-4 #wrapper #header { …
webkit #wrapper #header { …

I’ll have more ideas soon

Wouldn’t it be nice to be able to have some control over individual words, or even letters in a block of text?

I suggest the following syntax:
h1:nth-word(X) {property: value;}
h1:nth-word(X):nth-letter(Y) {property: value;}

Anyone with me on this?

Props Inayaili, this was a great read. Calc(), parent selectors and variables are my top three from this list, although font-size adjust would be nice, too. Typographic control has come a long way in the past few years, so it’d be great to see this trend continue!