Re: [csswg-drafts] [css-overflow] how should ignoring overflow on the *-start sides of the scrollport be done?

The Working Group just discussed `how should ignoring overflow on the *-start sides of the scrollport be done?`, and agreed to the following resolutions:

* `RESOLVED: Specify the webkit/blink behavior for issue #2006`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: how should ignoring overflow on the *-start sides of the scrollport be done?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2006<br>
&lt;dael> astearns: It sounded like idea is change the behavior so that things on start edges that are no in scrollpart do not contribute to scrollable area.<br>
&lt;dael> dbaron: Maybe I should step back. There's a long itnerop bug where edge/gecko do one and chrome/wk do another. I'm assuming english text in this.<br>
&lt;dael> dbaron: How things to the top or left of a scrollable area get ignored.<br>
&lt;dael> dbaron: Scrollable areas don't let you scroll to top or left. Itnteresting is top and right or left and below. In chrome/WK those don't contrinute to scrollable area. Edge &amp; Gecko the do.<br>
&lt;dael> dbaron: More webcompat is chrome &amp; wk behavior probably. Question is if we should spec that behavior or do something else.<br>
&lt;dbaron> Yeah, I thought I remembered discussing it before, but I couldn't find minutes...<br>
&lt;dael> Rossen: Thanks for bringing this up dbaron. This isn't a new topic. I remember, I think, smfr at the time saying that they do try and clip as many things as possible out of scrollable areas that will not be visible. They optimize for less empty space.<br>
&lt;dael> Rossen: Impl-wise there's quite a bit of inconsistancy between WK and Blink so when we spec this I would expect this to be kinda precise because if you start using things like position:relative you'll find that sometimes they will and sometimes they won't clip so even in their impl there's inconcstancy.<br>
&lt;dael> Rossen: I'm all for more interop and better UX, but I want to spec something that will be more concrete in terms of which bounds get clipped and how. Otherwise I support this.<br>
&lt;dael> Rossen: Do we have someone from WK or Blink?<br>
&lt;dael> ??: I just joined and don't know topic<br>
&lt;dael> astearns: [summerizes]<br>
&lt;dael> astearns: Sounds like rough consensus on spec WK/Blink behavior as long as we come up with a consistant way of desc.<br>
&lt;astearns> s/??/hober/<br>
&lt;dael> Rossen: Yeah, that's my only feedback that when we spec we should be explicit on what bounds we consider when compute scrollable bounds. So things like are we considering visible bounds, things offser by relpos, transforsm, so forth and so forth<br>
&lt;dael> astearns: Obj to spec blink/webkit behavior for this issue?<br>
&lt;dael> RESOLVED: Specify the webkit/blink behavior for issue #2006<br>
&lt;dael> astearns: dbaron will you make the overflow spec edits?<br>
&lt;dael> dbaron: It's a little ways out in terms of figuring out behavior first.<br>
&lt;dael> astearns: It would be nice to have blink/wk contribution to help spec the behavior.<br>
&lt;dael> hober: I can take an action to drum up a desc.<br>
&lt;dael> ACTION hober get a description of the behavior for issue #2006<br>
&lt;trackbot> Created ACTION-866 - Get a description of the behavior for issue #2006 [on Theresa O'Connor - due 2017-12-27].<br>
</details>


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

Received on Wednesday, 20 December 2017 17:12:26 UTC