<br><br><div class="gmail_quote">On Thu, Jul 9, 2009 at 6:25 PM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;"><div><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="word-wrap: break-word;"><div><div><div>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).</div>
</div>
</div></div></blockquote><div><br>Or making it consistent when the DOCTYPE is set to something.<br></div></div></blockquote></div>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.</div>
</div></blockquote><div><br>I guess I don't understand. I'm new to the list so forgive me but I thought HTML5 was still a working draft and that the canvas tag was part of that draft. How is a draft immutable?<br>
<br>Also, I don't follow the logic here: " 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)."<br><br>I don't see how breaking some very small percentage of Webkit sites, or breaking some very small percentage of Gecko/Presto sites is better than from breaking some very small percentage of sites in all of them to make the function useful and the spec specific.<br>
<br>(1) The number of sites that use cavnas is exceeding small at this point and the number of those that count on negative width and height behavior being one way or the other is and exceedingly small percent of those <br>
<br>(2) breaking some apps is the same as breaking some apps where some #1 is X and some #2 is Y. So what if X > Y if both X and Y are less than 0.000001% of websites.<br><br>Consistency and usefulness should win in this case. There is the chance to make the spec unambiguous and more useful before canvas becomes widely used.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div></div><div><div><br><blockquote type="cite">
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div><blockquote type="cite">
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Image scaling is implementation dependent everywhere else, why would it be spec defined in the case of canvas?</blockquote><div><br>There are 2 issues here I brought up<br><br>1) What happens at the edges. <br><br>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. <br>
</div></div></blockquote><div><br></div></div><div>This is just an artifact of scaling, and you agree below that scaling is implementation dependent.</div></div></div></blockquote><div><br>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.<br>
</div></div></blockquote></div><div>If you believe that to be the case then you can always file a bug at <a href="http://bugs.webkit.org" target="_blank">bugs.webkit.org</a> .</div></div></div></blockquote><div><br>I can't claim it's a bug if the spec doesn't define what the correct behavior is.<br>
<br>Here's a webpage showing the issue.<br><br><a href="http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html">http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html</a><br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div></div><div><br></div><font color="#888888"><div>
--Oliver</div><div><br></div></font></div></div></blockquote></div><br>