[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