The CSS Masking specification adds the optional value <mask-type> to 'mask-image': <mask-image># with <mask-image> = [<image> | none] <mask-type>? <mask-type> = luminance | alpha This allows switching to a different masking operation per image. All masks are "transformed" to alpha masks, drawn over each other and used as one alpha mask. Luminance masks are used by a lot of designers because tools from Corel and Adobe (possibly Inkscape and Gimp as well) create these kind of masks. This bug report just addresses adding the keywords to the CSS parser. Since the keywords are optional and the fallback is alpha, this won't break existing content that relies on CSS masking today.
*** Bug 97695 has been marked as a duplicate of this bug. ***
There was a discussion to change the syntax of the 'mask-image' property on www-style with the topic "Re: Ambiguities in fill:url() / stroke:url() syntax"[1]. The proposal says that the syntax should look like this: mask-image: [<mask-source> [alpha | luminance]? ] | [<mask-image> [alpha | luminance]?]# The problem is the definition of <mask-source> and <mask-image>. Both use <url>, but the meaning differs. While <mask-source> means that it references a <mask> element for masking, <mask-image> references an CSS image for masking. The outcome of the discussion is, that we differ on the syntax of the URL if we take image or <mask> referencing. If the URL has a fragment identifier, we will parse it as <mask-source> and the fragment identifier references a <mask> element. If it doesn't have a fragment identifier, it is a CSS image. Since we decide on the URL, we can't differ if the resource with a fragment is actually an SVG document with <mask> element. Means url(image.png#frag) would be assumed to be an SVG image with <mask> element. I will upload a patch to discuss this strategy shortly. Adding more CSS people who may want to be involved in the review and the decision. [1] http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html
Created attachment 174997 [details] Patch
Comment on attachment 174997 [details] Patch Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.
This is its own property now and already implemented.