[whatwg] Canvas rectangles

Ian Hickson ian at hixie.ch
Wed Jan 30 18:21:34 PST 2008


On Sun, 1 Jul 2007, Philip Taylor wrote:
>
> "The clearRect() method ... The fillRect() method ... The strokeRect() 
> method ..." - should say "clearRect(x, y, w, h)" etc, for consistency 
> with all the other function definitions.

Fixed.


> "Shapes are ... subject to ... shadow effects, global alpha, ... and 
> global composition operators" is a bit confusing since clearRect isn't 
> subject to those things. (Actually, clearRect is subject to shadow 
> effects in Safari, and subject to composition operators in Opera, but 
> I'd say those are just bugs.)

Fixed.


> strokeRect: The definition is vague about where line-joins occur, in the 
> normal case and in the "If only one of [width and height] is zero ..." 
> case, since it doesn't really say that it's a closed path.

Fixed as part of the earlier changes to lines and strokes, I think. Is it 
better now?


> There is minor implementation disagreement in the zero-width case 
> (<http://canvex.lazyilluminati.com/misc/rects.html>) - in Safari it is 
> equivalent to drawing a rectangle with infinitesimal width (hence with 
> four line-joins connecting perpendicular edges), whereas in 
> FF/Opera/spec it's equivalent to a line (with two line-joins connecting 
> parallel edges). Also, Safari/FF3 draw stuff in the width=height=0 case, 
> though that's related to the more general line-caps-on-zero-length-lines 
> thing (as in 
> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011883.html>). 
> I believe it would be nice (for consistency and predictability) if 
> strokeRect worked the same as rect+stroke (and the same as 
> moveTo+lineTo+lineTo+lineTo+closePath+stroke) - that is what everyone 
> except Safari does, but it doesn't seem to be explicit or obvious in the 
> spec.

This is basically now the case, I think, but mostly because of the 
changes we made before for zero-length line segments, and so on.


> Perhaps it would be easier and most precise to define strokeRect in 
> terms of existing methods, like: "The strokeRect(x, y, w, h) method must 
> be equivalent to the following sequence of method calls: beginPath(); 
> rect(x, y, w, h); stroke(); except with the current path after calling 
> the strokeRect method remaining the same as before the call."

The "except" is why I don't really want to do this.


Could you take a look again and let me know if you think the new 
definitions work ok? Don't hesitate to tell me that they're still broken. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'



More information about the whatwg mailing list