On Tue, Jul 7, 2009 at 10:52 AM, Hans Schmucker <span dir="ltr">&lt;<a href="mailto:hansschmucker@gmail.com">hansschmucker@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">It may just be me, but I think that the success of Canvas, which is<br></div></div>
way ahead of HTML5 in general, is largely due to the fact that it&#39;s<br>
pretty much standalone. You don&#39;t have to read through hundreds of<br>
pages of other documentation, you just read the Canvas spec and that&#39;s<br>
pretty much it. Same for parties who want to implement it, there&#39;s<br>
virtually no big dependency.</blockquote><div><br>That&#39;s not going to change, unless you want this relatively narrow extra functionality. For those who do, someone can write an SVG-filters-for-canvas tutorial that can ignore most of the SVG spec.<br>
<br>If we duplicate the feature, then someone who&#39;s already familiar with SVG or canvas filters and wants to use the other will need to read twice as much documentation, and try to keep two separate syntaxes for the same feature straight in their head. I think you know that in Firefox we support SVG filters for HTML content, and it&#39;s very useful, so it&#39;s quite likely that advanced Web authors will be learning about SVG filters independent of canvas.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Of course, how you actually implement it (i.e. by sharing code with<br>
the SVG filters) is not even something a spec is supposed to dictate,<br>
you can share as much code as you want as long as the result is what<br>
the spec says.</blockquote><div><br>Yes, but the specs can make code sharing painful or even infeasible if they diverge, even accidentally.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Tue, Jul 7, 2009 at 12:15 AM, Robert O&#39;Callahan&lt;<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>&gt; 
wrote:<br><div class="im">
&gt; On Tue, Jul 7, 2009 at 9:21 AM, &lt;<a href="mailto:hansschmucker@gmail.com">hansschmucker@gmail.com</a>&gt; 
wrote:<br>
&gt;&gt; Also, the SVG model is pretty complex when you include all the ways to<br>
&gt;&gt; cross-reference data. What would happen if a filter would want to load an<br>
&gt;&gt; image? Canvas can&#39;t work asyc, so either the whole call would fail or we&#39;d<br>
&gt;&gt; lock up the browser for ages.<br>
&gt;<br>
&gt; You&#39;d just use whatever image you&#39;ve got, just like SVG filter drawing does<br>
&gt; normally. It&#39;s no different from doing drawImage with a partially loaded<br>
&gt; image.<br>
</div>Is this really useful for Canvas? Partial results are fine when all<br>
you do is filter, but if the filter is part of a larger drawing<br>
routine, then the result could be pretty undesirable. And since<br>
there&#39;s no direct way to check for the status of the resource, all the<br>
Canvas user could do would be trying again and again until it works<br>
should we decide that methods should throw an error if a resource<br>
isn&#39;t loaded yet.</blockquote><div><br>In Gecko at least, the feImage element fires &#39;load&#39; and &#39;error&#39; events like other image elements, and also blocks the document load event while it&#39;s loading, so waiting for it to fully load is easy.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Nope, I meant the filter loading an SVG, loading a HTML via<br>
foreignElement, loading another SVG via iframe, loading an image from<br>
another server. BackgroundImage is of no use for Canvas anyway.</blockquote><div><br>We already have to solve that problem when we support SVG images with drawImage, which is already in the spec (implicitly).<br><br></div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">But do you really want to explain to everybody who wants to use it<br>
that the colorspace is not normal RGBA32, but some strange....<br>
something?</blockquote><div><br>I think we should change the SVG spec so that the default value of color-interpolation-filters is sRGB.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
That the applied rectangle is actually 1.2x the given size<br>
in any dimension?</blockquote><div><br>As I said in my previous email, the SVG working group is already receptive to the idea of changing SVG filters so we don&#39;t clip to the filter region, in which case the filter region (and its -10%,-10%,120%,120% default) can be ignored in most cases.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">There is simply a lot of stuff in SVG that&#39;s meant<br>
for graphics artists, not programmers. The usage would be different in<br>
Canvas from what it is in SVG.</blockquote><div><br>There&#39;s a lot of stuff in SVG that&#39;s meant for programmers too. Some of it&#39;s just not very well done, and will have to be fixed. I think it&#39;s pretty clear programmers are a more suitable audience for SVG filters than graphic artists...<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">&gt; BTW with an HTML5 parser you can write &lt;svg&gt; content directly in HTML, which<br>
<div class="im">
&gt; makes it really easy to write an SVG filter to use with &lt;canvas&gt;.<br>
</div>And suddenly we have another dependency :)</blockquote><div><br>Not a dependency, just a convenience.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
But seriously: What good is<br>
a filter that is supplied somewhere in the document body to a dynamic<br>
graphic. Why would I want to meddle with the DOM, when really all I<br>
want to set is a local property?</blockquote><div><br>In many cases it&#39;s easier to write markup and refer to it than to write code. The goal here is to support declarative filters, after all.<br><br>Rob<br></div>-- <br>
</div>&quot;He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all.&quot; [Isaiah 53:5-6]<br>