Re: [csswg-drafts] [css-overflow] Should overflow-clip-margin apply to scrollable boxes? (#10745)

The CSS Working Group just discussed `[css-overflow] Should overflow-clip-margin apply to scrollable boxes?`, and agreed to the following:

* ``RESOLVED: `overflow-clip-margin: content-box` applies to scrollable boxes``

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> emilio: not super high prio, but been agenda for a while<br>
&lt;TabAtkins> emilio: i don't think you can get the behavior of some of the built-in form controls regarding overflow clipping without something like this<br>
&lt;TabAtkins> emilio: in particular, textarea clips in the content-box in the inline-axis, input also has something weird<br>
&lt;TabAtkins> emilio: it seems useful to allow values that make the clip smaller than the padding box<br>
&lt;flackr> q+<br>
&lt;TabAtkins> emilio: per spec it only applies to overflow-clip right now, but i think it woudl be useful on scrollable boxes as well. was wondering about feelings on this<br>
&lt;astearns> ack fantasai<br>
&lt;astearns> ack flackr<br>
&lt;TabAtkins> flackr: i had the impression that we previously wanted to allow scrollable content to extend outside the scrolling box<br>
&lt;TabAtkins> flackr: a bunch of UI interfaces - you dont' want the scrollbar larger, but you want content behind the header, etc<br>
&lt;TabAtkins> emilio: that seems... maybe doable<br>
&lt;TabAtkins> emilio: would need to think more about that impl wise<br>
&lt;TabAtkins> emilio: at that point you may want to change the scrollbar region more than the scrolling region itself...<br>
&lt;TabAtkins> flackr: yeah, mayb<br>
&lt;TabAtkins> emilio: but i think the uncontroversial thing would be to allow things inside the padding box<br>
&lt;TabAtkins> emilio: would look cool to allow positive values, but not sure how it would look with borders/etc<br>
&lt;vmpstr> q+<br>
&lt;TabAtkins> emilio: maybe that just works?<br>
&lt;TabAtkins> flackr: yeah feels like you'd want it behind the border, in front of background<br>
&lt;TabAtkins> (border is already on top of background)<br>
&lt;astearns> ack vmpstr<br>
&lt;TabAtkins> vmpstr: q about scrolling with a mousewheel or trackpad<br>
&lt;TabAtkins> vmpstr: if... if the mouse is in padding area does it scroll the content?<br>
&lt;TabAtkins> vmpstr: if the content is outside the scroller, presumably doesn't scroll<br>
&lt;TabAtkins> vmpstr: if there's visual information about the content out there, is that meant to be scrolled by the mousewheel?<br>
&lt;TabAtkins> emilio: I'd like to avoid discussing positive margin right now because i haven't thought about it, and it does raise more questions<br>
&lt;TabAtkins> emilio: i think for inner, right now Firefox bheavior is to scroll when you're in padding box<br>
&lt;TabAtkins> emilio: textarea behavior exists now, so we could crib off of that<br>
&lt;TabAtkins> emilio: but otherwise yeah, good question<br>
&lt;TabAtkins> q+<br>
&lt;bramus> TabAtkins: so we are only discussing negative values. does that mean positive ones are clamped to 0 at the moment and in the future we might allow them?<br>
&lt;TabAtkins> emilio: yes, most reasonable right now. perhaps in the future we could add a support keyword<br>
&lt;bramus> TabAtkins: its the ability to detect future supoort that i am worried about, but i think we have the tools to figure tha tout<br>
&lt;fantasai> spec only allows positive values?<br>
&lt;fantasai> https://drafts.csswg.org/css-overflow-4/#overflow-clip-margin<br>
&lt;TabAtkins> emilio: currently it's already ignored on scorllable, which has same issue if we start doing it<br>
&lt;TabAtkins> emilio: but if we need to we can add feature detection as needed<br>
&lt;astearns> ack TabAtkins<br>
&lt;TabAtkins> vmpstr: so positive values grow; we're only discussing negatives that shrink<br>
&lt;TabAtkins> astearns: it's possible we'll run into compat issues if people are over-applying right now?<br>
&lt;TabAtkins> emilio: potentially, yes. i think it's unlikely, but i've been wrong before.<br>
&lt;bramus> TabAtkins: can always add an opt-in keyword to the property<br>
&lt;TabAtkins> emilio: so if people agree, allowing values taht shrink the clipping box for scrollable boxes<br>
&lt;TabAtkins> emilio: i was just trying to kill the internal mechanism<br>
&lt;TabAtkins> TabAtkins: just to clarify, elika pointed out in IRC that negative values are invalid. we're *actually* just taklinga bout allowing the box keywords to work on scrollable boxes, which can shrink the clip region ot smaller than what it currently is<br>
&lt;TabAtkins> emilio: it's probably worth ahving a separate issue for negative values<br>
&lt;TabAtkins> emilio: i'll file a separate issue<br>
&lt;TabAtkins> astearns: so proposed for this issue is to allow overflow-clip-margin: content-box to apply to scrollable containers<br>
&lt;TabAtkins> emilio: preferred is allow use of overflow-clip-margin on scrollers that shrink the clipping box<br>
&lt;TabAtkins> emilio: that is currently just the 'content-box' keyword<br>
&lt;TabAtkins> emilio: but if we allow negatives, it'll be a more general resolution<br>
&lt;TabAtkins> astearns: yeah, but i'd like the shrinking mechanism explored more specifically before we allow it generally here. tighter resolution for now<br>
&lt;TabAtkins> emilio: faire<br>
&lt;TabAtkins> astearns: objections to allowing content-box value to apply to scrollable containers?<br>
&lt;TabAtkins> RESOLVED: `overflow-clip-margin: content-box` applies to scrollable boxes<br>
</details>


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


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

Received on Wednesday, 11 December 2024 17:50:25 UTC