CSS Wishlist

CSS-Wishlist.md

CSS Wishlist

Pseudo elements

• Allow them to be animated (already works in Firefox, soon also in WebKit).
• Allow more than 2 pseudo elements. Maybe we don't need it if Web Components will come.

Pseudo selectors

• Once an element has display: none, it shouldn’t affect first/last-child and other pseudo selectors. Or maybe it makes sense to add something like display: removed. It would behave like when that element is removed from the DOM aka make pseudo selectors ignore them. Use case: When you temporarly wanna remove items in a list, see demo, but keep the design intact.

Mouse

• Allow mouse click areas be any custom shape, not just the element's bounding box. Like image maps. Maybe by using an SVG shape like hit-area: url(shape.svg);? Note: Often the alpha level would be ok, but not always. For example a tree that has lots of tiny branches needs a hit area that doesn't have small holes in it and rather a more even shape around: http://cl.ly/EulM

Using SVG ClipPaths might be a good work-around: http://labs.sawyerhollenshead.com/lab/svg-clippath/

Transforms

• Allow to break apart transforms like transform-scale:.5; transform-rotate:90deg; so that for example in a keyframe animation, the scale doesn't also need to be repeated if it stays .5 the whole time. There is the problem of order, maybe allow a separate order property like transform-order: scale, rotate; Use case: https://tinker.io/aec25 See how I had to repeat the translate in the random-shake animation. Also, what if I wanna animate translate and rotate individually?

Effects

• Allow inset text-shadow. Syntax could be the same as for box-shadows: text-shadow: inset 0 0 4px 2px black;. Use case: Pretty complicated (WebKit only) workaround: http://cssdesk.com/vWq4t.

Animation

• Allow to toggle display:none together with other transitions like opacity, transforms.
• Multiple easing points and not just start and end. So you can for an example do a bounce.

Media Queries

• Allow media-queries on a per element basis. Currently they only take effect on the whole browser window, but what if you wanna resize just a single element and have its children respond to that change? Maybe something like element:media(max-width:500px) { ... }? Use case: http://filamentgroup.com/examples/rwd-table-patterns/ (imagine it in a resizable side panel). Here a post by Andy with a JS implementation.
• Or an overflow media-query. Similar to text-overflow, we could change the styling as soon as an element's children starts to overflow. Great for Responsive Design. Use case: http://jsfiddle.net/simurai/E387E/ There is an overflow event in JS which might be used for a polyfill.

SVG

• Implement SVG fragment identifiers in background images. (Already works in Firefox, WebKit is still debating). Would be very useful for stacking SVG icons, see SVG stacks. We wouldn't need to fiddle with the offsets in sprites and still could load them with just a single request.

Units

• An aspect ratio unit. So you could do something like width:300px; height:0.5ar; (ar = aspect ratio). This would have the effect that the height is 50% of that element's width. You could create all kinds of responsive containers that keep aspect ratios while being resized. There is the "padding hack", but it doesn't work when the height should be 100%. Here a hack that works, but only in Chrome.

Math

• Random numbers in CSS! Currently transitions/animations all look pretty static/robot like when used on natural objects. Random numbers could make movements that slightly change in values more natural looking. You could pass in a range between two numbers like opacity: random(.5, 1); resulting the opacity be something between 0.5 and 1. Or transform: translateX( random(50px, 100px) ); moving the element between 50px - 100px. Example: https://tinker.io/aec25

Good start!

blending modes?
opacity: .5 darken;
background-color: rgba(130, 60, 200, .8 multiply);

Justification settings would be nice. Word/letter spacing limits and keep options to go with the hyphenation settings would be awesome.

Opentype support as well as stylistic set selection and proper small-caps.

Better pseudo element functionality would be awesome. FireFox seems to have a lot of bugs with pseudo elements and padding, although I haven't tested in 9.

Yeah, blending modes would be nice. And I see you're into type stuff. ;-D

I'd really love color: gradient()!

@Ps0ke Yess.. Or better support for background-clip: text.

• The pointer events stuff (in Mouse) is coming soon. Most game developers want it, so it will likely be in soon and likely use alpha transparency to indicate which are hit target areas or not.
• The transforms problem is a more universal problem, same with multiple backgrounds, box-shadows, text-shadows, etc. Essentially all the new properties that create multiple instances based on multiple sets of values they get. There is sadly no proposed solution so far.
• Inset text-shadows should be possible, have you proposed to www-style? :)
• The display: none issue, Opera had an interesting solution, which was to use display and opacity in tandem. So display would fire immediately but the opacity will ensure the slow fade in would occur. Sadly I think it was determined this is not the way to go by the WG (or tabled for the future?) and I think we will be changing our implementation soon.
• The media query w.r.t elements is unlikely to happen. What you are asking for is essentially have control over elements based on their property values. @Schepp asked for much a similar thing. What could happen is there could be a pseudo-class attached to indicate an element is transitioning or something and then you use the value to do something? But this is too deep into CSSOM territory in my view.
• Math is already possible with Sass/Compass! :P I suppose this could be useful, but given I have existing solutions, I am not too crazy on having it in CSS (and causing even more performance nightmares!). I think variables draft is a start in this direction.
• Vendor Prefixes+!!!?!! At best they should go away, personally, I would completely be anti-any more vendor prefixing :)

+1 on @nimbupani's vendor prefix opinion :)

