- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 8 Apr 2013 16:02:36 +0100
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, "public-fx@w3.org" <public-fx@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Apr 8, 2013 at 3:50 PM, Dirk Schulze <dschulze@adobe.com> wrote: > WebKit supports CSS Masking and SVG Masking, both with the mask property, just that the one for CSS Masking is prefixed. CSS Masking does not support SVG Masking yet and the other way around. There is no security bug, nor will there be one with the suggested interpretation of url(). I do not even see how it would harm the web platform today nor in the future. It just affects the url() function allowing us to combine SVG and CSS in a lot more places then just Masking. It allows a lot more possibilities on all CSS properties like taking SVG gradients and patterns as input on the background and border property. It allows fill and stroke properties to take CSS image values (which the SVG WG resolved already). It allows CSS exclusions to reference SVG shapes and CSS images. > > At the end I think it does not harm the web, it extends the possibilities. I don't really think you're answering any questions here. If WebKit is shipping, how is the "suggested interpretation of url()" relevant? Whether the harm is great or not we can judge in hindsight. However, it seems pretty clear to me that having a different fetching model based upon the fragment identifier in the URL, which exists exactly nowhere in the platform today, is not ideal and will lead to a great deal of confusion. What I could see working: You keep the default "tainted cross-origin" model for url() but do nothing special for fragment identifiers. If the fetched resource is an image, it being CORS cross-origin does not matter. If it is a mask, it does. You then add a way to enable CORS requests using e.g. fetch(url, crossorigin) or some such similarly to how HTML enabled a couple of elements to do just that. -- http://annevankesteren.nl/
Received on Monday, 8 April 2013 15:03:10 UTC