Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 something. I think it should be explicit that negative width/height are allowed on the rect methods (which appears to be the case based on my reading) Is the current text not explicit enough? The behaviour of inf and NaN arguments is undefined for any of the path functions. There's a paragraph near the top of the 2D context section now that explains this in general for all methods. I would think the a 0 dimension in the source rect for drawImage, and the like should fail silently, but i need to check what existing implementations actually do. Unfortunately I don't really know what the best behaviour would be in these cases -- i tend to prefer failing silently, but i think we should at least look at what existing implementions already do. Do let me know if you think the spec should change. Finally, although only tangentially related, i think we should provide the ability to selectively blit only a subregion of an ImageData object. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 something has to be decided for Infinity -Infinity and NaN for all of those. I don't have a strong opinion on it either way, although I would prefer it to be decided quickly so we have some time to propagate the changes in time for Opera 9.5. Are there any undefined cases you think should be defined? (The spec has changed significantly in recent days to cover many holes.) It's looking good, just a few more comments All the transform operations define the behaviour if given inf, but not NaN The behaviour of inf and nan arguments is undefined for arguments to the gradient constructors and shadow offsets. I think it should be explicit that negative width/height are allowed on the rect methods (which appears to be the case based on my reading) The behaviour of inf and NaN arguments is undefined for any of the path functions. I would think the a 0 dimension in the source rect for drawImage, and the like should fail silently, but i need to check what existing implementations actually do. Unfortunately I don't really know what the best behaviour would be in these cases -- i tend to prefer failing silently, but i think we should at least look at what existing implementions already do. Finally, although only tangentially related, i think we should provide the ability to selectively blit only a subregion of an ImageData object. --Oliver -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 to an extent agree with him) the Firefox 3 nightlies do not appear to have adopted this behaviour, leaving us in a position where we have to choose between compatibility and compliance which is awkward. Firefox 3 has now fixed this. The second problem is that the rules for drawing rects/adding rects to the path require us to throw an exception on negative width/height, once again Firefox 3 does not match this behaviour, putting us in a position where we need to choose between compatibility and compliance. In this case however it is relatively easy to make the argument that an exception should _not_ be thrown, as it means webapp developers either need to litter their code with exception handlers or add significant logic to ensure that their apps do not unexpectedly terminate. Fixed in the spec (defined by the operations x+w and y+h). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 -- that is, the functions that take x,y,w,h would be defined to create a rectangle with its two corners being (x,y) and (x+w,y+h), regardless of the sign of w/h I've gone through the canvas API and defined this behaviour for all methods that took rects of one kind or another. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 -Infinity and NaN for all of those. I don't have a strong opinion on it either way, although I would prefer it to be decided quickly so we have some time to propagate the changes in time for Opera 9.5. Are there any undefined cases you think should be defined? (The spec has changed significantly in recent days to cover many holes.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 nan -- but that's just because i'd prefer people to not have to litter their code with exception handlers and/or manual bounds checks -- given i assume most people will just be either ignoring (by catching) exceptions, or make the call conditional on manually checked values being safe it seems reasonable to offload such tasks from the developer to the interpreter. ramble OTOH, there are things like putImageData, drawImage, ... where it makes sense to throw if you are (for instance) not given correct *data* -- things like nan, inf, etc can occur as an edge case of many trivial expressions which make it difficult to check all scenarios for sane output, but it seems truly bogus for something of a completely incorrect type to be passed as say the image or ImageData arguments. /ramble --Oliver On 31/01/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 something has to be decided for Infinity -Infinity and NaN for all of those. I don't have a strong opinion on it either way, although I would prefer it to be decided quickly so we have some time to propagate the changes in time for Opera 9.5. Are there any undefined cases you think should be defined? (The spec has changed significantly in recent days to cover many holes.) -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 behaviour defined in hmtl5. This means that those browsers that match the current draft (eg. Safari 3 and Opera 9.x) fail to render these websites correctly. How hard would it be to get those sites fixed? If there are problems in something like PlotKit or Reflection.js, which lots of people copy onto their own servers, then it would be a pain to break compatibility. If it's just sites like canvaspaint.org where there is a single copy of the code and the developer still exists and can update it, it seems a much less significant problem to break compatibility. I've only seen it on major sites -- it just appears that FFX3 is unlikely to be updated to match the correct behaviour, which is worrying in terms of compatibility. Certainly I would prefer that FFX behaviour was fixed as the spec'd behaviour is much more technically sane. 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 is basically calling beginPath() after calling fill/strokRect etc.) Unfortunately it isn't really an edge case as it's a relatively common occurance -- people expect that the rect drawing function (for example) will clear the path, so expect clearRect (myCanvasElement.width, myCanvasElement.height) to clear the rect and reset the path, and other similarly exciting things :-/ Firefox also resets the path on drawImage and putImageData, unlike Opera and Safari 3 - do people depend on that behaviour too? That honestly never occurred to me :-O I can't see why people would expect it to, but i wouldn't have thought they'd think that about fill/strokeRect :-/ 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 certainly fix it, and it sounds like that would be the best way to go. - Vlad
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 certainly fix it, and it sounds like that would be the best way to go. 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 -Infinity and NaN for all of those. I don't have a strong opinion on it either way, although I would prefer it to be decided quickly so we have some time to propagate the changes in time for Opera 9.5. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 is basically calling beginPath() after calling fill/strokRect etc.) I believe that fixing Firefox/Gecko to match the spec is the best solution. Safari 3 beta has already shipped with behavior that conforms to the spec, with substantial developer evangelism about this issue. (See, e.g., this recently published tech note: http://developer.apple.com/technotes/tn2007/tn2177.html#CANVAS) . Reversing the spec, and re-reversing our course to return to Safari 2 behavior, would be terribly confusing. (I'm not even sure that it's possible at this late hour.) Thanks, Geoff
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 and resize the rect repeatedly. 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 to an extent agree with him) the Firefox 3 nightlies do not appear to have adopted this behaviour, leaving us in a position where we have to choose between compatibility and compliance which is awkward. For Firefox 3, there is a patch in our bugzilla, at https://bugzilla.mozilla.org/show_bug.cgi?id=296904 that could fix this issue -- that is, strokeRect/fillRect/drawImage would no longer reset the current path. However, I'm confused by your comment -- Firefox 2 and current Firefox 3 trunk's behaviour is identical, as far as I know; that is, the current path is being reset on strokeRect/fillRect. (Did you mean due to the context path being cleared ...?) Given that this is somewhat of an edge case, would it make sense to alter the spec here? The second problem is that the rules for drawing rects/adding rects to the path require us to throw an exception on negative width/height, once again Firefox 3 does not match this behaviour, putting us in a position where we need to choose between compatibility and compliance. In this case however it is relatively easy to make the argument that an exception should _not_ be thrown, as it means webapp developers either need to litter their code with exception handlers or add significant logic to ensure that their apps do not unexpectedly terminate. The possible responses to drawing a rect with negative dimensions are (excluding the unappealing exception behaviour currently defined) to cull/ignore them (as we do with 0-sized rects), to normalise them (the current behaviour of firefox, and the behaviour expected by those apps that are affected by it), or to normalise them and treat the negative dimensions as an implicitly reversing the winding direction. Both Opera and Safari 3 match the specification behaviour in both these cases, which results in multiple sites failing to render. 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 -- that is, the functions that take x,y,w,h would be defined to create a rectangle with its two corners being (x,y) and (x+w,y+h), regardless of the sign of w/h, but I would be ok with making such rectangles also be ignored. It's also fairly easy for authors to implement their own versions of strokeRect/fillRect with any of these semantics (well, harder if they were to preserve the current path). This is less of an edge case than the previous issue, IMO, so we should try to figure out what the most useful (and most straightforward) thing is to happen here. I think that it would be important to ship compatible canvas implementations in the next versions of Firefox, Safari, and Opera; so if we have to break existing users to do so, I hope that they will forgive us for the compliance bumps and put in workarounds (e.g., to call beginPath() after every strokeRect/fillRect), but it would be better if we could avoid having to do that. - Vlad
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 obvious issues can be shown if you use the draw rect tool and resize the rect repeatedly. 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 to an extent agree with him) the Firefox 3 nightlies do not appear to have adopted this behaviour, leaving us in a position where we have to choose between compatibility and compliance which is awkward. For Firefox 3, there is a patch in our bugzilla, at https:// bugzilla.mozilla.org/show_bug.cgi?id=296904 that could fix this issue -- that is, strokeRect/fillRect/drawImage would no longer reset the current path. However, I'm confused by your comment -- Firefox 2 and current Firefox 3 trunk's behaviour is identical, as far as I know; that is, the current path is being reset on strokeRect/fillRect. (Did you mean due to the context path being cleared ...?) Given that this is somewhat of an edge case, would it make sense to alter the spec here? 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 the current draft (eg. Safari 3 and Opera 9.x) fail to render these websites correctly. Ideally there would be a distinct Path object, that was separate from the canvas context but we can't have everything :D Unfortunately it isn't really an edge case as it's a relatively common occurance -- people expect that the rect drawing function (for example) will clear the path, so expect clearRect (myCanvasElement.width, myCanvasElement.height) to clear the rect and reset the path, and other similarly exciting things :-/ 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 -- that is, the functions that take x,y,w,h would be defined to create a rectangle with its two corners being (x,y) and (x+w,y+h), regardless of the sign of w/h, but I would be ok with making such rectangles also be ignored. It's also fairly easy for authors to implement their own versions of strokeRect/fillRect with any of these semantics (well, harder if they were to preserve the current path). This is less of an edge case than the previous issue, IMO, so we should try to figure out what the most useful (and most straightforward) thing is to happen here. I agree, throwing an exception in this case seems abhorrent and not in keeping with the behaviour of other portions of the canvas api. I quick study would indicate that those websites that assume negative dimensions will work seem to expect normalisation rather than culling, so in the interests of compatibility that is probably the best approach of the available options. I think that it would be important to ship compatible canvas implementations in the next versions of Firefox, Safari, and Opera; so if we have to break existing users to do so, I hope that they will forgive us for the compliance bumps and put in workarounds (e.g., to call beginPath() after every strokeRect/fillRect), but it would be better if we could avoid having to do that. Agreed. In the latter case this seems trivial as almost anything other than throwing an exception seems to be a technical improvement and the alternatives (including retaining old behaviour) all seem equally reasonable. In the case of the former i'm not sure what the best solution is, i think that resetting the path only on beginPath() seems to be a much more sensible behaviour, but that does clash with a reasonable number of existing sites :( - Vlad --Oliver
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 the current draft (eg. Safari 3 and Opera 9.x) fail to render these websites correctly. How hard would it be to get those sites fixed? If there are problems in something like PlotKit or Reflection.js, which lots of people copy onto their own servers, then it would be a pain to break compatibility. If it's just sites like canvaspaint.org where there is a single copy of the code and the developer still exists and can update it, it seems a much less significant problem to break compatibility. Unfortunately it isn't really an edge case as it's a relatively common occurance -- people expect that the rect drawing function (for example) will clear the path, so expect clearRect (myCanvasElement.width, myCanvasElement.height) to clear the rect and reset the path, and other similarly exciting things :-/ Firefox also resets the path on drawImage and putImageData, unlike Opera and Safari 3 - do people depend on that behaviour too? --Oliver -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] Compatibility problems with HTML5 Canvas spec.
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 hmtl5. This means that those browsers that match the current draft (eg. Safari 3 and Opera 9.x) fail to render these websites correctly. How hard would it be to get those sites fixed? If there are problems in something like PlotKit or Reflection.js, which lots of people copy onto their own servers, then it would be a pain to break compatibility. If it's just sites like canvaspaint.org where there is a single copy of the code and the developer still exists and can update it, it seems a much less significant problem to break compatibility. I've only seen it on major sites -- it just appears that FFX3 is unlikely to be updated to match the correct behaviour, which is worrying in terms of compatibility. Certainly I would prefer that FFX behaviour was fixed as the spec'd behaviour is much more technically sane. Unfortunately it isn't really an edge case as it's a relatively common occurance -- people expect that the rect drawing function (for example) will clear the path, so expect clearRect (myCanvasElement.width, myCanvasElement.height) to clear the rect and reset the path, and other similarly exciting things :-/ Firefox also resets the path on drawImage and putImageData, unlike Opera and Safari 3 - do people depend on that behaviour too? That honestly never occurred to me :-O I can't see why people would expect it to, but i wouldn't have thought they'd think that about fill/strokeRect :-/ --Oliver -- Philip Taylor [EMAIL PROTECTED]
[whatwg] Compatibility problems with HTML5 Canvas spec.
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 repeatedly. 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 to an extent agree with him) the Firefox 3 nightlies do not appear to have adopted this behaviour, leaving us in a position where we have to choose between compatibility and compliance which is awkward. The second problem is that the rules for drawing rects/adding rects to the path require us to throw an exception on negative width/ height, once again Firefox 3 does not match this behaviour, putting us in a position where we need to choose between compatibility and compliance. In this case however it is relatively easy to make the argument that an exception should _not_ be thrown, as it means webapp developers either need to litter their code with exception handlers or add significant logic to ensure that their apps do not unexpectedly terminate. The possible responses to drawing a rect with negative dimensions are (excluding the unappealing exception behaviour currently defined) to cull/ignore them (as we do with 0-sized rects), to normalise them (the current behaviour of firefox, and the behaviour expected by those apps that are affected by it), or to normalise them and treat the negative dimensions as an implicitly reversing the winding direction. Both Opera and Safari 3 match the specification behaviour in both these cases, which results in multiple sites failing to render. Cheers, Oliver
