Fwd: Property to disable SVG filters

Tim,

I agree with Doug, make it a Firefox-specific feature string.  Authors
who want filters should be providing fallback content already, so they
can extend that mechanism.  Feature strings and
requiredFeatures/switch are the way of testing for feature support in
SVG so it makes sense to extend that and not a custom attribute.

<switch>
  <rect fill="#someFilter"
requiredFeatures="http://www.w3.org/TR/SVG11/feature#Filter" />
  <rect fill="#someFilter"
requiredFeatures="http://www.mozilla.org/SVG/feature#Filter" />
  <rect fill="blue" />
</switch>

In this scenario, Firefox 3 should specifically NOT enable the
standard SVG filter feature string (so that authors who aren't aware
of Fx3's poor filter performance don't inadvertently trigger filter
usage in Fx3).

Regards,
Jeff

On 1/23/08, Tim Rowley <tor@acm.org> wrote:
>
> There is some thought that Mozilla's current implementation of SVG
> filters are too slow, and that they should be disabled by default in
> order not to scare content developers from ever using this feature in
> the future:
>
> http://groups.google.com/group/mozilla.dev.tech.svg/browse_thread/thread/807b7c2f75a0b13e
>
> There is also some discussion in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=413588
>
> If we decide to do this, people seem to be gravitating towards the
> proposal put forward by Ken Stacey to add a -moz-filter-rendering
> property as follows:
>
> '-moz-filter-rendering'
>   Value: auto | optimizeSpeed | optimizeQuality | inherit
>   Initial: auto
>   Applies to: container elements, graphics elements
>   Inherited: yes
>
> In Firefox 3, we'd treat auto = optimizeSpeed = pretend we don't
> implement filters and render the geometry unfiltered.
>
> How does the SVG WG and other implementor feel about this?  If it's
> acceptable to the WG, we could remove the -moz- property prefix.
>
> We'd appreciate an answer to this issue soon, as we're about a week
> from code freeze.
>
>

Received on Wednesday, 23 January 2008 17:44:22 UTC