- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Thu, 24 Jan 2008 14:25:29 +0100
- To: www-svg@w3.org
Obviously the problem seems to exist in mozilla and it is impossible to add such a property to the SVG 1.1 recommendation within a week and as a new feature. And even if added to the current 1.2 filter draft this will not help for 1.1 documents using filters. Therefore a property with a prefix like '-moz-filter-rendering' (or a namespace construction) seems to solve the problem for mozilla within a week. And if it turns out, that this is useful in general, this can be added to the 1.2 filter draft without prefix and without time problems. SVG 1.1 already has properties without a corresponding presentation attribute (like font and marker), therefore just to have such a property and no presentation attribute is no new construction even in SVG 1.1. The vendor specific prefix is well defined by CSS and the implementation can be used to test, whether this is useful or not. Therefore I think, this could be a preliminary solution of the obviously existing problem, avoiding unneccessary corruption of documents with undefined/unspecified attributes ... > This worries me, we already have filterRes which can be used to tune > down the quality in exchange for performance. I'm not sure what the > benefit of having a vendor specific css property to (effectively) > just disable filters despite them being otherwise supported by the > engine. > > --Oliver > > On 23/01/2008, at 11:03 AM, Dr. Olaf Hoffmann wrote: > > As far as I understand this, such a property > > '-moz-filter-rendering' can only be used as a > > property for example in an external style sheet, > > the style element or the style attribute, not as > > a presentation attribute? > > > > Another approach would be to use an own > > namespace an the extension mechanism of > > SVG to avoid conflicts and problems with > > undefined attributes. Such an approach > > pronounces, that there is currently no such > > attribute in any SVG version, whatever the > > future may bring. > > There are a few similar things from adobe > > arround using such an extension. > > If it was no problem that adobe used its > > own namespace and extensions, then it > > should be no problem for mozilla too ;o)
Received on Thursday, 24 January 2008 13:32:04 UTC