- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Oct 2020 16:35:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSSOM scrollWidth/scrollHeight behaviour of “overflow: clip”`, and agreed to the following: * `RESOLVED: scrollWidth/scrollHeight ignore overflow:clip when computing the value` <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: CSSOM scrollWidth/scrollHeight behaviour of “overflow: clip”<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5572<br> <fremy> Rossen_: iank_ raised this and emilo last added to the agenda<br> <fremy> Rossen_: who want to bring us up to speed?<br> <fremy> emilio: me<br> <fremy> emilio: we considered what scrollWidth/Height should return when overflow-clip is set<br> <fremy> emilio: there is not scrollbar<br> <fremy> emilio: but there is content out there<br> <fremy> emilio: the question is should we return the size as if there was scrollbar<br> <TabAtkins> +1 to behaving the same as visible, at least from first thoughts<br> <fremy> emilio: I think acting as visible is easier<br> <fremy> emilio: but iank_ said there is an optimization<br> <fremy> iank_: if you have overflow:hidden can be scrolled<br> <fremy> iank_: for visible, it still makes sense to return the full value, because it will cause scrollbars on ancestors<br> <TabAtkins> Hm, okay, Ian's making sense<br> <fremy> iank_: when you clip though, it's not useful, because it really does not exist<br> <fremy> iank_: but if you don't do that, you can return early<br> <fremy> iank_: because you don't need to calculate the scrollable overflow for the element when the value is fetched<br> <fremy> iank_: but it's not super important and only works if clip is in both directions<br> <fremy> smfr: the other option was what?<br> <fremy> iank_: report as if you had no children<br> <fremy> iank_: if the size is definite and you clip overflow, you don't need to layout the children<br> <fremy> iank_: but it's a small case<br> <fremy> smfr: and offsetWidth/offsetHeight?<br> <fremy> iank_: yes, this is the same as what I had in mind<br> <fremy> smfr: oh, in that case, yes, I prefer that option slightly<br> <fremy> Rossen_: other opinion?<br> <fremy> iank_: if I had to choose I would probably try to keep things consistent, but I really don't mind<br> <fremy> iank_: we just need to do something<br> <fremy> Rossen_: ok, let's get a summary of the two options and resolve<br> <fremy> iank_: option 1 is to do what we do when overflow:visible is applied (you need to layout the children to report that width)<br> <fremy> iank_: option 2: (ignoring overflow-clip-margin) report the size of the element ignoring whether or not you have something that will be clipped<br> <fremy> iank_: but if you have a clip margin, you need to do the full computation to see where inside that margin you land<br> <fremy> Rossen_: (restates the two proposals)<br> <fremy> fantasai: scrollWidth scrollHeight are asked on an element which is not scrollable<br> <fremy> fantasai: does that mean they are defined on all elements<br> <fremy> emilio: yes<br> <fremy> fantasai: ok, then, if we have a clipping, what happens if you have a border?<br> <fremy> iank_: they return content-box sizes, so it's a bit complicated<br> <fremy> fantasai: padding box you mean?<br> <fremy> iank_: yes, padding box size<br> <fremy> iank_: if you have no children, this is clientWidth/clientHeight, which is the padding box<br> <fremy> iank_: if you have a child, it returns whichever is bigger (the padding box or that child)<br> <fremy> iank_: so if you set overflow-clip with no margin, you can return the padding box because the child will not overextend<br> <fremy> iank_: but this only works if you dont have a margin<br> <fremy> iank_: if you have a margin, there could be an overflow<br> <fremy> iank_: so you need to do the full computation<br> <fremy> fantasai: the advantage of the doing like visible is that you get the value that tells you "how big should it be not to overflow"<br> <fremy> fantasai: the advantage of taking the clip into account, is that you know how much you will ask the parent scroller<br> <fremy> iank_: with proposal 2 you can't get answer 1<br> <fremy> iank_: but with proposal 1 you can compute the difference yourself<br> <fremy> Rossen_: this seems more clear now<br> <fremy> Rossen_: for "what you see is what you get" option 2 is nicer<br> <fremy> Rossen_: I don't want to do a straw poll, let's try to resolve<br> <fremy> Rossen_: can we resolve on option 2 which takes into account the visual clipping?<br> <Rossen_> q<br> <fremy> emilio: I lean towards option 1<br> <fremy> emilio: because I don't see strong arguments<br> <fremy> emilio: and for testing purposes, we can copy all the tests<br> <fremy> emilio: and we have shipped like that<br> <fremy> emilio: but this is not a super strong argument<br> <fremy> emilio: but given option 2 removes your ability to get the value of option 1<br> <fremy> emilio: I would rather we did 1<br> <fremy> Rossen_: if you want to get the bounds for the clip, what do you do?<br> <fremy> iank_: in script, you get the style of the clipping, then you do Math.min<br> <fremy> iank_: between scrollWidth and offsetWidth + the clip margin<br> <fremy> Rossen_: authors might not think about it<br> <fremy> Rossen_: and very often it's more useful to consider what is visible<br> <fremy> emilio: I don't disagree it's useful<br> <fremy> emilio: but scrollWidth is not the right API for that<br> <fremy> emilio: it's weird and legacy, so I would rather not change it<br> <fremy> Rossen_: ok let's do a poll<br> <fantasai> Given the arguments in favor of emilio's position, and the fact that you can get answers to the second question fairly easily with the first option but not the other way around, I'd be in favor of emilio's position<br> <fremy> Rossen_: because it's pretty split<br> <fremy> smfr: if we have scrollWidth behave like overflow:visible<br> <fremy> smfr: then you can't get the data and know if you can flip to visible without overflow<br> <fremy> fantasai: yes, option 2 hides info from authors you can't get otherwise<br> <fremy> fantasai: it's not great<br> <fremy> Rossen_: ok, then le'ts resolve for option 1<br> <fremy> RESOLVED: scrollWidth/scrollHeight ignore overflow:clip when computing the value<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5572#issuecomment-715448943 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 October 2020 16:35:23 UTC