miscoded

We've been working away on Opera's SVG support for a while. Recently, integrating SVG-specific CSS properties into the DOM implementation caused an unexpected problem: the "filter" concept in SVG styling and IE's proprietary "filter" suddenly exist in the same namespace - the CSSStyleDeclaration interface. If that was greek to you, here's a translation: in SVG, you can do something like

<circle style="filter: url(#someCoolEffectDefinedOverThere)">

and IE allows you to do something like

<div style="filter: alpha(opacity=50)">

This means that a browser supporting SVG will define element.style.filter - and all versions of IE you want to care about also define element.style.filter. So if you're writing a generic script and see a random element with a style.filter property - how do you know what filter syntax is supported? We discovered this problem due to failing opacity effects - scripts doing

if(typeof element.style.filter != 'undefined'){
 // IE syntax
}else{
 // standards-compliant syntax
}

suddenly saw style.filter defined and started giving us IE-code. Seems Firefox is about to come across those compatibility problems too.. Of course it raises a red flag when we add something that causes new compatibility issues. It has been raised as an issue with the SVG working group, who discussed it and decided to sweep the issue under the carpet with an informative warning in the spec. For compatibility, we're considering hiding style.filter like we hide document.all. That is not a good solution, however. We want scripts to be able to detect that SVG filters can be manipulated from JavaScript, and we want them to do so through good, old, best-practice object detection. Microsoft will actually save us by re-naming filter to ms-filter. That's excellent, if late, and they still have the problem that millions of existing sites use IE-style CSS filters. It would have been the perfect solution had they done it back when their CSS filters were invented.. I still welcome their initiative, but at this point it probably won't make any difference for many years ahead. Right now, we're stuck with confusion. I'm worried that we're breaking established best-practice (object detection) and forcing people down the dirty road of browser sniffing. I think it will be confusing that HTML elements get a "filter" property that will presumably only work when set on SVG elements. Now.. changing SVG's footprint in the CSS DOM wouldn't suffer from legacy content problems. My preferred solution would be to make sure "filter" only appears on the .style object of real SVG elements, and that it's named svgFilter in the DOM rather than just "filter", to make it easier to detect. What do you all think?