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
