[whatwg] Compatibility problems with HTML5 Canvas spec.

Vladimir Vukicevic vladimir at pobox.com
Wed Sep 26 15:53:51 PDT 2007


Oliver Hunt wrote:
> 
> On 25/09/2007, at 2:19 PM, Philip Taylor wrote:
> 
>> On 25/09/2007, Oliver Hunt <oliver at apple.com> 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




More information about the whatwg mailing list