Re: [css-masking] clip-path with invalid url

On Thu, Dec 12, 2013 at 2:28 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Dec 11, 2013, at 7:00 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> On 12/11/2013 07:46 AM, Dirk Schulze wrote:
>>>
>>> On Dec 11, 2013, at 11:46 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
>>>
>>>>   6. # If the URI reference is not valid [...], no clipping is applied.
>>>>      Please clarify whether a stacking context is still created
>>>>      or whether the behavior is equivalent to specifying 'none'.
>>>
>>> I would say a stacking context should be created to match the behavior
>>> but think that implementations don’t do that currently. I would like
>>> to base the decision on the current implemented behavior.
>>
>> Then please investigate currently-implemented behavior. But please also
>> raise this to the WG, as the implementors might decide they don't like
>> the currently-implemented behavior.
>
> I checked the behavior on Firefox, Safari and Chrome. (IE just supports clip-path and mask on SVG which does not have stacking contexts.)
>
> All implementations create a stacking context for clip-path on HTML even if the url() is “invalid”. Means the fragment identifier does not exists, resource is not loaded or does not point to an <clipPath> element. I also tested the behavior on ‘mask’ with the same result.
>
> In all cases the three engines WebKit, Gecko and Blink do create a stacking context.
>
> Now it is up the implementations if they want to change the behavior. Given that all implementations are consistent, I do not expect that to happen.

That's the correct behavior anyway - we shouldn't be basing things
like stacking contexts on used-value time information, which network
requests qualify as whenever possible.

~TJ

Received on Friday, 13 December 2013 18:50:14 UTC