Re: [csswg-drafts] [css-backgrounds] Are the rules for interactions of transforms and backgrounds on the root element what we want? (#6683)

The CSS Working Group just discussed `[css-backgrounds] Are the rules for interactions of transforms and backgrounds on the root element what we want?`, and agreed to the following:

* `RESOLVED: Always ignore transforms on backgrounds of the root element`
* `RESOLVED: Always ignore transforms on backgrounds that propagate to canvas`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-backgrounds] Are the rules for interactions of transforms and backgrounds on the root element what we want?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/6683<br>
&lt;dael> mattwoodrow: Looks like discussed last year, resolved to wait for filter spec<br>
&lt;dael> mattwoodrow: I would like to continue discussion and make a decision. No strong opinions<br>
&lt;dael> astearns: Can you get us up to speed with what has been discussed?<br>
&lt;dael> mattwoodrow: Current state is inconsistent between impl and spec is unclear which path. Pretty open. Slight diff in if background is fixed.<br>
&lt;dael> astearns: Anyone with opinions?<br>
&lt;dael> smaug: Any websites where this matters?<br>
&lt;smfr> s/smaug/smfr/<br>
&lt;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<br>
&lt;dael> smfr: I would argue to easiest to implement<br>
&lt;dael> astearns: Naive guess is that's never transform?<br>
&lt;dael> smfr: I think ignoring transform is easiest<br>
&lt;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.<br>
&lt;dael> fantasai: If you want bg to transform with page you attach it to the page and get the behavior<br>
&lt;dael> smfr: Makes sense to me. I think only bg that prop to canvas?<br>
&lt;dael> fantasai: Yeah<br>
&lt;dael> smfr: I would say they never transform. If they want transform but bg on the body<br>
&lt;TabAtkins> This seems confusing in general, but I think the proposal makes sense<br>
&lt;dael> astearns: Anyone want to argue for paying attention to transforms on root element background?<br>
&lt;dael> astearns: Prop: Always ignore transforms on backgrounds of the root element<br>
&lt;dael> astearns: Is that sufficient resolution?<br>
&lt;dael> mattwoodrow: That's sufficient<br>
&lt;dael> smfr: That's both bg attachment fixed and scroll I think. But what you said should be sufficient<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: Always ignore transforms on backgrounds of the root element<br>
&lt;dael> florian: Question - do we mean bg on the root or bg that prop to the canvas? Do we mean those two?<br>
&lt;dael> fantasai: Yes. Anything prop to the canvas doesn't get impacted<br>
&lt;dael> fantasai: There's no transforms on canvas<br>
&lt;dael> astearns: Always ignore transforms on bg that get propagated to canvas<br>
&lt;dael> smfr: Transforms applied to elements. If it's prop to canvas bg not effected<br>
&lt;dael> fantasai: once prop to the canvas it's not impacted by any transforms<br>
&lt;dael> astearns: BG that are propagated to canvas have any transforms taken away<br>
&lt;dael> smfr: Render as if originating element had no transform<br>
&lt;dael> florian: We're clear enough. Let editors write<br>
&lt;dael> astearns: Current resolution + discussion or ammend the resolution?<br>
&lt;dael> florian: Another.<br>
&lt;florian> +1<br>
&lt;dael> astearns: Always ignore transforms on backgrounds that propage to canvas<br>
&lt;dael> RESOLVED: Always ignore transforms on backgrounds that propagate to canvas<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6683#issuecomment-1269092125 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 5 October 2022 23:14:28 UTC