[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

Received on Tuesday, 25 September 2007 13:26:32 UTC