Re: Filter Templates

On Thursday, February 24, 2011, 11:01:51 PM, Alistair wrote:

AM>  I would think it would be quite important to cover the basic
AM> overlay     primitives offered in most graphics packages, such as:
AM>  Screen
AM>  Blend
AM>  Add
AM>  Multiply
AM>  Exclusion
AM>  Dodge
AM>  Hard-light
AM>  Soft-light
AM>  Burn
AM>  Difference (difference is also great for getting visual test     results when comparing builds)
AM>  Etc
AM>  ( I am aware we have some of these filter already available to SVG )

They are in the compositing spec, and we have all of them.
AM>  Could anyone tell me if there has been an update to the way
AM> sources     work for filters on individual DOM elements yet? Last
AM> time I checked     there was no way to execute the following kind
AM> of behavior: (Using     multiple DOM elements as separate sources)

<svg version="1.1" xmlns="">
    <filter id="srcLoadedOverlay">
      <feImage xlink:href="url(#canvas0)" result="img1" />
      <feImage xlink:href="url(#canvas1)" result="img2" />
      <feImage xlink:href="url(#canvas2)" result="img3" />
      <feBlend in="img1" in2="img2" result="blend1" mode="multiply" />
      <feBlend in="blend1" in2="img3" mode="lighten" />

xlink:href takes a URL directly, not wrapped in url().

It would seem reasonable to state in the spec that if a canvas element is referenced by its id, then the graphics state of the canvas is used as the input to the filter. (This already works for svg elements, for example).

Of course this immediately causes same-origin restrictions to apply to the filter.

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Thursday, 24 February 2011 23:17:48 UTC