- From: Jeff Schiller <codedread@gmail.com>
- Date: Wed, 23 Jan 2008 11:49:41 -0600
- 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 UTC