- From: Florian Rivoal <florian@rivoal.net>
- Date: Sun, 14 Jul 2013 17:59:56 +0200
- To: www-style@w3.org
On Thu, 11 Jul 2013 19:06:29 +0200, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Thu, Jul 11, 2013 at 7:46 AM, Dirk Schulze <dschulze@adobe.com> wrote: >> Hi, >> >> We didn't get to an agreement on the CSS WG call how to handle the >> 'mask' shorthand property. I think in general we did not disagree on >> the structure: >> >> mask >> +-- mask-layer >> | +--mask-layer-image >> | +--mask-layer-position >> | +--mask-layer-repeat >> | etc. >> +-- mask-element >> +-- mask-box >> +--mask-box-source >> +--mask-box-slice >> +--mask-box-repeat >> etc. >> >> But CSS WG members didn't like that 'mask' can just reference SVG >> elements. Here the problem why the initial proposal didn't allow >> <mask-layer>: >> >> Both, mask-element and mask-layer-image can take a url(). However, >> while it references an <mask> element for the former, it references an >> CSS image for the later. There are some security considerations if one >> loads an SVG resource or CSS image, which leads to different fetching >> algorithms. Therefore, the CSS Parser must detect on parse time if we >> load an SVG resource or an CSS Image. Two solution that are agreed on >> in the past: >> >> 1) Parse the URI string and check for hashes. If there is an hash, >> assume it is an SVG resource, otherwise an CSS Image. >> - This was quite unpopular for web authors and many complained on >> Twitter and some mailing lists. >> 2) Don't allow either <mask-element> or <mask-layer> on the shorthand. >> Since 'mask' is in an recommendation and uses <mask-element> this one >> was the natural choice. >> >> I see two more ways to allow <mask-element> and <mask-layer> as values >> for the 'mask' shorthand: >> >> 3) Don't allow url() as CSS Image for 'mask-layer' >> - This would mean that you can not use url() for mask-layer-image >> anymore, which a lot of authors are still used to. Furthermore, image() >> (the alternative) is not supported in browsers yet. >> >> 4) Add keywords that allow to differ between the masking operations: >> >> mask: [<mask-element> && layer <mask-layer> && box <mask-box>] | none >> >> As you see, this could allow 'mask' to set all kind of masking >> operations, not just <mask-element> and <mask-layer> but also <mask-box> > > Ooh, #4 doesn't sound half bad. Agreed, #4 is my favorite. It is a little bit verbose, so if that makes it unacceptable to some, we can replace the keywords by single character separators, but I am fine with it as is. #1 I strongly dislike. Even more so if we take Robert's variant that needs network access. - Florian
Received on Sunday, 14 July 2013 16:00:20 UTC