- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 9 Apr 2013 06:43:28 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Apr 9, 2013 at 2:36 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: > * Anne van Kesteren wrote: >>On Sat, Apr 6, 2013 at 10:02 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote: >>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"). In a later email I suggested not changing the fetching policy based on the presence of a fragment identifier and having a way to opt into a fetching policy that supports cross-origin masks instead (CORS). A way that matches how HTML has addressed this. That would also scale better if we introduced new types that have a CORS same-origin requirement that do not use a fragment. -- http://annevankesteren.nl/
Received on Tuesday, 9 April 2013 05:43:56 UTC