[css-backgrounds] Are the rules for interactions of transforms and backgrounds on the root element what we want? #6683
Comments
|
The CSS Working Group just discussed The full IRC log of that discussion<fantasai> Topic: Transforms and backgrounds on root element<fantasai> github: <fantasai> 6. <fantasai> github: https://github.com//issues/6683 <fantasai> s/6.// <fantasai> dbaron: obscure passage in the spec, wrote a test for it, and ended up wondering if we really want spec to say this in the first place <fantasai> dbaron: [quote spec] <fantasai> dbaron: basically, this is describing a special behavior for fixed backgrounds on root element, saying that transforms apply to that fixed background <fantasai> dbaron: interesting because normal rules for background on root element say that backgrounds get propagated to canvas <fantasai> dbaron: and backgrounds on canvas, nothing says anywhere that they are affected by transforms <fantasai> dbaron: so if you read between lines in spec, I think what it says is that non-fixed background are not affected by transforms <fantasai> dbaron: could probably make other arguments, though <fantasai> dbaron: What I think the spec is saying is that fixed backgrounds are affected by transforms, and scrolled backgrounds are not affected by transforms <fantasai> dbaron: what my tests found, is that in chromium do the exact opposite <fantasai> dbaron: i.e. fixed background not affected, but scrolled backgrounds are <fantasai> dbaron: in Gecko neither is affected by transform <fantasai> dbaron: and in WebKit both kinds are affected by transform <fantasai> dbaron: So 4 possible behaviors <fantasai> dbaron: and every browser fits into a different possible behavior <dholbert> as a see-also, we have https://bugzilla.mozilla.org/show_bug.cgi?id=1724471 filed on some WPT tests failing due to Gecko's behavior here <fantasai> dbaron: It's not clear to me we want what the spec says <fantasai> dbaron: I wanted to see if anyone has an opinion here <fantasai> smfr: Don't have a clear memory about why spec is the way it is, might have been ease of implementation <fantasai> smfr: we do special thinks for fixed backgrounds <fantasai> smfr: but I would expect that it would have been easiest to *not* apply transforms for fiexd backgrounds <fantasai> smfr: so I'm pretty confused <astearns> ack RRSAgent <astearns> ack r12a <fantasai> dholbert: [...] <fantasai> fantasai: So what do authors expect to happen here? <fantasai> dbaron: part of what I was wondering <fantasai> fantasai: so canvas is infinite... <fantasai> smfr: Think about rotate(45deg); does the background rotate? <fantasai> dbaron: Unsure anyone cares here, so maybe do the easy thing? <fantasai> dbaron: so not apply transform <fantasai> smfr: So if author wanted background to move around, they could put it on body and prevent propagation with different style on the root <fantasai> smfr: and then transform the body <fantasai> dbaron: might not cover the same area though <fantasai> smfr: What happens to gaps revealed by e.g. rotating 45deg? <fantasai> smfr: are they filled, or ...? <fantasai> dbaron: WebKit has some bugs around that <fantasai> astearns: Anyone looked to see if any bugs filed against engines on this? <fantasai> smfr: don't recall any for WebKit <fantasai> dbaron: I feel like this is a combination that nobody actually cares about <fantasai> astearns: so suggestion of never honoring transform, is that ok smfr? <fantasai> smfr: My concern there is, naively, if root gets transformed, whether background is transformed with it depends on details of impl <fantasai> smfr: if we end up with behavior change, might force us to do additional work to handle <fantasai> smfr: I'm OK resolving bg never gets transformed, and if hard, we can revisit <fantasai> astearns: so chrome would need to change also <fantasai> dbaron: haven't looked into what's needed for that, but I'm OK looking into it <fantasai> astearns: proposed that we change spec to say that background on root element are not affected by transforms <fantasai> dbaron: I think current spec is unclear about scrolled backgrounds <fantasai> dbaron: you have to infer based on propagation rules <fantasai> smfr: we've talked about effects of filters on root element in the past <fantasai> smfr: Chris came up with a proposal for rendering model that allows filters to affect root background <fantasai> smfr: so maybe review that and see if any of it applies to transforms <fantasai> dbaron: ok, so let's come back to this later <fantasai> astearns: so let's review filters and come back to this later |
Note: separate from those pending tests, I think this issue is also the core of the differences-in-outcomes on these existing WPT tests (which happen to be in the compat2021 test suite, and all of which pass in Chromium but fail in other browsers): (note that transform-translate-background-001.html and -002 are hitting some other behavior-differences as well, which I've got some notes on in https://bugzilla.mozilla.org/show_bug.cgi?id=1724459 ) |
|
Sorry, I should've also added, in case it matters: for some of the WPT tests that I linked, there's a a transform specified on the root but the background-image is specified on the vs. in others, the transform and background-image are both specified on the root, e.g. in (I'm not sure that makes a meaningful difference, since I think background-image gets propagated from the body and behaves essentially the same on body vs. root as a result. But I wanted to call it out, since dbaron did specifically mention "backgrounds on the root element" as the thing-in-question here.) |
|
I think Chrome's behavior is intentionally to conform to the compositing spec @chrishtr Currently Chrome has a bug about background-attachment:fixed with transforms. |
|
Though the compositing spec only says we should apply root element filters, masks, etc. on the root element group, it seems reasonable to also apply root element transform on backgrounds (regardless of attachment). Also the transform spec has a note under the background-attachment:fixed paragraph:
|
|
When we revisit this, if transforming the background is ever the right thing to do, we should also specify in which coordinate space 'background-repeat: space' is resolved (and possibly other position properties). |
|
Can we discuss this at the next APAC call on October 5th? |
atanassov
changed the title
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-backgrounds] Are the rules for interactions of transforms and backgrounds on the root element what we want?<dael> github: https://github.com//issues/6683 <dael> mattwoodrow: Looks like discussed last year, resolved to wait for filter spec <dael> mattwoodrow: I would like to continue discussion and make a decision. No strong opinions <dael> astearns: Can you get us up to speed with what has been discussed? <dael> mattwoodrow: Current state is inconsistent between impl and spec is unclear which path. Pretty open. Slight diff in if background is fixed. <dael> astearns: Anyone with opinions? <dael> smaug: Any websites where this matters? <smfr> s/smaug/smfr/ <dael> mattwoodrow: No one has found any. Poss because it's so different between browsers. I think Gecko never transforms, WebKit always, Chrome for scrolled but not fixed. No interop <dael> smfr: I would argue to easiest to implement <dael> astearns: Naive guess is that's never transform? <dael> smfr: I think ignoring transform is easiest <dael> fantasai: Could make sense b/c if you're transforming the whole root you could want a bg behind it and don't want that to transform with the page. Should be something behind it. <dael> fantasai: If you want bg to transform with page you attach it to the page and get the behavior <dael> smfr: Makes sense to me. I think only bg that prop to canvas? <dael> fantasai: Yeah <dael> smfr: I would say they never transform. If they want transform but bg on the body <TabAtkins> This seems confusing in general, but I think the proposal makes sense <dael> astearns: Anyone want to argue for paying attention to transforms on root element background? <dael> astearns: Prop: Always ignore transforms on backgrounds of the root element <dael> astearns: Is that sufficient resolution? <dael> mattwoodrow: That's sufficient <dael> smfr: That's both bg attachment fixed and scroll I think. But what you said should be sufficient <dael> astearns: Objections? <dael> RESOLVED: Always ignore transforms on backgrounds of the root element <dael> florian: Question - do we mean bg on the root or bg that prop to the canvas? Do we mean those two? <dael> fantasai: Yes. Anything prop to the canvas doesn't get impacted <dael> fantasai: There's no transforms on canvas <dael> astearns: Always ignore transforms on bg that get propagated to canvas <dael> smfr: Transforms applied to elements. If it's prop to canvas bg not effected <dael> fantasai: once prop to the canvas it's not impacted by any transforms <dael> astearns: BG that are propagated to canvas have any transforms taken away <dael> smfr: Render as if originating element had no transform <dael> florian: We're clear enough. Let editors write <dael> astearns: Current resolution + discussion or ammend the resolution? <dael> florian: Another. <florian> +1 <dael> astearns: Always ignore transforms on backgrounds that propage to canvas <dael> RESOLVED: Always ignore transforms on backgrounds that propagate to canvas |
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment)
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment)
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment)
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment)
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment)
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment)
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment)
It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment) Fixes web-platform-tests/interop#138
https://bugs.webkit.org/show_bug.cgi?id=245032 rdar://99782177 Reviewed by NOBODY (OOPS!). This has the side effect of stopping transforms from applying on the document element background, which is what we want according to: w3c/csswg-drafts#6683 (comment) * Source/WebCore/rendering/BackgroundPainter.cpp: (WebCore::BackgroundPainter::paintBackground): (WebCore::BackgroundPainter::paintRootBoxFillLayers): * Source/WebCore/rendering/RenderView.cpp: (WebCore::RenderView::paintBoxDecorations): * Source/WebCore/rendering/RenderElement.cpp: (WebCore::RenderElement::styleWillChange):
…lement tests, a=testonly Automatic update from web-platform-tests Update backgrounds on transformed root element tests (#36306) It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment) Fixes web-platform-tests/interop#138 -- wpt-commits: 8c3d8900b04afb95d56ee1bee254d94657160f1b wpt-pr: 36306
…lement tests, a=testonly Automatic update from web-platform-tests Update backgrounds on transformed root element tests (#36306) It was decided that transforms on the root element and on the canvas should not apply to the background-image. See: w3c/csswg-drafts#6683 (comment) Fixes web-platform-tests/interop#138 -- wpt-commits: 8c3d8900b04afb95d56ee1bee254d94657160f1b wpt-pr: 36306
|
Would be great if someone can do the edit since it is part of interop 2023. |
…canvas. This stops honoring CSS transforms when painting backgrounds of either the root element or the HTML <body> element that are propagated to the CSS canvas. This matches a spec clarification/change in w3c/csswg-drafts#6683 . This should hopefully be low risk due to the hopefully-low rate of usage of transforms on the root or <body> element, and the poor interop of the current behavior. I had been hoping to do more code removal in this CL, but it seems that's not possible because of how paint offset is sometimes stored in the property tree and sometimes not. Fixed: 1373055 Bug: 1423007, 1179572, 1266821 Change-Id: I6aef4afb8e132808d2fb38cd553a2b362cb73249 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4324478 Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/main@{#1115360}
|
While writing spec edits, I noticed one other minor inconsistency that I'm going to consider editorial, because on this testcase all of Chrome, Firefox, and Safari do the sensible thing rather than what a literal reading of the spec says. Read literally, the spec says that the rule that |
…nsform https://bugs.webkit.org/show_bug.cgi?id=245032 Reviewed by NOBODY (OOPS!). As per w3c/csswg-drafts#6683 root element backgrounds should not have the css transform applied to their rendering. This adds an explicit call to render the background of root elements before the transform is pushed, and requests that the background is not rendered during the following normal rendering. * LayoutTests/TestExpectations: * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/transform-translate-background-001-expected.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/transform-translate-background-001-ref.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/transform-translate-background-002-expected.html: Reimported tests to include the scrollbar fix. * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/transform-translate-background-001.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/transform-translate-background-002.html: Fuzz added to tests for subtle gradient rendering differences, will be exported upstream. * Source/WebCore/rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintLayerByApplyingTransform):
|
adding transform translate ruins background attachment fixed |
In web-platform-tests/wpt#30946 I just wrote some tests for backgrounds on the root element when the root element has a transform. Both interoperability and conformance to the current specification are poor. I think it's perhaps worth considering whether the specification says what we want it to say.
In particular, the transforms spec says:
(Note there's some prose in the previous normative paragraph, prior to the example, about background-attachment fixed backgrounds, but that's actually more recent text that was added in #2185 as part of exporting a formal definition of containing block for all descendants, so it can be ignored here since it's not relevant to the transform property itself, thanks to the text I quoted above.)
Then, in general, the backgrounds spec describes the background propagation of the root element to the canvas, and the background positioning area being determined by the root element's padding box. While it's not completely clear whether this is affected by transforms or not, I think the implication of the current spec is that it is not affected by transforms, although I think it's possible to argue the opposite.
Thus my reading of the current specs is that transforms on the root should affect the root's background only when background-attachment is fixed.
However, what my tests found is that:
The particular conclusion about what the spec currently says doesn't particularly make sense to me, and I wonder if it's something we should reconsider given the lack of interop and lack of conformance to the current spec.
The text was updated successfully, but these errors were encountered: