[whatwg] Compatibility problems with HTML5 Canvas spec.

[Oliver Hunt]

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