- From: Rik Cabanier <cabanier@gmail.com>
- Date: Sat, 5 Apr 2014 23:24:19 -0700
- 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