- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Sep 2022 20:45:07 +0000
- To: public-css-archive@w3.org
> If we want to address these concerns, we can instead add a new initial value to overflow (e.g. normal) that computes to either visible or clip depending on whether the element is actually replaced. I was excited with this proposal and assumed we could go with the used value override (the conclusion at #7435). But didn't think through the compat risk @Loirooriol pointed out. > I guess this should be to elements which may be replaced, but independently on whether they are actually replaced? The elements were specified explicitly to avoid this ambiguity. For other cases where an element may become replaced (like with the content property), the used value for overflow and overflow-clip-margin can be clip and content-box respectively and developer overrides don't apply (which is the behaviour today). > I worry this is not web compatible. is the compat risk here for cases where script uses getComputedStyle on these elements and the computed value for `overflow` changes? The used value would behave similar to setting overflow: clip in UA CSS in the original proposal but the value returned to script will change. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7144#issuecomment-1235881899 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 2 September 2022 20:45:09 UTC