- From: Dirk Schulze <dschulze@adobe.com>
- Date: Mon, 8 Apr 2013 07:33:55 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Bjoern Hoehrmann <derhoermi@gmx.net>, "public-fx@w3.org" <public-fx@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Sent from my iPhone On Apr 8, 2013, at 7:28 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote: > On Sat, Apr 6, 2013 at 10:02 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: >> * Anne van Kesteren wrote: >>> That sounds fucked up. Deciding the fetching policy based on the >>> presence of a fragment identifier in the URL is a severe layering >>> violation. What if we introduce a fragment identifier to crop an >>> image? >> >> http://www.w3.org/TR/css3-images/#image-notation proposes a `image(...)` >> functional notation that can be used where `url(...)` does not suffice, >> and SVG 1.0 and http://www.w3.org/TR/media-frags/ already provide such >> functionality, which can be used in combination with `image(...)`. I've >> http://lists.w3.org/Archives/Public/www-style/2013Mar/0190.html argued >> that there should be an example using `image(...)` in the masking draft >> to avoid this particular confusion. > > Even so that would still mean CSS will have this fragment identifier > presence determines processing behavior bug. Clearly a new syntax > should have been used for masks, e.g. mask(url)... We try to solve problems, not to create new. CSS Masking combines the existing mask syntax of SVG (with url()) with the existing prefixed mask-image/mask syntax in WebKit (and now Blink) based browsers. A simple way would be to download the resource and check the type then and proceed depending on the data type. Firefox people asked for a solution to verify on interpreting the property value / URI during parsing. Greetings Dirk > > > -- > http://annevankesteren.nl/
Received on Monday, 8 April 2013 14:34:33 UTC