W3C home > Mailing lists > Public > www-svg@w3.org > January 2008

Re: Property to disable SVG filters

From: Jeff Schiller <codedread@gmail.com>
Date: Wed, 23 Jan 2008 11:49:41 -0600
Message-ID: <da131fde0801230949t71dfee79j3a1630151f3e5a06@mail.gmail.com>
To: www-svg@w3.org

To elaborate a little more, the following code deployed in the wild:

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

Would result in a blue rectangle in Fx3 (because Fx3 does not turn on
the filter feature string.

The following code :

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

would result in a filtered rectangle in Fx3 and a blue rectangle in
EVERY other browser.

The following code:

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

would result in a filtered rectangle in any browser supporting filters
as well as Fx3 and a blue rectangle in every other browser.

Regards,
Jeff

On 1/23/08, Jeff Schiller <codedread@gmail.com> wrote:
> 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:49:50 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:38 GMT