@danielfilho @nimbupani Yes yes.. I know, it would be bad.. then people might just target the shiny iPhone only, but what should we do in the case of different implementations/bugs between Safari/Chrome like in this case: http://jsfiddle.net/simurai/TaZUA/ Would it be ok to use UA sniffing for this edge case? Because feature detection doesn't get you far. Or you might could say it's too early to use this in real production and we just have to wait till either changes their implementation?

@nimbupani And some more comments with use cases:

• Hit Area. Good to hear, but don't forget.. alpha alone could be problematic for things that have lots of holes in it. Like a tree: http://cl.ly/EulM It needs a custom definable shape (SVG) otherwise when you hover over the tiny branches, you get constantly mouse over/out events.
• Overflow media-query. I ran into a need when using Flexbox http://jsfiddle.net/simurai/E387E/ because its children don't collapse (which is great), but then we need a way to react to the overflow, otherwise the layout is broken (hidden navigation). One simple solution is to use 'overflow: auto' which just adds a scrollbar, but could be handled in better ways too.
• Math (random numbers). I'm talking more about random numbers that keep changing at run time. Like in a keyframe animations https://tinker.io/aec25/, or for example change to a ramdom number on every :hover or so instead of the static authored value.

Allow [pseudo-elements] to be animated (already works in Firefox).

This is already allowed. Up to browsers to implement.

Allow more than 2 pseudo elements.

There are already more than 2 pseudo-elements. Do you mean add more structural pseudo-elements to be generated for elements? There is/was a spec with those proposals (e.g., ::outside, ::before(2), ::before::before), but last I heard there was little vendor interest in implementing it and it is being revised to help encourage future implementation.

Allow to break apart transforms

This has also been discussed on the mailing lists before. Not just for transforms but for many properties, like adding an extra box-shadow or background-image without having to re-specify them all. Seems like a tricky problem to solve but people know it is an issue.

Animations.

Toggling from auto values (e.g. height) would also be useful (and has probably been discussed on the lists)

Allow media-queries on a per element basis.

These would be useful for components. It's been discussed on the mailing list before afaik (and the idea repeated in different forms, e.g., http://blog.andyhume.net/responsive-containers), but could do with some more momentum.

How about a way to stop CSS transitions in progress, instead of having to overwrite them?

Fucking variables and nested selectors finally, so we would have a start, and a hope that some day - when all the shitty browsers die - our children will find CSS preprocessors useless... fuck

Also, with CSS animations being more efficient/faster than doing the same thing with JavaScript, we are entering a state when doing things the fastest possible way leaves us without proper/reliable "on animation over" callbacks in JavaScript...

I'm still waiting for boring old stuff like vertical center, center float. Columns to be standardized and to actually work. There are so many basic layout concepts not easily available or not properly available with css.

The whole back and forth between JS & CSS for animation feels like such a mess.. and the only reason we put up with it is because of Apple. Give us JS hooks for accessing the GPU-friendly CSS3 frames so we can actually create something dynamic in the browser, without writing prescriptive + linear css.

If its not already standardized, the webkit-mask thing (allows us to do gradient text) would be nice too. I definitely agree with the original list though.

@NuckChorris +1 for masks. Finding them extremely useful. Also for using SVG as masks.

Ideally a mask would just be a second image with alpha, so it could be SVG, PNG, or GIF. I could see a lot of potential awesome here.

+1 on random numbers, too

I would love to see an aspect-ratio-property. Something like this:

Values: auto | inherit | maintain | [<rel-width> <rel-height>]
Initial value: auto
Applies to: block elements and inline-block elements
Inherited: yes

block.element {
  aspect-ratio: 16 9;
}

aspect-ratio can take a keyword or two numbers as argument. The valid keywords would be auto, inherit and maintain.

• auto the initial value of all block elements, and is the same as no aspect-ratio value
• inherit will inherit the aspect-ratio of the closest parent where aspect-ratio is not auto, or, if all parents are auto, the element will be auto as well
• maintain will keep the aspect-ratio the element gets on page load
• [<rel-width> <rel-height>] specifies an aspect-ratio in relative numbers, I.E. aspect-ratio: 4 3; with width: 400px; would result in a height of the element equal to 300px.

1. If one of css properties width or height is set (not auto), that value would be used to calculate the other.
   If an element with the aspect-ratio property set, has a width value of auto and a height value set in percent (or other relative unit), the height should be calculated from the closest parents height. So if closest parent is 50px high, and our element has aspect-ratio: 2 1; and a height: 100%;, our element dimensions would turn out to be 100px wide and 50px high.
2. If neither css property width nor height is set on the element (both is auto), the aspect-ratio would work the same way as background-size: contain, I.E. aspect-ratio is maintained, and whatever relative value of the aspect-ratio-property that first would be equal to 100% of the parent element corresponding property, would be used as the base for calculating the other. Above mentioned value calculation regarding height values in percent (or other relative units) comes into play here as well.
3. If both css properties width and height are set on the element, aspect-ratio has no effect.

Also, a specification for different accessibility properties wold be nice to have access to in the css, so we could get rid of some hacks and accessibility-inline-styles (aria-hidden=true).

And a semi value between visibility: hidden and display: none, likely to become a value of the display-property:

.accessibility {
  display: no-layout;
}

.aria-mute {
  aria-visibility: hidden;
}

button {
  width: 20px;
  height: 20px;
  color: #fff;
  border: 1px solid #fff;
  border-radius: 50%;
  background-color: transparent;
}

<button><span class="accessibility">Close list of stores</span><span class="aria-mute">╳ </span></button>

This would render a round button with the familiar "╳" and a white border, read by the screenreaders as "Close list of stores".