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

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Sun, 6 Apr 2014 07:04:46 +0000
To: Rik Cabanier <cabanier@gmail.com>
Message-ID: <872B4940-A589-46D1-B72B-B302E7FCC1E3@adobe.com>
Cc: WHAT Working Group <whatwg@whatwg.org>

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

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

Firefox has a strange different behavior if dash >= gap. If the gap is smaller it behaves like IE, Blink and WebKit. This also answers your question: Your example renders in IE the same as in WebKit and Blink.

Greetings,
Dirk

> 
> I would be in favor to change the blink/webkit behavior as the specified one makes more sense.
Received on Sunday, 6 April 2014 07:06:04 UTC

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