Inconsistency doesn't lead to no one depending on a behaviour, it
just means sites only work in one browser. Your suggesting would
result in sites being broken in all browsers -- the only options
from here on out are either nothing gets drawn (as in gecko and
presto), or the destination is normalised (as in webkit).
Or making it consistent when the DOCTYPE is set to something.
API behaviour is not effected by the DOCTYPE, only parsing.
Unfortunately you can't change a DOM API that has existed for years to
something contradictory.
Image scaling is implementation dependent everywhere else, why
would it be spec defined in the case of canvas?
There are 2 issues here I brought up
1) What happens at the edges.
The results are VASTLY different now. Unless this works
consistently it would be hard to make canvas graphics work across
browsers and expect get reproducible results. The 2x2 pixel
example I gave, one browser ends up scaling with translucency even
though there is no translucent pixels in the source image.
This is just an artifact of scaling, and you agree below that
scaling is implementation dependent.
I disagree. When I scale a rectangular opaque image I expect
rectangular opaque results. The Firefox implementation does not do
this. If I take a 1x1 pixel image and attempt to use it to cover up
something in another image by scaling it it will not cover up that
other image. Only the very center pixel will be opaque, all other
pixels will be some percentage translucent, showing whatever was
previously drawn on the canvas. That's a much bigger issue than
whether the scaled pixels are blocky or smooth.
If you believe that to be the case then you can always file a bug at bugs.webkit.org
.
--Oliver
