On Fri, 1 Feb 2008, Oliver Hunt wrote:
All the transform operations define the behaviour if given inf, but not
NaN
Fixed recently.
The behaviour of inf and nan arguments is undefined for arguments to the
gradient constructors and shadow offsets.
Fixed, I believe. Let me know if I missed
On Jan 31, 2008, at 9:35 PM, Ian Hickson wrote:
On Thu, 27 Sep 2007, Anne van Kesteren wrote:
Cool! I suppose that leaves the issue about revisiting throwing
exception for certain members? Are there any member where it does
make
to throw an exception? If we decide not to throw an exception
On Mon, 24 Sep 2007, Oliver Hunt wrote:
The first problem is the repeated drawing of old rects, this is due to
the context path not being cleared by draw rect and fill rect which is
the behaviour present in Safari 2 and Firefox 2. While I've discussed
the issue with Hixie in the past (and
On Tue, 25 Sep 2007, Vladimir Vukicevic wrote:
I agree that throwing an exception is probably unnecessary, as there are very
few other places in the API where such exceptions are thrown (except when the
input is of clearly the wrong type). Normalizing seems to be the most useful
approach --
On Thu, 27 Sep 2007, Anne van Kesteren wrote:
Cool! I suppose that leaves the issue about revisiting throwing
exception for certain members? Are there any member where it does make
to throw an exception? If we decide not to throw an exception something
has to be decided for Infinity
I'll try to look at the updated spec later tonight, and see if i can
see if there's anything for which it seems sensible to me for canvas
to throw (or not throw) left in the spec.
My current feeling is that for most operations it is sane to fail
silently for out of bounds numbers, inf, or
Oliver Hunt wrote:
On 25/09/2007, at 2:19 PM, Philip Taylor wrote:
On 25/09/2007, Oliver Hunt [EMAIL PROTECTED] wrote:
Firefox 2/3 and Safari 2 clear the context's path on strokeRect/
fillRect, this violates the spec -- but there are many websites that
now rely on such behaviour despite the
On Thu, 27 Sep 2007 00:53:51 +0200, Vladimir Vukicevic
[EMAIL PROTECTED] wrote:
Yeah, we do the same thing on drawImage/putImageData that we do no
fill/stroke (because in the underlying code they're all implemented
using paths, and there's just one path :). So, like I said, we can
We can certainly fix it, I'm just wondering what makes the most
sense to do so. Like I said, there's a patch sitting in our
(Mozilla's) bugzilla that implements the spec-compatible behaviour.
I'd be happy to fix it and relnote that it was fixed, while
providing a simple workaround (which
Hi,
Oliver Hunt wrote:
Hi All,
We've encountered a number of website compatibility issues in WebKit due
to our adherence to the new Canvas specifications -- a good example of
this is rect drawing at http://canvaspaint.org
The most obvious issues can be shown if you use the draw rect tool
On 25/09/2007, at 1:26 PM, Vladimir Vukicevic wrote:
Hi,
Oliver Hunt wrote:
Hi All,
We've encountered a number of website compatibility issues in
WebKit due to our adherence to the new Canvas specifications -- a
good example of this is rect drawing at http://canvaspaint.org
The most
On 25/09/2007, Oliver Hunt [EMAIL PROTECTED] wrote:
Firefox 2/3 and Safari 2 clear the context's path on strokeRect/
fillRect, this violates the spec -- but there are many websites that
now rely on such behaviour despite the behaviour defined in hmtl5.
This means that those browsers that match
On 25/09/2007, at 2:19 PM, Philip Taylor wrote:
On 25/09/2007, Oliver Hunt [EMAIL PROTECTED] wrote:
Firefox 2/3 and Safari 2 clear the context's path on strokeRect/
fillRect, this violates the spec -- but there are many websites that
now rely on such behaviour despite the behaviour defined in
Hi All,
We've encountered a number of website compatibility issues in WebKit
due to our adherence to the new Canvas specifications -- a good
example of this is rect drawing at http://canvaspaint.org
The most obvious issues can be shown if you use the draw rect tool
and resize the rect
14 matches
Mail list logo
