Re: [filter-effects][css-masking] Move security model for resources to CSP

* Anne van Kesteren wrote:
>On Sat, Apr 6, 2013 at 10:02 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>> 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)...

If that is the only change you have in mind, then for each of the these:

  mask-image: url(...);
  mask-image: mask(...);
  mask-image: image(...);
  mask-image: url(...#...);
  mask-image: mask(...#...);
  mask-image: image(...#...);

you would have to define whether they are allowed and what the behavior
is, and what `mask(...)` means for all other properties. I do not really
see any "clear" answer to that that would lead to a better result. I can
see an argument for disallowing `url(...)` without fragment identifier,
if that is indeed redundant with `image(...)`, but that would not really
address the concern as you put it above, and people do not like failure
cases (just look at all the places where you can specify a fragment, but
that has no effect compared to not specifying one, making it impossible
to define more sensible behavior for fragment identifiers there "now").
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/