Re: [css-masking] 'mask' with resource and image references (was: [css4-images] support for SVG Paint Servers without element())

On Wed, Nov 7, 2012 at 2:52 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> Looks like a good summary of the discussion on the other threat. I agree with it. As a note: there are SVG fragments which still imply an image. #viewbox is one of them.

Under our simplified proposal, no, url(image#viewbox) would, in the
handful of special SVG properties, be treated as an external resource,
*not* an image.

Roc's original proposal would have detected this and treated it as an
image, but we seem to prefer the simpler model.  You can force it to
be treated as an image by using the image() function.


>> 'mask-image' is in that latter set.  So, when you encounter
>> "mask-image: url(image#frag);", we can tell at parse time that we
>> should load "image#frag" as an external resource, rather than as an
>> image.  This happens *regardless of the file's eventual type" - if it
>> ends up being a PNG (which can't provide an external resource), then
>> too bad, it's just an invalid reference.
>
> This is a very specific detail. In WebKit does not care about the fragment at all for CSS Image values (one reason WebKit does not support Media Fragments on CSS Images yet IIRC).
> Just from the name of the property, WebKit decides to treat a URL as CSS Image or a resource (like <mask>). This is the case for every single property and works very well so far. 'background', 'border' would always be CSS Images (independent of the fragment), which fulfills the agreement. 'fill', 'stroke' and 'clip-path' treat URL as resource, always (independent of the fragment). This fulfills the agreement as well.
> Since 'mask-image' uses the exactly same parsing step as 'background-image', URLs are treated as CSS Images, always. This is why 'mask-image' would be special. The same problem could occur on 'fill' and 'stroke' if SVG2 fully supports CSS image values for these properties.

Yes, as I keep saying, this is a backwards-incompatible behavior
change.  There's no way around this.

This should be an okay change to make, though, because I expect there
to be very low usage of fragment urls in -webkit-mask-image.  The
other SVG properties subject to this rule should work as intended -
they'll only fail if people were linking to something like
"url(image.png#uselesshash)".


>>>>>> You *do* know, at parse time, that it won't be
>>>>>> loading the SVG as an image, because 'mask' is on the list of
>>>>>> properties that default frag-urls to being a resource reference rather
>>>>>> than an image.
>>>>>
>>>>> You do not know that it actually is an SVG file at all. This is what I described in a previous mail:
>>>>
>>>> That doesn't matter.  The rule that we're switching to says that, *at
>>>> parse time*, a value like "url(image#frag)" will be an external
>>>> resource reference, *not* an image file.  You don't need to know what
>>>> type of file it is to make this distinction.  It just tells you which
>>>> code path to go down.
>>>
>>> This would be a mayor difference to current behavior. See below.
>>
>> Only theoretically, so far.  *If* people are commonly writing
>> -webkit-mask-image with SVG Stacks, or PNGs with useless fragments,
>> then it's a problem, because the behavior I outlined above would be a
>> change (and would make the mask stop working).
>>
>> However, I doubt both of those.  We apparently have decent evidence
>> that most usage of SVG Stacks is in HTML (<img>, <iframe>, etc.), not
>> CSS, so heavy use of them in -webkit-mask-image seems unlikely.  I
>> also doubt that useless fragments are commonly used on bitmap images,
>> in any property, so that shouldn't be much of a problem either.
>>
>> Given this, it should be okay to make this minor behavior change.
>
> I agree that the fragment is useless on PNGs or any other rasterized image with the exception of Media Fragments. But at least the behavior is consistent across all browsers. It feels bogus to specify something that runs against all implementations.

If you feel this way, then *why did you agree with Roc's earlier
suggestion, and the subsequent simplified proposal*???  I don't
understand how you can simultaneously think that the proposal is fine,
while also thinking that we shouldn't do it.

Compatibility across browsers is cool, but unless there's a web-compat
risk, we're allowed to break the pattern to achieve better things.
This is one of those "better things".

~TJ

Received on Thursday, 8 November 2012 00:14:37 UTC