-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-transforms-1] The computed value of transform
if the transformed element is display:none
#9121
Comments
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 |
Oh right. Per spec, 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. |
WebKit originally changed to stop returning |
According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d
According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199807}
According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199807}
According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199807}
…omputedStyle-001.html, a=testonly Automatic update from web-platform-tests Fix css/css-transforms/transform-2d-getComputedStyle-001.html According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199807} -- wpt-commits: 86693b117d3f2179ec1714c0566736945d445322 wpt-pr: 42092
…omputedStyle-001.html, a=testonly Automatic update from web-platform-tests Fix css/css-transforms/transform-2d-getComputedStyle-001.html According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhuchromium.org> Reviewed-by: David Baron <dbaronchromium.org> Cr-Commit-Position: refs/heads/main{#1199807} -- wpt-commits: 86693b117d3f2179ec1714c0566736945d445322 wpt-pr: 42092 UltraBlame original commit: 7b5f71b2c4e47b86bd9c161aae8b20860c613703
…omputedStyle-001.html, a=testonly Automatic update from web-platform-tests Fix css/css-transforms/transform-2d-getComputedStyle-001.html According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhuchromium.org> Reviewed-by: David Baron <dbaronchromium.org> Cr-Commit-Position: refs/heads/main{#1199807} -- wpt-commits: 86693b117d3f2179ec1714c0566736945d445322 wpt-pr: 42092 UltraBlame original commit: 7b5f71b2c4e47b86bd9c161aae8b20860c613703
…omputedStyle-001.html, a=testonly Automatic update from web-platform-tests Fix css/css-transforms/transform-2d-getComputedStyle-001.html According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199807} -- wpt-commits: 86693b117d3f2179ec1714c0566736945d445322 wpt-pr: 42092
…omputedStyle-001.html, a=testonly Automatic update from web-platform-tests Fix css/css-transforms/transform-2d-getComputedStyle-001.html According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhuchromium.org> Reviewed-by: David Baron <dbaronchromium.org> Cr-Commit-Position: refs/heads/main{#1199807} -- wpt-commits: 86693b117d3f2179ec1714c0566736945d445322 wpt-pr: 42092 UltraBlame original commit: 7b5f71b2c4e47b86bd9c161aae8b20860c613703
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:
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. |
According to w3c/csswg-drafts#9121, there is no full consensus on the resolved value of transform on an element with 'display: none', and for now we should accept both 'none' and the value not depending on 'display' (w3c/csswg-drafts#9121 (comment)). Bug: 1418705 Change-Id: Ic053b4f963fb51fc9432ec614800570c4492332d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4878164 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1199807}
(Of the three options I wrote, I think the |
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 So right now I'd favor the [1] https://www.w3.org/TR/2017/WD-css-transforms-1-20171130/#terminology |
The CSS Working Group just discussed
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 |
Just curious about where we define the computed value of
transform
property fordisplay:none
element (or in thedisplay:none
subtree).Per this WPT PR#36380, it expects the computed value of
transform
property is alwaysnone
if we set this elementdisplay:none
(or in thedisplay: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 abouttranslate
/rotate
/scale
properties? Should they be consistent?The text was updated successfully, but these errors were encountered: