W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2014

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Sat, 5 Apr 2014 23:24:19 -0700
Message-ID: <CAGN7qDAD5XEFfHo0+LPoTeK2mLVmW8_qXiOe4XV7uTr_eTAV0A@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: WHAT Working Group <whatwg@whatwg.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:28 UTC