1463336 - Inconsistent behavior of mask with display: none between SVG and HTML

Status: RESOLVED DUPLICATE of bug 1765202

(Core :: SVG, enhancement, P3)

Description

[Dirk Schulze]

There was an issue reported for the CSS Masking specification about the behavior of <mask> and <clipPath> in combination with display: none.

Beside the differences between implementations and specification, the testing revealed an inconsistency between <mask display="none"> applied on HTML elements and SVG elements.

For SVG elements, the mask gets disabled on display: none and does not contribute to the rendering of the element.

For HTML element, the element does not get rendered at all if the mask gets disabled on display: none.

Spec issue: https://github.com/w3c/fxtf-drafts/issues/245
SVG test: https://codepen.io/anon/pen/mpBdrx
HTML test: https://codepen.io/anon/pen/opGXyx

CSS Masking allows multiple mask sources for the `mask` property. I didn't check if that works on SVG elements as well. If it doesn't, there might be technical reason for the difference. Maybe the difference is because of the following new spec text:

> A mask reference that is an empty image (zero width or zero height), that fails to download, is not a reference to an mask element, is non-existent, or that cannot be displayed (e.g. because it is not in a supported image format) still counts as an image layer of transparent black.

It would be great if someone familiar with the code could reply on the spec issue as well so that we define the most reasonable thing in the spec.

Comment 1

[Markus Stange [:mstange]]

At TPAC 2019 the SVG working group decided on the following resolution:

RESOLUTION: display: none on mask/clipPath/filter element (or ancestor) should cause the graphical effect to be ignored, so there is no impact on the rendering of the SVG/HTML element the resource applies to (as if it was not specified for that element)

In other words, Gecko's behavior of hiding an HTML element if its mask is display:none is not compliant with this resolution - the element should be drawn as if no mask was specified for that element.
We should fix Gecko.

Comment 2

[Timothy Nikkel (:tnikkel)]

A try push for this
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8a7ddc1bf77d9007842bb2cf64dfb25947d3fce
It fails some tests that shouldn't be failing, some tests should be changed to the new behaviour. One test fails on wr but not non-wr.

Comment 3

[Daniel Holbert [:dholbert]]

tnikkel - would you mind posting a snapshot of your patch, as an attachment here, so that we don't lose it? (I assume it'll be useful as a starting point for whoever ends up working on this.)

IIRC, the try hg-repo gets purged periodically, so comment 2 will turn into a broken link at some point. (I thought that happened relatively often, but it seems your patches from 2 years ago in comment 2 are still there, fortunately! But who knows how soon they will disappear. :))

(Also: given that we've now shipped WR and presumably fixed a bunch of bugs, I wonder if some of the issues that you hit in comment 2 may have been fixed now -- maybe the patch is trivially closer-to-being-shippable?)

Comment 4

[Daniel Holbert [:dholbert]]

(For reference: I ran across this when looking for bugs related to bug 1755678; that bug is mostly about a distinct issue, but it also touched on this behavior as part of the investigation there.)

Comment 5

[Timothy Nikkel (:tnikkel)]

Attachment: makehtmlmasklikesvg

Here's the patch from try server. I've long paged this out of my head. Not sure if it'd even be easier for me to page it back in vs someone else getting up to speed on this.

Comment 6

[Robert Longson [:longsonr]]

Our rendering is the same as Chrome post bug 1765202