Fwd: Property to disable SVG filters


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.

  <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" />

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).


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