[css-masking] Disabling masks and clipPaths when display is none #245
Safari, Firefox, Chrome and Edge allow disabling
Here’s an example with a mask and a clip path in SVG. They both have display set to "none", which disables them: https://codepen.io/anon/pen/mpBdrx
The paragraph about the display property seems to be about direct rendering, but it doesn’t mention that the display property disables the mask/clipPath:
Could the spec be updated to match the current browser behavior? It should say that if the display property is "none", then the mask or clip path is disabled.
SVG 1.1 and CSS Masking state for
Clearly, none of the implementations follow the spec text where
I suppose that for HTML, Firefox follows this description (because of
Edit: Gecko issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1463336
Well, I suppose it could be useful to be able to disable/enable all uses of a mask or clipPath with
And it makes the logical model much more difficult: what about display being turned off on a parent element? What about references to clip path and mask in external files (currently only supported consistently in Firefox)?
We'd definitely have to retract the parts of SVG 2 that assign these elements a
Either way, I do think we should continue to distinguish between
The SVG Working Group just discussed
The full IRC log of that discussion<AmeliaBR> Topic: Disabling masks and clipPaths when display is none
<AmeliaBR> GitHub: https://github.com//issues/245
<AmeliaBR> Dirk: Question is what happens when `display: none` on the <mask> or <clipPath> element itself.
<AmeliaBR> ... I uploaded some test results
<AmeliaBR> ... most browers disable the effect (as if you didn't specify a clip-path). But there are discrepancies when the effect is on HTML elements.
<AmeliaBR> ... (for browsers/effects which are supported on HTML element, `display: none` is treated as if the mask was full transparent / clipPath was empty. So the element with the effect disappears.
<AmeliaBR> Dirk: Not sure what to do with that, but for SVG effects on SVG elements, it looks like we have consistency.
<AmeliaBR> Dirk: I'd recommend standardizing that: if clip-path or mask property references an element with `display: none`, treat it the same as if it referenced a non-existant element, so no effect.
<AmeliaBR> Chris: Does this only apply if `display: none` is directly set on the element itself, or does it also imply by inheritance, e.g., from `<defs display="none">`.
<AmeliaBR> ... Because a defs is general defined as the same as display: none.
<AmeliaBR> Amelia: And it also depends on the spec text. Assuming the SVG 1 spec was implemented (display: none has no effect), we rewrote it to define these elements as having a `display: none !important` user agent style so it could be defined with CSS. But that doesn't work if display: none actually has an effect.
<AmeliaBR> Dirk: After a quick test, it looks like an explicit `display: none` on the defs element does disable the child masks / clipPaths, in Blink and WebKit.
<AmeliaBR> Amelia: Since we have consistency between browsers, there may be content depending on it, we should change the spec to match. But we need to figure out what that is, and how to define it clearly. And whether it applies to other elements, e.g., filter effects.
<AmeliaBR> Dirk: Yes, so we need to do some comparison, e.g., for the defs issue. But I think we should focus on masks / clipPath for now.
<AmeliaBR> Amelia: The same text about display not having an effect is used in many parts of the spec. If we're going to rewrite it, we need to figure out how much need to edit.
<AmeliaBR> Dirk: Can we agree on the `display: none` for the mask and clipPath element?
<AmeliaBR> Amelia: I think we need to do more testing first. Go through all the elements in SVG that have the same rules.
<AmeliaBR> Dirk: But these aren't in the SVG spec anymore, they're in CSS Masking.
<AmeliaBR> Amelia: Are you in a rush to republish?
<AmeliaBR> Dirk: No, but we don't want edits on one spec to wait for the other.
<AmeliaBR> Amelia: But we do want to make sure that the final edits are consistent.
<AmeliaBR> Dirk: OK, so you want to get data for all SVG effects, like gradients and patterns and so on?
<AmeliaBR> Amelia: Yep. Should probably open a dedicated issue on the SVG repo. And filter effects, too.
<AmeliaBR> Dirk: There's already one on Filters (https://github.com//issues/130)
<AmeliaBR> ... it's also on the agenda, but I guess we should also defer until we get full data.
referenced this issue
May 16, 2019
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: disabling masks/clip paths when display:none
<astearns> github: https://github.com//issues/245
<TabAtkins> AmeliaBR: I don't expect a resolution here. SVG call discussed it, we decided we needed detailed testing for browser interop
<TabAtkins> AmeliaBR: What browsers are doing doesn't match long-standing SVG text tho
<TabAtkins> AmeliaBR: this is about SVG elements that are never rendered: <*gradient>, <pattern>, <symbol>, etc
<TabAtkins> AmeliaBR: In SVG1, these all had an opaque paragraph that said 'display doesn't apply to these elements, no matter what you say it won't be rendered, and nobody what you say they'll always b eusable"
<TabAtkins> AmeliaBR: For SVG2, I was working on trying to make <use>-element shadow DOM make more sense
<TabAtkins> AmeliaBR: To make <symbol> not work directly, but work if you render it in which case 'display' does apply
<TabAtkins> AmeliaBR: Figured I could replace that prose with a UA stylesheet using !important to mean authors can't change 'display'.
<TabAtkins> AmeliaBR: So say "display:none; except for <symbol> that is a direct child of a <use> shadow tree"
<TabAtkins> AmeliaBR: But turns out that in browsers, display:none *does* do something
<TabAtkins> AmeliaBR: In most browsers, if you set <mask style=display:none>, it has no effect on elements using it as a mask
<TabAtkins> AmeliaBR: This isn't in specs but happnes i nmultiple browsers.
<astearns> ack dbaron
<Zakim> dbaron, you wanted to comment on ancestors being display:none
<TabAtkins> dbaron: Interesting is whether the element has display:None *and* whether ancestor has it
<TabAtkins> dbaron: Tied to "is the thing that makes these work the presence of their DOM node, or the presence of boxes they create"
<TabAtkins> dbaron: For many browsers, these live in the box tree, and using them links to the box tree, and display:none means no boxes are generated and they fail
<TabAtkins> dbaron: So question is if that's what we want to do
<TabAtkins> dbaron: So in general display:none and ancestor display:none are not distinguishable
<TabAtkins> dbaron: So using a non-none !important value doesn't work, as it doesn't solve the ancestor problem
<astearns> ack hober
<TabAtkins> hober: Do we need to special-case these at all? In HTML <style> defaults to display:none, but you can display:block it to render it.
<TabAtkins> hober: So who cares?
<TabAtkins> dbaron: I think at this point that's not backwards compatible
<TabAtkins> chris: Used to be that you couldn't display <title> no matter what you did. But now you can.
<TabAtkins> AmeliaBR: I don't know how much will break, I didn't know that browsers were doing it anyway.
<TabAtkins> AmeliaBR: I suppose it could be useful sometimes to disable a clip-path by setting one thing on the <clipPath> rather than changing all the uses...
<TabAtkins> AmeliaBR: Practical case it breaks. Lots of inline SVGs using a gradient, so you have an inline SVG somewhere that defines those gradients. You don't want it to draw, so can you tell that SVG display:none?
<TabAtkins> AmeliaBR: Some browsers you can, some you can't, because of what dbaron mentioned earlier.
<TabAtkins> AmeliaBR: So instead you throw a pile of styles at it to make it visually hidden but not display:none
<TabAtkins> emilio: Is part of the reason it depends on the box tree-- we have a special thing for SVG that says "this frame is non-display" that doesn't do anything on its own
<TabAtkins> emilio: What that gets you is that a lot of elements don't generate a box at all when they're invalid markup - not in an SVG parent or whatever.
<TabAtkins> emilio: You need to make all those checks in two places now
<TabAtkins> AmeliaBR: So if anyone wants to help us build up that interop-testing table, that would be very helpful.
<TabAtkins> astearns: So I think you can take that back to the SVGWG with our notion that it's probably not worth special-casing, and maybe impossible.
<dbaron> Is there going to be some attempt to drive towards interop?