W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2020

Re: [csswg-drafts] [css-contain-2] apply containment on `content-visibility: visible` ; use `normal` as initial value (#5695)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 03 Dec 2020 00:51:54 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-737587611-1606956713-sysbot+gh@w3.org>
The CSS Working Group just discussed ``[css-contain-2] apply containment on `content-visibility: visible` ; use `normal` as initial value``, and agreed to the following:

* `RESOLVED: Have separate keywords for the visbile and contained value vs initial value`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  [css-contain-2] apply containment on `content-visibility: visible` ; use `normal` as initial value<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5695<br>
&lt;vmpstr> auto?<br>
&lt;dael> TabAtkins: The issue here is that the hidden-matchable value switches content between 2 behaviors. One idential to hidden and one that's indescribable in current. That feels weird, don't normally have auto that goes to unrepresentable value<br>
&lt;dael> TabAtkins: Prop the other behavior that makes things visible have an explicit keyword<br>
&lt;dael> TabAtkins: Original proposal in thread is name that visible and change the default to normal. Chris points out that it's been shipped in Chrome so visible may be locked.<br>
&lt;dael> TabAtkins: I don't specifically want a name but I think we need the property<br>
&lt;dael> Rossen_: Is there data if it shoudl be frozen?<br>
&lt;dael> TabAtkins: content-visibility as a property is 1% of page loads. That gives reasonable sense there would be problems if we change<br>
&lt;vmpstr> q+<br>
&lt;dael> fantasai: Cases where likely to break seem unusual. You have to set it away from inital value and you would have to not be using containment. Seems like most of use cases you'd use containment with this or have explicit width and height in which case no change in behavior if we made this change<br>
&lt;dael> fantasai: I don't know for sure, but I think there's a change its safe. If there's a better keyword fine, but I think the properties are better if we make normal the default value<br>
&lt;dael> TabAtkins: I prop if people think general idea of the mode having a keyword we resolve on that. Then move back to GH on name and bring it back in a week or two<br>
&lt;vmpstr> q-<br>
&lt;dael> Rossen_: Works for me<br>
&lt;fantasai> s/change its/good chance its/<br>
&lt;dael> Rossen_: Okay, let's continue there<br>
&lt;dael> TabAtkins: Can we get the resolution to make a keyword for this behavior?<br>
&lt;dael> fantasai: Prop: Have separate keywords for the visbile and contained value vs initial value<br>
&lt;dael> Rossen_: Objections?<br>
&lt;dael> RESOLVED: Have separate keywords for the visbile and contained value vs initial value<br>

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 December 2020 00:51:56 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:23 UTC