* 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/Received on Tuesday, 9 April 2013 01:37:15 UTC
This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC