Wednesday, 4 November 2009

CSS Gradient Syntax

We landed support for a form of CSS gradients on trunk a while ago, but we got considerable feedback that our syntax --- which was an incremental improvement of Webkit's syntax, which basically exposes a standard gradient API in the most direct possible way --- sucked. A bunch of people on www-style got talking and Tab Atkins produced a much better proposal. Since we haven't shipped our syntax anywhere yet, dropping it and implementing Tab's syntax instead was a no-brainer. So Zack Weinberg, David Baron and I did that (using a -moz prefix of course), and today it landed on trunk. It should land on the Firefox 3.6 branch shortly. It's unfortunate to land something new like this after the last beta, but in this case, it seems like the right thing to do instead of shipping CSS gradient syntax that we know nobody wants.

This does mean that anyone who's currently using -moz-linear-gradient or -moz-radial-gradient on pages is going to find that their syntax doesn't work anymore. Hopefully that's not too many people yet.



Posted by Robert at 1:21 PM
Labels:

10 comments:

  1. I'm using a couple of gradients, but that's no problem to adapt. It will most likely be skin writers who will have to adjust a lot of gradients, but I'm totally for changing the syntax--it truly is bad. I've never used something so complicated and unforgiving in CSS. The fact you can't specify the gradient height in the points (only 0 or 100% allowed) means you have to use background-size and position to make a 100px high gradient attached to the bottom of an element.
    I don't like the idea of having separate declarations for repeating gradients, I would instead suggest that if the first parameter is "repeat", then the gradient will be repeated.
    ReplyDelete
  2. Damn, that sucks that some of my pages are broken now. But I agree that the new syntax looks much better, so thanks for being so quick to drop the old way.
    ReplyDelete
  3. I would also prefer a parameter to specify whether the gradient repeats. Ideally it would be optional (defaulting to no-repeat), but otherwise would take [no-repeat|repeat|reflect].
    Note that I've added "reflect" there. Whichever approach is taken, whether a new parameter or the addition of reflected-linear-gradient() and reflected-radial-gradient(), I think that reflected gradients are well worth adding. Reflected is like repeated, but the stops are reversed in each iteration such that the end stop of the first iteration is the same as the start of the second.
    I do quite a bit of work in SVG using Inkscape, and find I use the reflected gradients far more than the repeating gradients.
    ReplyDelete
  4. Is this the syntax implemented in Fx from now on? Currently the old syntax (webkit-like) works - is that to be phased out in favour of this one?
    ReplyDelete
  5. Robert O'CallahanNov 6, 2009 12:50 AM
    Rich: It is implemented on trunk, and it will appear on the 3.6 branch in a day or three.
    MarkC: you can at least do "reflect" by just repeating the gradient stops backwards.
    ReplyDelete
  6. Yes, I can do my own reflected gradients - but that then requires me to keep both halves in synch if I make any changes. It's not difficult, but it would be nice if I didn't have to think about it.
    In the longer term, whilst linear and radial gradients are a huge improvement over no gradients at all, it would be great to have other gradient types available. I can see immediate uses for "square" gradients ('picture frames' whose colours can be changed programmatically) and four-point gradients (set the four corner colours and the background is interpolated automatically).
    And there are other gradient types: although I can't foresee any personal need for conical or spiral gradients in CSS backgrounds, I'm sure someone else could make use of them - hypnotic Austin Powers time machine animations, for example ;-)
    ReplyDelete
  7. New syntax is great!
    BWT, people: You can use both old and new syntax. Browser will parse the one it understands, and skip the other one.
    ReplyDelete
  8. I like the new syntax very much! Can't wait until a certain group of sluggish devs in near seattle get around to adopting it:)
    ReplyDelete
  9. Love the new syntax - it gets rid of a lot of unnecessary clutter. And migrating was easy - just one big regular-expression find-and-replace. :-D
    ReplyDelete
  10. I had my shares of trouble with Gradient style CSS. Thanks to this syntax, I can navigate better so thanks.
    ReplyDelete

Subscribe to: Post Comments (Atom)