On Apr 6, 2014, at 8:24 AM, Rik Cabanier <caban...@gmail.com> wrote:
> > > > On Sat, Apr 5, 2014 at 11:00 PM, Dirk Schulze <dschu...@adobe.com> wrote: > > On Apr 6, 2014, at 3:23 AM, Rik Cabanier <caban...@gmail.com> wrote: > > > > > > > > > On Sat, Apr 5, 2014 at 9:01 AM, Dirk Schulze <dschu...@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.
