CSS Canvas Drawing
Posted by Dave Hyatt on Thursday, April 17th, 2008 at 11:33 amCurrently the set of images you can use from CSS consists of the following:
Bitmap Images (PNG, GIF, JPG)
SVG Images
Gradients
A notable missing ability when compared with explicit DOM content is programmatic drawing into CSS images. The <canvas> element represents a foreground bitmap image that can be drawn into programmatically, but – aside from inefficient hacks involving toDataURL – there hasn’t been any way to draw into the image buffers used by CSS images.
Until now!
In the latest nightlies, you can try out a new feature: the ability to specify named image buffers in CSS and then to draw into them programmatically from JavaScript. Here’s how it works.
background: -webkit-canvas(mycanvas);
Instead of specifying an image URL, you specify a canvas and an identifier to use for that canvas. The following new API on documents can then be used to obtain a drawing context for that canvas.
CanvasRenderingContext getCSSCanvasContext(in DOMString contextType, in DOMString identifier, in long width, in long height);
There is only one CSS canvas for a given global identifier per document. When you obtain the drawing context you also specify the size. The canvas will not be cleared as long as you repeatedly request the same size. Specifying a new size is equivalent to the kind of behavior you’d expect if you resized a <canvas> element, and so the canvas buffer will be cleared.
All objects that observe a CSS canvas of the same name are sharing that canvas. This means that (similar to how animated GIFs work), you can do animations and have them happen in lockstep on all the clients of the canvas. Drawing changes will be propagated to all clients automatically.
Here is an example:
April 17th, 2008 at 1:35 pm
I’d be very interested in having screenshots of these pre-Safari-build additions to WebKit. I follow these developments, but rarely update to a nightly. Are screenshots something that the Surfin Safari folks might be willing to add to these cutting edge posts?
BTW, you guys are crusing. These are really exciting developments…
April 17th, 2008 at 6:43 pm
Why not just “background: url(#foo)” and a hidden element?
April 17th, 2008 at 8:20 pm
Robert, that violates separation of presentation and content.
That way would be extremely cumbersome to deal with once XBL gets involved. In order to make sure the drawing is presentational, you really need an XBL binding. However, things get weird if you have to reference the canvas inside the XBL document from the original stylesheet. Where would that canvas be? Would it be anonymous content in a template? Then it would get incorrectly cloned. Would you “reuse” the cached XBL document to get to that canvas or would you load it separately?
By making the drawing purely available as JS, it’s easy to put it into an XBL binding without any referencing issues.
April 17th, 2008 at 8:27 pm
This is not being proposed as a standard by the way. (It’s not even clear who it would be proposed to.)
April 18th, 2008 at 11:01 am
While I certainly thing that this is pretty cool, I really do wonder what the point of working on this is. While I know there are some people that would want to use css canvas tools, I really don’t think that this will be a very big segment of the population because it’s a relatively advanced and complicated subject.
On the other hand, HTML5 elements would be hugely helpful to the broader populous. I know you’re already working on them because you have the video and audio tags (which I think are great!), but there are a ton of other elements that would be really useful that you haven’t implemented yet.
How exactly do you guys decide that people are going to work on css canvases, and not HTML5?
April 18th, 2008 at 11:15 am
ctachme, keep in mind that WebKit is not just used in Safari. It is also used heavily in technologies such as Mac OS X’s Dashboard, all over the iPhone, and tons of other specific places. Even though a feature may not be useful to the general browser market, I could definitely see how a feature like this would still be very important to a ton of developers.
April 19th, 2008 at 7:54 am
You could be doing more useful things – like implementing MathML.
CSS Gradients and Canvas Drawings are great, but they’re not standards, so they won’t see much use. MathML is a standard, and is already used widely.
April 19th, 2008 at 12:15 pm
Actually CSS Gradients is (or will be shortly) proposed as a standard, thanks for playing though!
(Also what makes you think Hyatt is even the right person to implement MathML? People *do* have areas they specialize in, you know)
April 19th, 2008 at 11:32 pm
@ctachme, @KarlWa
WebKit is not a centrally planned project. We don’t decree, “these are the new features WebKit hackers will work on, and nothing else”. For one thing, many of our contributors are volunteers. For another, even people like Hyatt who are paid by big companies to work on WebKit, are encouraged to pursue cool new stuff. We like to keep a good balance of fun, innovative things, and more straightforward improvements. So if there’s particular features you want, please file requests, or comment in the particular bugs. But it doesn’t make sense to say “you should do my favorite feature X instead of this other feature Y”. Don’t make it an either-or, just ask for the things you actually want, and you will find we are pretty responsive to web developer requests.
April 20th, 2008 at 11:17 am
What’s the rationale behind not proposing it as a standard, besides not knowing to whom to propose it? Why would we want a potentially useful feature like this if it isn’t going to be used by other browsers? It seems like all the web functionality in WebKit that’s not already a standard or proposed as a standard should be, otherwise it shouldn’t be in WebKit.
April 20th, 2008 at 2:05 pm
@simx. Read the Project Goals detailed on this site. The first goal should make it clear why some features that are added to Webkit will not be proposed as a standard. Webkit is used in many contexts besides a standards compliant web browser and so some non standard features are required to support that.
April 20th, 2008 at 2:46 pm
I don’t know if Hyatt would agree, but if this functionality turns out to be useful, I do think we should propose it as a standard. Right now I think it’s too experimental to really know where it’s going.
April 24th, 2008 at 11:37 pm
Dave, so you consider the scripts that populate the canvas(es) as *not* part of the content?
April 25th, 2008 at 2:11 pm
Robert, ultimately yes. There is no way to achieve that in WebKit today though since XBL doesn’t exist yet.
May 5th, 2008 at 9:05 am
If Canvas and SVG can be expected to work where CSS expects an image, can I expect that to work with -webkit-border-image as well? I am trying this with SVG content in the nightly Webkit (circa 2006-04-04) and not seeing a result. Trying to figure out if I’m doing something wrong, or this isn’t something I should expect to work.