- From: Chris Lilley <chris@w3.org>
- Date: Mon, 17 Nov 2008 15:34:58 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Doug Schepers <schepers@w3.org>, public-svg-wg@w3.org
On Monday, November 17, 2008, 2:59:39 AM, Maciej wrote: MS> The problem scenario is like this: MS> 1) WebKit implements the SVG 'filter' property, but not the Internet MS> Explorer 'filter' property. MS> 2) We will almost certainly never implement the IE proprietary MS> 'filter' syntax, since it is so thoroughly tied to DirectX and we MS> consider Mac OS X a tier 1 platform. That is one reason why the CSS WG refused to standardise it when IE brought it to that group (that and the lack of any technical documentation). (There is more history on this decision and the svg filter property, but I'm not sure its relevant at this point). MS> 3) Some Web content tests the CSS OM for presence of a 'filter' MS> property; if present, it assumes the browser is Internet Explorer, and MS> uses the 'filter' property with IE-specific syntax to control opacity, MS> instead of the standard 'opacity' property. MS> We ran into multiple sites where 3 was true. So the problem is really that there is browser-sniffing code which depends on an inaccurate assumption. This happens from time to time. Early tests for html table support assumed that any browser called 'mozilla' had table support and any browser that was not 'mozilla' did not. The solution would be to make it easy for those sites to update their test: demonstrate how the test fails, create a better test that does not fail, make code snippets that people can copypaste, and blog it. MS> Our solution was to have the 'filter' property present but MS> undetectable to typical if statement checks, using similar techniques MS> to what we use for document.all. >> We should look at exactly how IE-filter is >> being used, and see if we can come up with an effective hack that >> allows both to exist in harmony. I have seen IE filter used on web-based forum software, especially sites aimed at children (e.g. NeoPets). The text entry widget offers assorted glowy colours (as well as text colour, bold, italic, font and font size). It only displays like that on Windows IE, of course. MS> We already have a hack that more or less does that. WebKit's hack is MS> exactly what the ECMAScript working group complained about. I think it MS> would be better to have a name that could be hack-free in the CSS OM. MS> But the hack is not something that is all that hard to live with. It MS> does interfere somewhat with the possibility of SVG content feature MS> testing for filter support. Adding or documentinga good way to checkfor svg filter support via the DO is a much lower impact change than renaming an existing property which is widely and interoperably deployed in authoring tools, viewers and cotent. -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Monday, 17 November 2008 14:35:08 UTC