- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Apr 2020 17:41:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Scrollbars when intrinsic-width is > width?`, and agreed to the following: * `RESOLVED: contain-intrinsic-size defines scrollable overflow area for purpose of intrinsic sizing (including adding scrollbars if so required); is ignored for the actual scrollable overflow area during layout` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Scrollbars when intrinsic-width is > width?<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4415#issuecomment-614345165<br> <tantek> wow this seems like a historically painful one<br> <fantasai> TabAtkins: Following along from the linked "top of thread"<br> <fantasai> TabAtkins: now that contain-intrinsic-size defined to give result of doing child layout<br> <fantasai> TabAtkins: basically, pretend that bounding box of your laid-out contents is this size<br> <fantasai> TabAtkins: Should that trigger scrollbars or not?<br> <fantasai> TabAtkins: we think it should<br> <fantasai> TabAtkins: because if the contents were that large, they would indeed create scrollbars<br> <fantasai> TabAtkins: And we're saying, here's a shortcut to running your layout<br> <fantasai> TabAtkins: biesi brought up question of what does this mean for intrinsic size?<br> <fantasai> TabAtkins: is the intrinsic size that plus crollbars or what?<br> <fantasai> TabAtkins: Have a specified width, contain-intrinsic-size is wider than that, adds a scrollbar to the bottom<br> <fantasai> s/width/width and auto height/<br> <fantasai> TabAtkins: Result of applying that is that width is specified width, auto height is resolved according to 'contain-intrinsic-size' plus mbp<br> <fantasai> TabAtkins: if you add 'overflow: auto'<br> <fantasai> TabAtkins: contents wider than box would add a horizontal scrollbar to the bottom<br> <fantasai> TabAtkins: would height of scrollbar be added to the auto height?<br> <fantasai> s/height/height (based on contain-intrinsic-size)/<br> <fantasai> cbiesinger: There was a proposal in the issue that the used size should be max of actual content size and contain-intrinsic size, and that is where it gets complicated<br> <fantasai> cbiesinger: because then you need to know the actual content size to know whether there's a scrollbar<br> <fantasai> iank_: For purposes of layout overflow calcualtion, the content size rectangle is unioned with previous calc?<br> <fantasai> TabAtkins: stepping away from contain-itnrinsic-size for the moment<br> <fantasai> TabAtkins: if you have contain + overflow: auto<br> <fantasai> TabAtkins: assume zero size content<br> <fantasai> TabAtkins: if you add content, can you not scroll to it?<br> <fantasai> iank_: depends on impl<br> <fantasai> iank_: we will currently add scrollbars, rerun layout<br> <fantasai> iank_: This will affect intrinsic size of the box<br> <fantasai> iank_: unsure what ff does<br> <fantasai> dholbert: we do not do that relayout<br> <fantasai> dholbert: we treat it as zero height / width as if explicitly specified<br> <fantasai> dholbert: in the case of zero width/height, you wouldn't see it<br> <fantasai> cbiesinger: Don't remember how we handle this, we maybe increase the size of the element<br> <fantasai> TabAtkins: dholbert, if you have 'contain: size' element with specified height of '100px' and ?<br> <fantasai> TabAtkins: would you say that ff wont' show scrollbars?<br> <fantasai> dholbert: if we have space to show scrollbars we will<br> <fantasai> dholbert: just won't influence sizing of the box<br> <fantasai> TabAtkins: That's reasonable to me, and if that's what we want to be more specific about, I'm fine with doing that<br> <fantasai> cbiesinger: I think that's more reasonable behavior<br> <fantasai> AmeliaBR: Balance of that is, if there is room for scrollbars we will put them<br> <fantasai> AmeliaBR: if the intrinsic size is bigger than contain size<br> <fantasai> AmeliaBR: [...]<br> <fantasai> cbiesinger: Downside is that you'll definitely get scrollbars in the other side, too<br> <fantasai> TabAtkins: oh, yes, becaue if you say `contain-intrinsic-size: 200px`<br> <fantasai> TabAtkins: ...<br> <fantasai> AmeliaBR: proposal I suggested was that, as soon as you know you have scrollbars, you only do either the intrinsic sizing or the content and the intrinsic size goes away<br> <fantasai> AmeliaBR: Another thing I just thought of is we have an option for an overflow value where the scrollbars never take away content size<br> <fantasai> AmeliaBR: is there a way maybe to say, for the purpose of the 'contain-intrinsic-size' calculation, we always treat as overlay scrollbar instead of as scrollbar that takes away content size?<br> <fantasai> AmeliaBR: while still laying out content size as normal?<br> <fantasai> TabAtkins: in other words, treat 'contain-intrinsic-size' rectangle as ignoring scrollbar for determining if there's overflow in a given axis<br> <AmeliaBR> s/content size/the actual content/<br> <TabAtkins> SCribeNick: TabAtkins<br> <TabAtkins> fantasai: I think we should say the actual scrollable overflow area is the union of the content and c-i-s<br> <TabAtkins> fantasai: But size the box as if the scrollable overflow area is only the area given by c-i-s<br> <TabAtkins> fantasai: You'll possibly need to add a scrollbar then, but it's only dependent on c-i-s, not content<br> <AmeliaBR> s/[...]/then there will be scrollbars, the same as for content larger than for the contained size/<br> <astearns> ack fantasai<br> <tantek> I was only able to follow partially as well.<br> <TabAtkins> fantasai: If your c-i-s is accurate (matches content size), you'll get scrollbars, and size will accommodate the scrollbars as you'd expect<br> <TabAtkins> fantasai: if c-i-s is too big, you'll get to scroll to more area than the contenta ctually takes<br> <tantek> As much as we want to avoid having unviewable content, I'd also like to see us adopt a principle of making it *easy* for web authors to avoid automatic scrollbars showing up especially when "it doesn't seem like they should be needed"<br> <TabAtkins> fantasai: if c-i-s is too small, you might get two scrollbars rathe rthan one, but you'll still bea ble to scroll to everyone<br> <TabAtkins> cbiesinger: The scrollbar is still in the area defined by c-i-s, right?<br> <TabAtkins> fantasai: If you have an element sized to fit content exactly, and then you set that size explicitly, then add more content that creates a scrollbar, you end up adding a scrollbar to the bottom as well.<br> <tantek> yeah I pretty much hate this problem<br> <TabAtkins> fantasai: So you can still scroll to see everything, but one of the scrollbars might just be scrolling a tiny bit<br> <TabAtkins> fantasai: You'll get into that situation if your c-i-s is inaccurate.<br> <TabAtkins> cbiesinger: I think if you overflow in one direction, you'll alway sget two scrollbars.<br> <tantek> would really prefer to avoid situations where we make the layout so scrollbar-fragile that it's too easy to cause scrollbars<br> <dholbert> q+<br> <TabAtkins> fantasai: Say you have 100x100 box, c-i-s is 200px tall, ou'll get a vertical scrollbar<br> <TabAtkins> cbiesinger: If your scrollable area is the union of content and c-i-s<br> <TabAtkins> cbiesinger: Then c-i-s needs to be scrollable-to. And since scrollbar is in that area defined by c-i-s, you'll always need a scrollbar for it.<br> <tantek> in particular when a vertical scrollbar shows up e.g. due to fantasai's example, it should not *also* cause a horizontal scrollbar<br> <tantek> that's a particularly bad side-effect to avoid<br> <fantasai> ScribeNick: fantasai<br> <fantasai> fantasai: No, that's not what I'm saying<br> <fantasai> fantasai: What I'm saying is, you size based on c-i-size<br> <cbiesinger> <div style="width: 100px; contain-intrinsic-size: 100px 100px; overflow: auto;"><div style="width: 120px;"></div></div><br> <fantasai> fantasai: and c-i-size increases size of scrollable overflow area<br> <fantasai> fantasai: potentially causing scrollbars, which get accounted for<br> <fantasai> fantasai: based on that, you size the box.<br> <cbiesinger> you get a horiz scrollbar. this covers up the bottom 15px or so of the 100px c-i-s<br> <fantasai> fantasai: then after you lay out the contents, you increase the scrollable overflow area (if needed) to fit the contents, so that you're not clipping anything<br> <cbiesinger> but the scrollable area is the union of actual contant and c-i-s<br> <fantasai> fantasai: this increases the size of the scrollable overflow area, but does not change the size ofthe box<br> <cbiesinger> so you need to be able to scroll to that<br> <cbiesinger> no?<br> <fantasai> fantasai: so you might get extra scrollbars added if your c-i-s value wasn't accurate. But at least you can see all the contents<br> <fantasai> TabAtkins: So, example here, you have a float<br> <fantasai> TabAtkins: it as contain-intrinsic-size of 200px x 200px<br> <fantasai> TabAtkins: specified height of 100px<br> <fantasai> TabAtkins: this should create a vertical scrollbaron the right<br> <fantasai> TabAtkins: what should be the float's width, assuming no mbp?<br> <fantasai> TabAtkins: Should it be 200px or 216px, to account for scrollbar<br> <tantek> Thank you Tabatkings, that's exactly the problem I was referring to<br> <cbiesinger> yes, that's what I was asking too<br> <fantasai> fantasai: Yes, it would be 216px<br> <tantek> s/Tabatkings/TabAtkins<br> <TabAtkins> cbiesinger: How can that be 216px if the scrollbar doesn't affec the size of the box?<br> <fantasai> AmeliaBR: ...<br> <fantasai> AmeliaBR: but if scrollbar is created by c-i-s, that affects the size of the box<br> <TabAtkins> AmeliaBR: So a scrollbar form content shouldn't affect the size of the box, but a scrollbar from c-i-s should affect the size of the box?<br> <fantasai> AmeliaBR: if we're in a context where just the dimensions that we have on the container, combination of explicit sizes plus contain-itnrinsic-size are enough to create a scrollbar<br> <fantasai> AmeliaBR: and usually scrollbar would be outside the content<br> <fantasai> AmeliaBR: normally a scrollbar would go inside defined widht of container<br> <fantasai> AmeliaBR: but not necessarily in something like a float, which doesn't have a defined width<br> <cbiesinger> <div style="width: 100px; contain-intrinsic-size: 100px 100px; overflow: auto;"><div style="width: 120px;"></div></div><br> <fantasai> fantasai: ...<br> <TabAtkins> fantasai: In that example,<br> <fantasai> cbiesinger: You end up a horizontal and a vertical scrollbar<br> <TabAtkins> fantasai: Your width is specified, so it won't grow. cis width is fine. There's no height specified, so it sizes to 100px tall.<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=8034<br> <fantasai> cbiesinger: because horizontal scrollbar takes up space<br> <iank_> (view in chrome canary)<br> <fantasai> fantasai: yes. But size of box would be 100px, doesn't grow<br> <TabAtkins> cbiesinger: Right, then the content is 120px tall, so you need a vertical scrollbar. And that covers up part of the 100px cis, so you get a horiz scrollbar too<br> <TabAtkins> fantasai: yes<br> <fantasai> dholbert: I think mental model of it that makes sense:<br> <fantasai> dholbert: sounds like we size scrollable overflow area as if only one child size of c-i-s<br> <fantasai> dholbert: other elements are sized similar to abspos, don't affect sizing<br> <fantasai> dholbert: I think that approximately matches<br> <fantasai> TabAtkins: Problem with children, grid + multicol act very differently if have one child<br> <fantasai> TabAtkins: if ignore that, prtend block layout with one child, that works<br> <fantasai> cbiesinger: so Ian's testcase, Chrome is wrong<br> <fantasai> iank_: so width of this element should be 100px?<br> <fantasai> fantasai: that's what I'm saying<br> <cbiesinger> Ian's testcase would get two scrollbars, then<br> <fantasai> fantasai: the point of the feature was that box doens't resize in response to contents<br> <fantasai> fantasai: so should not change size<br> <fantasai> fantasai: but also should not clip contents, or make them inaccessible underneath scrollbars<br> <fantasai> TabAtkins: so use c-i-s to figure out if you need to add a scrollabr<br> <fantasai> TabAtkins: but then when do layout, then ignore c-i-s for purpose of scrollbar<br> <fantasai> TabAtkins: so adding vertical scrollbar for excess content won't change the size<br> <fantasai> TabAtkins: but won't trigger extra scrollbars due to c-i-s<br> <fantasai> TabAtkins: want content to be reflowable, and avoid unnecessary scrollbars<br> <fantasai> TabAtkins: so c-i-s should factor into scrollable overflow area during intrinsic sizing<br> <fantasai> TabAtkins: but not affect the scrollable overflow area when actually laying out the content<br> <fantasai> cbiesinger: makes sense<br> <fantasai> fantasai: +1<br> <fantasai> iank_: So during intrinsic sizes phase, if we have size containment, we ignore the scrollbar, but if not we include?<br> <fantasai> cbiesinger: in intrinsic size phase, include scrollbar iff contain-intrinic-size triggers overflow<br> <fantasai> cbiesinger: for actual layout, do what we do today<br> <fantasai> TabAtkins: I think we fall back to model where post doing intrinsic size layout, lay out as if that was an explicit width + height<br> <fantasai> TabAtkins: proposed resolution is, 'contain-intrinsic-size' is used to figure out whether or not scrollbars should show up during sizing of container. Scorllbars that would appear are factored in.<br> <fantasai> TabAtkins: but when doing layout of interior contents, 'contain-intrinsic-size' has no effect -- cannot trigger additional scrollbars. Only the actual contents affects scrollbars<br> <tantek> I agree with the resolution, and let's explicitly capture the principle that no additional scrollbars should appear<br> <fantasai> RESOLVED: contain-intrinsic-size defines scrollable overflow area for purpose of intrinsic sizing (including adding scrollbars if so required); is ignored for the actual scrollable overflow area during layout<br> <fantasai> cbiesinger: there can be actual scrollbars depending on the actual contents, just not based on contain-intrinsic-size<br> <tantek> right what Tab said, not caused by the c-i-s value<br> <fantasai> astearns: let's get testcases<br> <fantasai> AmeliaBR: scrollbars should not be caused by interaction of actual content and c-i-s<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4415#issuecomment-621360752 using your GitHub account
Received on Wednesday, 29 April 2020 17:41:30 UTC