Tuesday, April 15th, 2008

CSS Gradients in WebKit

Category: Browsers, CSS, WebKit

CSS Gradients

Dave Hyatt, the one person I would love to get to TAE to join the other browsers, posted about CSS gradients in WebKit:

  1. -webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*)

So what exactly is a gradient in CSS? It is an image, usable anywhere that image URLs were used before. That’s right… anywhere. :)

You can use gradients in the following places:

  • background-image
  • border-image
  • list-style-image
  • content property

The type of a gradient is either linear or radial.

A point is a pair of space-separated values. The syntax supports numbers, percentages or the keywords top, bottom, left and right for point values.

A radius is a number and may only be specified when the gradient type is radial.

A stop is a function, color-stop, that takes two arguments, the stop value (either a percentage or a number between 0 and 1.0), and a color (any valid CSS color). In addition the shorthand functions from and to are supported. These functions only require a color argument and are equivalent to color-stop(0, …) and color-stop(1.0, …) respectively.

This is great stuff. Think about the image repeating tricks you have had to do just to get some of this behaviour. This is much more elegant.

There are a bunch of examples:

And in conclusion, we have a lot more coming:

WebKit now supports a generic architecture for generated images, making it easy to add new generator effects to CSS in the future (lenticular halos, checkerboards, starbursts, etc.). The rules for sizing of these generated images will match whatever is decided for SVG content with no intrinsic size (the two are sharing the same rules right now).

We encourage you to try gradients out and file bugs if you see any unexpected or weird behavior. They will degrade safely in other browsers as long as you use multiple declarations (e.g., specify the image in one declaration and the gradient in a following declaration).

Posted by Dion Almaer at 12:01 am
11 Comments

++++-
4.3 rating from 33 votes

11 Comments »

Comments feed TrackBack URI

Very nice. Would be cool when the other vendors follow sometime. Until then it’s not really useable yet.

In IE there are the CSS filters which allow gradients through declaration. But this only works for backgrounds and not for borders:
http://msdn2.microsoft.com/en-us/library/ms532997(VS.85).aspx

Still, any idea how this performs when inserting many of them in an interactive applications? There must be some sort of smart caching when these are really dynamically created images as stated in the post.

Comment by wpbasti — April 15, 2008

Nice ideed, the problem with that is, that today Apple/Webkit are starting to add CSS things which are not defined as standard or so. Ages ago that was the behavior of IE and Netscape. Everyone blamed them for doing that. Now all browsers try to be standard conform and now Webkit does this stuff.

Bring up HTML5 fast and CSS3 fast!! That would help.

Comment by Aimos — April 15, 2008

You can emulate this in Opera/Firefox by sticking a under the element you want to have a gradient and drawing the gradient.

Unfortunately, you cannot stick custom CSS properties in a stylesheet and retrieve them through the CSSOM/CssValue interface (none of the browsers I tested would pass these through as type CSS_CUSTOM), rather, they ignore things they don’t understand which is perfectly legal.

