- From: Jeff Schiller <codedread@gmail.com>
- Date: Wed, 23 Jan 2008 11:44:09 -0600
- To: www-svg@w3.org
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