[css-transforms-1] The computed value of transform if the transformed element is display:none

[BorisChiou]

Just curious about where we define the computed value of transform property for display:none element (or in the display:none subtree).

Per this WPT PR#36380, it expects the computed value of transform property is always none if we set this element display:none (or in the display:none subtree). However, I cannot find the specific words in the spec (e.g. css-transforms-1 and css-display-3) to mention this behavior.

Should we add this into the spec to specify this behavior because it seems this is only for transform property? How about translate/rotate/scale properties? Should they be consistent?

[Loirooriol]

The test is actually checking the resolved value. For properties that have a special resolved value, it tends to be the computed value when in display: none. Making the computed value become none in display: none seems strange to me.

[BorisChiou]

Oh right. Per spec, transform property serializes as the resolved value. However, its result still depends on its computed value, so per the spec, in both css-transforms-1 and css-transforms-2, it's also strange to me to show none in the wpt.

Note: I'd like to update it in Gecko's bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1841292, to accept both cases for now.

[nt1m]

WebKit originally changed to stop returning none when the display value was none in WebKit/WebKit@ae44d0c , but that part was reverted in WebKit/WebKit@3a3a97e due to breaking a site (although that site can probably be fixed on our end, I would be cautious about potential web compat impact here).

[dbaron]

We had some Chromium discussion of this in https://chromium-review.googlesource.com/c/chromium/src/+/4878164?tab=comments , but really the conclusion there was to fix the test to accept multiple possible behaviors (as discussed above in #9121 (comment)) until this issue is resolved.

As far as sensible behavior goes:

• I think it's strange to return a matrix() for elements that are display: none because doing so, for some cases (resolving percentages) requires making up a size of box to resolve those percentages against.
• I also think it's strange to return none (as the resolved value) when the computed value isn't none, with the exception of cases where transform doesn't apply (like display: inline) where I think returning none does make sense.
• It's probably bad to return something closer to the computed value (a list of functions) because it's bad for calling code to get something other than a matrix() for edge cases when the calling code expects either matrix() or none.

So, basically, I think all three possible behaviors that I've thought of are bad.

It sounds like we also need to worry a good bit about compatibility here, which may mean that we should just pick the bad thing that's web-compatible instead of the bad things that aren't web-compatible.

[dbaron]

