W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Review of 3.14.11. The canvas element

From: Philip Taylor <philip@zaynar.demon.co.uk>
Date: Tue, 21 Aug 2007 18:41:17 +0100
Message-ID: <46CB23BD.1060002@zaynar.demon.co.uk>
To: Mihai Sucan <mihai.sucan@gmail.com>
CC: public-html <public-html@w3.org>

Mihai Sucan wrote:
> 3. The getContext() method should be defined such that any number of 
> additional arguments are allowed, just like toDataURL() is defined. This 
> is forward thinking about initializing various contexts with any settings.

I believe that is already covered by "1.3.1. Common conformance 
requirements for APIs exposed to JavaScript": "Unless other[wise] 
specified, if a method is passed more arguments than is defined for that 
method in its IDL definition, the excess arguments must be ignored."

> 5. Drawing states should be saveable with IDs, and for easier restoring.
> save(id)
> restore(id)
> If id is not provided, then save() works as defined now. The same for 
> restore().
> Currently, it's not trivial to save and restore a specific state.

I think a more convenient syntax would be:
   var state = ctx.save();
But how would it interact with normal calls to ctx.restore()?

I'm unsure what are the cases where you'd want to do non-stack-based 
save/restore and would use restore(id) rather than simply defining and 
calling your own function to set the whole state each time.

> I don't believe it can be argued that such changes break (too many) 
> applications. Today's applications using canvas are experiments. The 
> entire spec is subject to change, and as such nobody should complain.

They're not all experiments - I found 
http://www.city-data.com/city/Hardy-Iowa.html (using PlotKit on canvas) 
Apparently there's Yahoo Pipes too. I've no idea how many other 
non-experiments there are, though.

> 7. On the basis of save()/restore() state, I think it would be a good 
> idea (performance-wise, for various applications), to be able to do 
> something like this:
> saveImage(id)
> restoreImage(id)

That effect should already be possible, like:

CanvasRenderingContext2D.saveImage = function(x, y, w, h) {
  var canvas = document.createElement('canvas');
  canvas.width = w;
  canvas.height = h;
  canvas.getContext('2d').drawImage(this.canvas, x, y, w, h, 0, 0, w, h);
  return canvas;
CanvasRenderingContext2D.restoreImage = function(canvas, x, y) {
  this.drawImage(canvas, x, y);

(untested), which should be sufficiently fast and memory-efficient.

> 9. I would propose something different, a different idea. Why not define 
> an optional method for the 2d context, which allows authors to say 
> something like importNodeRender()? Here's the "funky" idea:
> importNodeRender(node)
> ... where node is any DOM node, e.g. 
> document.getElementById('whatever'). The way "captures" the rendered 
> image of that element, irrespective what it is (maybe it's SVG, Flash, 
> simple HTML+CSS, whatever).
> importDocument(x, y, w, h)
> This method could allow the author to capture a part of the rendered 
> document page. x and y positions are taken from the entire document, not 
> just the visible page, in the current window size.
> [...]
> Would this be overly complex? Popular UAs already have ways to generate 
> page thumbs.

Mozilla has a non-standard drawWindow method, to draw whole Windows into 
the canvas (e.g. for thumbnails), which sounds similar to your proposal. 
It is limited to trusted content (like extensions) for security reasons:

   // We can't allow web apps to call this until we fix at least the
   // following potential security issues:
   // -- rendering cross-domain IFRAMEs and then extracting the results
   // -- rendering the user's theme and then extracting the results
   // -- rendering native anonymous content (e.g., file input paths;
   // scrollbars should be allowed)

as well as issues like rendering cross-domain <img>s or rendering 
<canvas>s that have had cross-domain Images drawn onto them, etc. (I 
don't know if this means it's overly complex or infeasible-to-secure, or 

Philip Taylor
Received on Tuesday, 21 August 2007 17:41:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC