- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Feb 2023 15:41:42 +0000
- To: public-css-archive@w3.org
> I was also concerned that the inconsistency between this behavior (which effectively allows animating transform without containment) where normally any non-none transform forces containment would be confusing for developers. I can understand how forcing containment can be surprising to developers, but it is the way that [transforms work](https://www.w3.org/TR/css-transforms-1/#containing-block-for-all-descendants) which developers already likely have to deal with. I'm not sure what lead to transforms doing this, and if that rationale is applicable here. Perhaps opacity behaving differently is a good reason we don't need this. [#913](https://github.com/w3c/csswg-drafts/issues/913) has history behind why transforms force a containing block. The short answer is implementation complexity across all engines, effects like `filter` cause the same. A lot of developers have expressed frustration with this decision on the issue. That tells me that if browsers can support this, most developers would prefer option 1. From Blink's perspective, implementation complexity is not a concern because `opacity` establishes a similar pattern. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8139#issuecomment-1422823743 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 February 2023 15:41:43 UTC