W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > June 2019

Re: [fxtf-drafts] [css-masking] Disabling masks and clipPaths when display is none (#245)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 06 Jun 2019 18:37:17 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-499616118-1559846236-sysbot+gh@w3.org>
The CSS Working Group just discussed `disabling masks/clip paths when display:none`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: disabling masks/clip paths when display:none<br>
&lt;astearns> github: https://github.com/w3c/fxtf-drafts/issues/245<br>
&lt;TabAtkins> AmeliaBR: I don't expect a resolution here. SVG call discussed it, we decided we needed detailed testing for browser interop<br>
&lt;TabAtkins> AmeliaBR: What browsers are doing doesn't match long-standing SVG text tho<br>
&lt;TabAtkins> AmeliaBR: this is about SVG elements that are never rendered: &lt;*gradient>, &lt;pattern>, &lt;symbol>, etc<br>
&lt;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"<br>
&lt;TabAtkins> AmeliaBR: For SVG2, I was working on trying to make &lt;use>-element shadow DOM make more sense<br>
&lt;TabAtkins> AmeliaBR: To make &lt;symbol> not work directly, but work if you render it in which case 'display' does apply<br>
&lt;TabAtkins> AmeliaBR: Figured I could replace that prose with a UA stylesheet using !important to mean authors can't change 'display'.<br>
&lt;hober> q+<br>
&lt;TabAtkins> AmeliaBR: So say "display:none; except for &lt;symbol> that is a direct child of a &lt;use> shadow tree"<br>
&lt;TabAtkins> AmeliaBR: But turns out that in browsers, display:none *does* do something<br>
&lt;TabAtkins> AmeliaBR: In most browsers, if you set &lt;mask style=display:none>, it has no effect on elements using it as a mask<br>
&lt;TabAtkins> AmeliaBR: This isn't in specs but happnes i nmultiple browsers.<br>
&lt;astearns> ack dbaron<br>
&lt;Zakim> dbaron, you wanted to comment on ancestors being display:none<br>
&lt;TabAtkins> dbaron: Interesting is whether the element has display:None *and* whether ancestor has it<br>
&lt;TabAtkins> dbaron: Tied to "is the thing that makes these work the presence of their DOM node, or the presence of boxes they create"<br>
&lt;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<br>
&lt;TabAtkins> dbaron: So question is if that's what we want to do<br>
&lt;TabAtkins> dbaron: So in general display:none and ancestor display:none are not distinguishable<br>
&lt;TabAtkins> dbaron: So using a non-none !important value doesn't work, as it doesn't solve the ancestor problem<br>
&lt;astearns> ack hober<br>
&lt;TabAtkins> hober: Do we need to special-case these at all? In HTML &lt;style> defaults to display:none, but you can display:block it to render it.<br>
&lt;TabAtkins> hober: So who cares?<br>
&lt;TabAtkins> dbaron: I think at this point that's not backwards compatible<br>
&lt;TabAtkins> chris: Used to be that you couldn't display &lt;title> no matter what you did. But now you can.<br>
&lt;TabAtkins> AmeliaBR: I don't know how much will break, I didn't know that browsers were doing it anyway.<br>
&lt;TabAtkins> AmeliaBR: I suppose it could be useful sometimes to disable a clip-path by setting one thing on the &lt;clipPath> rather than changing all the uses...<br>
&lt;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?<br>
&lt;TabAtkins> AmeliaBR: Some browsers you can, some you can't, because of what dbaron mentioned earlier.<br>
&lt;TabAtkins> AmeliaBR: So instead you throw a pile of styles at it to make it visually hidden but not display:none<br>
&lt;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<br>
&lt;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.<br>
&lt;TabAtkins> emilio: You need to make all those checks in two places now<br>
&lt;TabAtkins> AmeliaBR: So if anyone wants to help us build up that interop-testing table, that would be very helpful.<br>
&lt;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.<br>
&lt;dbaron> Is there going to be some attempt to drive towards interop?<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/245#issuecomment-499616118 using your GitHub account
Received on Thursday, 6 June 2019 18:37:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:25 UTC