Re: [whatwg] Canvas normalize rect() and strokeRect()

On Apr 6, 2014, at 3:23 AM, Rik Cabanier <cabanier@gmail.com> wrote:

> 
> 
> 
> On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> Hi,
> 
> I looked at the behavior of negative width or height for the rect() and strokeRect() functions.
> 
> All browsers normalize the passed parameters for strokeRect() to have positive width and height.
> 
> strokeRect(90,10,-80,80) —> strokeRect(10,10,80,80)
> 
> http://jsfiddle.net/za945/
> 
>> It also seems that only firefox is following the spec [1] when width or height are 0: http://jsfiddle.net/za945/2/
>> I'm unsure why such a rectangle is defined as a straight line. 

You mean you would rather let it draw a one dimensional rectangle? So for the dimension that is not zero, you would see two overlapping lines + the 0 dimensional sides?

That seems indeed to be the case for IE, Safari and Blink: http://jsfiddle.net/Gh9XK/

>  
> Just WebKit seems to normalize for rect() as well:
> 
> http://jsfiddle.net/VT4MG/
> 
> The behavior of normalizing is not specified. Especially it seems odd that the behavior for fillRect()/strokeRect() should differ from rect(). So we should either normalize for all functions or don’t do it for all IMO.
> 
> Note: fillRect() and clearRect() are not affected. The behavior for rect() is important for filling with different winding rules as well. It is not just stroking with dash arrays that is effected.
>  
>> yes, the spec needs to say "in that order" as it does for fillRect and strokeRect.

Ok, that means you would be in favor not to normalize. Again, all current browser normalize and do NOT draw “in that order” for fillRect() and strokeRect(). That means you would require to give up the currently interoperable behavior.

Greetings,
Dirk

> 
> 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrect

Received on Sunday, 6 April 2014 06:01:28 UTC