I work around this in Chronoscope (http://timepedia.org/chronoscope) by using special URLs like:

background-image: url(http://timepedia.org/lineargradient/0,0/0,1/0/00ABEb/1/FFFFFF )

which are recognized by the Javascipt processing the CSSOM. As a side effect, you can gracefully fail by putting a service at that URL which renders gradients on demand.

Comment by cromwellian — April 15, 2008

“You can emulate this in Opera/Firefox by sticking a under the element ”

ugh, it ate my <canvas> element. :(

Comment by cromwellian — April 15, 2008

Yes Aimos is very right. However nice this feature might be (and NICE it truly is), it does undermine the overall standardization effort. On the other hand, crossing this edge was repeatly a positive force that pushed the market.

But let’s consider opacity – this has been adopted by major browsers years ago – yet we still have to use syntax like moz-opacity: 0.XX, opacity: 0.XX, filter: alpha(opacity=XX)

Personally I would prefer crossbrowser canvas/svg adoption, rather then eyecandy features, that are supposed to help a rather small group of developers (iPhone, OSX widgets) and overall creating just more confusion. :(

Comment by OndraM — April 15, 2008

“Apple/Webkit are starting to add CSS things which are not defined as standard or so. Ages ago that was the behavior of IE and Netscape. Everyone blamed them for doing that. Now all browsers try to be standard conform and now Webkit does this stuff.”

This isn’t really exactly accurate, and this is why I’ve been making a point to advocate for web developers to be more clear in their expression of a need for standards: that is, to demand interoperability, rather than strict adherence to largely irrelevant standards. This shouldn’t really need to be addressed in a community like “Ajaxian”, a community which couldn’t even exist absent non-standard extensions to the standards.

What makes the Webkit team’s actions now different from IE/Netscape actions during the Browser Wars is that there isn’t a race to add new, incompatible features. Instead, there is: three largely standards-compliant browsers, one way behind; the one way behind is the one that’s not only notorious for introducing vast incompatibilities into the web, but still largely unchanged since the Browser Wars; one of the compliant browsers, which happens to lead the pack in almost all ways, is introducing new features which can either be adopted or not, but were they to be adopted by other browsers they would represent de facto new standards. Why? Because the CSS standards process (you’ll notice nearly everything the Webkit team introduces is in CSS) has stagnated and really failed to capture the imagination of pretty much everyone.

Moreover, Apple, Opera and Mozilla *are* building CSS3 and HTML5 support. So we have again from the dev community: unclear, undesirable demands; anachronism; false dilemmas; and a failure to see the benefit of obviously valuable, time-saving, and easily-standardized features that have developers currently spending untold hours approximating, hacking around inconsistencies and bogging down networks.

To web developers: please, support interoperability over blind adherence to standards.

Comment by Trevor — April 15, 2008

@Trevor: The problem is that, in order for Opera and Mozilla to add these features, they now have to reverse-engineer the Safari behavior because these features are not yet specified in any sufficient detail (the Safari blog is only a starting point).

If Apple wants to have interoperable solutions, it would make sense for them to propose these new inventions as standards within the W3C. This is the only way a company like Microsoft would ever consider implementing them (because of the W3C patent policy).

Comment by codedread — April 15, 2008

“Apple/Webkit are starting to add CSS things which are not defined as standard or so. Ages ago that was the behavior of IE and Netscape. Everyone blamed them for doing that. Now all browsers try to be standard conform and now Webkit does this stuff.”
.
You are correct that these are not standards…yet. But they will be. The way these were implemented is in close approximation with the SVG, HTML5, and CSS specs. The specs are still not finalized in these areas, which is why other good browsers (Opera, Firefox) have not adopted them yet, but they will.
.
“@Trevor: The problem is that, in order for Opera and Mozilla to add these features, they now have to reverse-engineer the Safari behavior because these features are not yet specified in any sufficient detail (the Safari blog is only a starting point).”
.
Not at all. They don’t have to reverse engineer anything. This functionality is written into upcoming specs.
.
Read before you comment

Comment by Carbon43 — April 15, 2008

“The problem is that, in order for Opera and Mozilla to add these features, they now have to reverse-engineer the Safari behavior because these features are not yet specified in any sufficient detail (the Safari blog is only a starting point).”

Or they could wait til the feature is stabilized and read the source. Or they could read the source now and get a jump on it. Or they could communicate with the Webkit team.

“If Apple wants to have interoperable solutions, it would make sense for them to propose these new inventions as standards within the W3C.”

As they have done with all but a few Dashboard-only extensions to the standards… when they became stable enough to propose. “Just available in tonight’s build” isn’t really the best time to do that, for anyone concerned.

“This is the only way a company like Microsoft would ever consider implementing them (because of the W3C patent policy).”

Well, on that we have some time. It’ll be at least a version or two before IE adds any of the newer standards. As in, a version or two of Windows.

Comment by Trevor — April 15, 2008

I tend to agree it makes more sense to keep this in SVG/Canvas and follow the standards. However, as far as the code base, it probably doesn’t add many lines adding this feature to CSS, as it’s already written in. So that’s kinda nice.

Following that regards, it would be nice to port some of the SVG features (such as convolution, and color matrix) into canvas.

Comment by mudx — April 15, 2008

I agree with most of you guys here. If we could get the basics working in all browsers first before adding in this stuff that would make my life easier ;)

CSS gradients are sweet tho and would definately be something that we need.

Comment by RichardReddy — April 16, 2008

Leave a comment

You must be logged in to post a comment.