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

On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> 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?
>

yes

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.
>

I changed your test a bit so you can more easily see the normalisation:
http://jsfiddle.net/za945/3/
Safari and Chrome are doing as you say, but Firefox does not. (I don't have
IE to test)

I would be in favor to change the blink/webkit behavior as the specified
one makes more sense.

Received on Sunday, 6 April 2014 06:24:47 UTC