(Of the three options I wrote, I think the matrix() one seems least bad from first principles, though I didn't reread the compatibility information.)

[kbabbitt]

As I understand it, the one bit of web compatibility data we have is that WebKit regressed a site when they changed away from returning none. I also did some digging and found that an older version of the spec [1] defined "transformable element" in a way that excludes display:none elements, in which case transform would not apply to display:none elements, which I think makes it reasonable for the computed value to be none.

So right now I'd favor the none option but would reconsider if more compatibility data surfaced.

[1] https://www.w3.org/TR/2017/WD-css-transforms-1-20171130/#terminology

[css-meeting-bot]

The CSS Working Group just discussed [css-transforms-1] The computed value of `transform` if the transformed element is display:none, and agreed to the following:

• RESOLVED: non-transformable elements and elements without a box return a matrix() resolved against a 0x0 box

The full IRC log of that discussion

<fantasai> astearns: David, you had a proposal?
<fantasai> dbaron: I'm not sure I'd go so far as to call it a proposal.
<fantasai> dbaron: Basic problem is we don't have interop on getComputedStyle for the transform property for elements that are `display: none`
<fantasai> dbaron: Some UAs try to return none, as though there is no transform... which is weird if there is a transform, but that's also what happens when you do getComputedStyle on an inline box
<fantasai> dbaron: I think?
<fantasai> dbaron: normally, gCS for transforms returns either `none` or a matrix
<fantasai> dbaron: matrix() or matrix3d(). Not a sequence of transform functions.
<fantasai> dbaron: I think some UAs return sequence of transform functions when `display: none`
<fantasai> dbaron: There are 3 reasonably sensible options
<fantasai> dbaron: ... sensible is maybe a stretch
<fantasai> dbaron: Could return a matrix, but some things need a box to e.g. resolve percentages
<fantasai> dbaron: so if you want to return a matrix, you have to make up a box size
<fantasai> dbaron: e.g. 0x0
<fantasai> dbaron: Another option is return `none`
<fantasai> dbaron: Third possibility is to return sequence of transform functions.
<fantasai> dbaron: Maybe it's theoretically sensible, but not done anywhere else so might break people's code.
<fantasai> dbaron: So I think that's probably the least good option
<fantasai> dbaron: I know there is lack of interop, forget who does what
<TabAtkins> q+
<fantasai> Rossen_: Are there any use cases motivating any of these options?
<fantasai> dbaron: Not really. Just need to not break stuff.
<Rossen_> ack TabAtkins
<fantasai> TabAtkins: I don't know what backwards compat is, but I suspect naive code is more likely to depend on matrix() than anything else, so returning matrix against a 0x0 box would be sufficient
<emilio> q+
<fantasai> fantasai: It was only resolving percentages against 0x0, not making the matrix zero
<fantasai> dbaron: so usually it'll still be right, unless you have percentages in translates
<Rossen_> ack emilio
<fantasai> emilio: That's what Gecko does afaict. I don't think we special-case inlines either, just return a matrix for those also
<fantasai> emilio: if there's no box, we use an empty rect and carry on
<fantasai> emilio: Could return computed value instead, that's what we do for a lot of other properties when they don't have a box
<fantasai> emilio: would that break stuff?
<fantasai> dbaron: I don't know if anyone tried to ship that
<fantasai> dbaron: Worried since it parses so differently from the other values
<fantasai> emilio: My preference is between those two
<fantasai> emilio: using transform with empty rect seems more useful than 'none', gives you the right answer most times
<fantasai> fantasai: but wrong answer sometimes
<fantasai> dbaron: Blink does 'none' for case of not having a box. Don't think that's what it does for inlines.
<fantasai> TabAtkins: returns a matrix. it's kinda weird
<fantasai> [seems to be resolved against zero]
<fantasai> Rossen_: You mentioned a compat issue in WebKit?
<fantasai> kbabbitt: That was my interpretationof the prior comments in the issue
<kbabbitt> https://github.com//issues/9121#issuecomment-1691139831
<fantasai> emilio: that looks like breakage if returning a function list
<TabAtkins> (doing `display:block; transform:translate(50%)`, you get `matrix(1,0,0,1,NNN,0)` where NNN is a correct px value. In chrome, `display:inline; transform:translate(50%)` returns `matrix(1,0,0,1,0,0)`.
<fantasai> fantasai: Problem with matrix is that you might think you have the transform, but you don't when you display the box it'll resolve to something else
<fantasai> emilio: that's true if you change width or height
<fantasai> dbaron: If we think doing the matrix does more sense, and I probably lean that way, given Gecko's behavior it seems like something we could try
<fantasai> fantasai: It's not unreasonable answer, not thrilled that it could be misleading
<fantasai> Rossen_: Then let's resolve on the matrix behavior, and see what happens
<fantasai> Rossen_: since no objections
<fantasai> fantasai: Do we resolve on this for both inline and none?
<fantasai> dbaron: Already iimplemented in Blink and Gecko
<fantasai> fantasai: but is it in the spec
<fantasai> dbaron: probably not, so should spec it
<fantasai> dbaron: So for display:none and non-transformable boxes, compute a matrix against 0x0 box.
<emilio> q+
<fantasai> Rossen_: does that include tables?
<kbabbitt> s/tables/table parts/
<fantasai> dbaron: Ignoring SVG, non-transformable would be non-replaced inlines, table columns, and table column groups
<Rossen_> ack emilio
<fantasai> emilio: I prefer a separate resolution for none, because Gecko resolves percentages on inlines against something
<fantasai> dbaron: Chrome does 0x0 on inlines
<fantasai> emilio: ok, we can adopt that
<fantasai> fantasai: I would prefer doing something consistent
<fantasai> emilio: so we'll swap around some engine behaviors
<dbaron> emilio: Gecko uses a size for inlines
<fantasai> PROPOSED: non-transformable elements and elements without a box return a matrix() resolved against a 0x0 box
<fantasai> TabAtkins: Table column elements return 'none'
<fantasai> TabAtkins tests some stuff and is confused
<TabAtkins> <!DOCTYPE html>
<TabAtkins> <table><col style="transform: translate(50%);"></col></table>
<TabAtkins> <script>
<TabAtkins> w(getComputedStyle(document.querySelector("col")).transform);
<TabAtkins> </script>
<fantasai> RESOLVED: non-transformable elements and elements without a box return a matrix() resolved against a 0x0 box