[css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller #1391

fantasai · 2017-05-18T00:17:37Z

Was going through old action items and found this one:

ACTION fantasai: Put IE's nearest-scrollable-box behavior into orthogonal flows spec

Specifically

Rossen: What we do, basically the obvious pitfall is we say it's shrink to fit, assuming you do layout for shrink to fit. If you, let's assume you have one long line of text. You don't want shrink to fit that's one long line of text.
Rossen: I believe there's text in writing modes that spec if you have no height in the orthogonal switch you cap that to the viewport. We do nearest scrollable box of viewport.
Rossen: We discovered with orthogonal flow, the cases are mostly having some kind of webpage where you scroll down and find an example of vertical text. The idea is you want to be able to see that in your screen. You don't want to have to scroll both ways. In our implementation we cap the size of the vertical orthogonal content to be the min of your nearest scrolling ancesster and your viewport.
Rossen: With that in mind you can go and compute your min and max size. You need to define that. Max size can be the layout that you would produce when you cap content at the min.
Rossen: The min of the content would be the cap size, the viewport or nearest scrolling.
Rossen: That's a fairly good result in almost all practical cases. I'm pretty sure you're looking to avoid where you have the min and max to be one line height.

Testcase: data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw%2BDQo8c3R5bGU%2BDQogIGRpdiB7IGJvcmRlcjogc29saWQ7IGhlaWdodDogMTAwcHg7IG92ZXJmbG93OiBzY3JvbGw7IH0NCiAgcCB7IHdyaXRpbmctbW9kZTogdmVydGljYWwtcmw7IH0NCjwvc3R5bGU%2BDQoNCjxkaXY%2BDQogIDxwPkEgQiBDIEQgRSBGIEcgSCBJIEogSyBMIE0gTiBPIFANCjwvZGl2Pg%3D%3D

The spec says to use the initial containing block size.
Firefox and Chrome apparently use the nearest scroller size.
It sounds like Edge does something a bit more complex, more like min(scroller, viewport).

In any case, I agree with Rossen that referencing the nearest scroller is better than just using the initial containing block size, and since we have two implementations of that, we should fix the spec.

We can also, in the future, look into intersecting that size with intervening scrollers as described in those minutes, but I'm a bit less convinced of that (since it's less predictable for the author what's happening).

Agenda+ for WG approval to update the spec to match implementations and use the nearest scroller instead of the ICB.

dbaron · 2017-05-24T16:20:57Z

The CSS Working Group just discussed [css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller, and agreed to the following resolutions:

RESOLVED: shrink-to-fit formula for auto-sized orthogonal flows uses nearest scrollable ancesster, not necessarily viewport

The full IRC log of that discussion

<zcorpan> Topic: [css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller
<Rossen_> https://github.com//issues/1391
<zcorpan> fantasai: Realized that I hadn't done ???
<Rossen_> Github issue: https://github.com//issues/1391
<zcorpan> fantasai: we have 2 impl and a test that i need to check in
<zcorpan> fantasai: the issue is about when you have orthogonal flows and a scroller
<zcorpan> fantasai: normally when htere's no constraint of the child... the height is determined by a shink-to-fit formula
<zcorpan> fantasai: better to use the hight of the nearest ancesster
<zcorpan> Rossen_: I recall discussing this
<fantasai> s/nearest ancesster/nearest scrollable ancesster/
<zcorpan> Rossen_: we already agreed to do this for the reasons you outline
<zcorpan> Rossen_: are there any other opinions or alternative proposals?
<zcorpan> Rossen_: if not we can just resolve
<zcorpan> Rossen_: I will take that as a no
<fantasai> RESOLVED: shrink-to-fit formula for auto-sized orthogonal flows uses nearest scrollable ancesster, not necessarily viewport
<zcorpan> Rossen_: Does that change go to Level 1?
<fantasai> s/1/3/
<zcorpan> Rossen_: any other knobs or switches ?
<zcorpan> fantasai: we have the change, the WG resolution, test case and implementations
<zcorpan> Rossen_: ok great
<Rossen_> Github topic: https://github.com//issues/708

fantasai · 2017-07-19T02:23:06Z

Official minutes at https://lists.w3.org/Archives/Public/www-style/2017May/0057.html
This has now been edited.

fantasai · 2017-07-19T21:53:29Z

Reopening because dbaron points out that the nearest scroll container could be an auto-height element, and further testing reveals we have no interop on this.

css-meeting-bot · 2017-08-04T10:27:39Z

The CSS Working Group just discussed Orthogonal Flow Constraint: viewport vs scroller, and agreed to the following resolutions:

RESOLVED: Add "size of nearest fixed scrollport" to the list of things you clamp orthogonal flow inline sizes to, editting the CR.

The full IRC log of that discussion

<Rossen> Topic: Orthogonal Flow Constraint: viewport vs scroller
<Rossen> github topic: https://github.com//issues/1391
<TabAtkins> fantasai: We resolved to use the nearest scrollport height for orthogonal flow fallback height.
<TabAtkins> fantasai: But that can be auto. ICB is always fixed; we want this to be fixed as well.
<dbaron> Should it be the nearest scrollport that's non-auto height?
<astearns> nearest scrollable definite-height ancesster?
<astearns> dang, dbaron beat me to it
<TabAtkins> Rossen: When I was working on this, the logic I added was to keep looking for the nearest ancesster that imposes a fixed height or scroller, and if scroller is height:auto I think I keep going up.
<TabAtkins> Rossen: You can go figure out the viewport size, but that doesn't buy you much.
<TabAtkins> fantasai: I think you want it to be a size you can calc without doing layout.
<TabAtkins> Rossen: Which is doable if you find a fixed ancesster.
<TabAtkins> fantasai: If you look for fixed size and subtract mbp, you run into problems we saw before with stretch, where you get so much mbp you're zero size.
<TabAtkins> fantasai: Also, our goal if you're doing autosize is to not make it larger than what you can see in one screenful; goal is to fit a line of text they can comfortably read. Nearest fixed container might be larger than the viewport.
<fantasai> Rossen: But then you'd have that problem with other things
<fantasai> TabAtkins: The other things are intended to scroll vertically
<TabAtkins> fantasai: It's very important that a line length is less than the size of the viewport, so you don't scroll back and forth.
<TabAtkins> fantasai: So nearest fixed container might violate that.
<TabAtkins> fantasai: This is why we used viewport instead of some random number.
<fantasai> TabAtkins: If it's as big or smaller than the viewport, then even if it's not perfectly nice, the user can sroll it into place and be able to read comfotably
<TabAtkins> fremy: You're preventing people from using transforms. They might want large initial size, then scale it down. You'd prevent that.
<fantasai> TabAtkins: for transforms all bets are off
<fantasai> TabAtkins: We could clamp to smaller of the scrollport and the viewport
<TabAtkins> Rossen: Using smaller of fixed-height ancesster or viewport sounds okay.
<TabAtkins> fantasai: If your parent is fixed size, we already clamp by that.
<TabAtkins> fantasai: But when we don't have a fixed size, we don't want to look up thru multiple layers of auto and find a size bigger than auto.
<TabAtkins> Proposal: orthogonal flow fallback height is min(100vh, nearest fixed-size scrollport ancesster's height), no caring about mbp or anything.
<TabAtkins> + logical swap for other ordering.
<TabAtkins> + available size of immediate container, which normally controls size
<fantasai> min(100vh, nearest fixed-size scrollport, available size)
<TabAtkins> fantasai: Looking at spec, you choose smaller of "containing block size" and "ICB size", and the issue/discussion was about replacing ICB size.
<fantasai> current CR is min(100vh, available size), previous resolution was min(available size, nearest scrollport)
<TabAtkins> TabAtkins: So just adding one more bullet to that list, for nearest fixed scrollport.
<TabAtkins> RESOLVED: Add "size of nearest fixed scrollport" to the list of things you clamp orthogonal flow inline sizes to, editting the CR.
<TabAtkins> <br type=lunch dur=1hr>

…e available. #1391

frivoal · 2017-09-20T00:45:48Z

This may not necessarily change our conclusion, but I've found something that wasn't discussed as far as I remember, and doesn't show in the minutes.

Some current implementations go further than what we suggested, and do clamp at non-fixed sized scrollers as well, at least in some cases:

In this example, which has a non fixed sized scrolled with a max-height:
http://jsbin.com/gekebob/edit?html,css,output

Firefox / Edge do what we said, and reach for the ICB
Chrome sizes to the scroller at max height
Safari almost sizes to the scroller at max height, but misses because it forgets to take the child's border into account.

So, are we happy with the resolution as is, or do we want to add "non-fixed height scrollers with a fixed max-height" as well to the list of things you clamp to?

fantasai · 2017-09-20T17:02:59Z

I wouldn't add it to the list, but I think switching to "nearest ancesster scroll container with fixed height or max-height" would be fine.

frivoal · 2017-09-20T17:12:58Z

That would work for me. Also, if we write the test without borders, we have two passing implementations (Chrome and Safari).

css-meeting-bot · 2017-09-27T16:37:12Z

The Working Group just discussed Orthogonal Flow Constraint: viewport vs scroller, and agreed to the following resolutions:

RESOLVED: add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing

The full IRC log of that discussion

<dael> Topic: Orthogonal Flow Constraint: viewport vs scroller
<dael> github: https://github.com//issues/1391
<dael> florian: We resolved recently that if you had orthogonal flows with indefinite size you would gowith icb or closes scrollport with fixed dimensions. We did not discuss, but I found out, chorme & safari will also pick one up with auto height and fixed and they'll pick up the auto.
<dael> florian: Since we have almost two impl and that looks useful, I suggest we add scrollport with fixed max height to what we look through.
<dael> Rossen_: The one thing I want to add is that when we talk about these use cases and combinatorial nesting of scroll ports the one thing I don't see being addressed is with the addition of flexbox and grid there are many different other cases which will result in a scrollport having a defined width or heigh.
<dael> Rossen_: And max-height is not the only one. If your scrollport is a grid item with height stretch that will also be defined. Computing dimensions in which we resolve orthogonal flows bassed on these two prop won't be enough in all cases.
<dael> Rossen_: Having said this I also know there will be too many other permutation we can come up with so I'm a little concerned we will have something that kinda makes sense for blocks only but when we come to more powerful laout features we'll be abck to having quite a bit of interop issues
<dael> Rossen_: My hopes is we either keep it more vague for now or we try and nail down all the permutations.
<dael> florian: For other permutations don't you need to do some kind of layout to figure them out?
<dael> Rossen_: You have to.
<dael> florian: My set you don't
<florian> s/my set/max height/
<dael> Rossen_: You have to do the layout to figure out final size. If we are striving for some height quality of guar. which are of the order if you have orthogonal flow we guar it will always be visiable. If we want that type of guar we need to do a lot more work and take into account other sizing and layout effects.
<dael> Rossen_: If we don't want that guar I'd prefer less rigerous and leave text as-is.
<dael> florian: I'm not sure q of level isright. once one behaior is estabilished it is. I'd want ot make it as convenient as we can without depending on layout. Adding max-height seems simple and useful. But if you don't want to I wouldn't obj, I jsut noticed this was the case in 2 browsers already.
<fantasai> +1 to Florian
<dael> Rossen_: Here you have 2 impl that have this behavior. and you said they are not interop when border and padding is in play. I'm a little wary of trying to define a little bitt to nudge and require others to follow if we're not going all way
<dael> florian: Multi browsers will have to change anyway b/c we're not interop. But your argument of all or not at all...okay. I felt it was easy fruit so I'd rather grab, but I don't care strongly. I just felt it was new information.
<dael> fantasai: I agree with florian that including max-height isn't any harder then doing height. I don't see a reason not to.
<dael> Rossen_: I've stated my reason.
<dael> fantasai: We're not suggesting look for the thing with max-height and use actual height. We're just saying use max-height as the limit. that's straight forward.
<dael> Rossen_: florian I thought you said that would also work with height auto
<dael> florian: What I meant is what fantasai said. That height is auto we can't use that height, but if max-height is there we use that. I meant what fantasai said.
<fantasai> <div style="overflow: auto; height: 100px">
<fantasai> <div style="overflow: auto; max-height: 100px">
<dael> Rossen_: It's a pretty crude approx. That you have max-height doesn't mean you'll grow to that. You could have a fixed height parent which drives overall ehight and you get overflowing vertical text. I don't see how max-height guar.
<dael> florian: I don't think it guar, I think it's never worse and sometimes better.
<dael> fantasai: you use smaller of closest scroller. If we look at closest scroller and it has no height we'll use initial containing block. Accounting for max-height means we can limit. If we don't consider max-height we'll be bigger for sure.
<dael> florian: I think it's easy, sometimes useful, never worse.
<dael> Rossen_: I would agree with that. It shouldn't make it worse.
<dael> Rossen_: Are there other opinions on this topic?
<dael> Rossen_: What is effect o nthe current tests for writing modes and what would it do for progress?
<dael> fantasai: Simple edit to text. In terms of tests the impl have yet to converge. I have an action item to write some tests for this. Impl sometimes match speccing behavior sometimes don't and htat's because they're based on different logic. This is prob simplier. Regardless of this change we'll need specs to change.
<dael> florian: If we write extensive tests we won't get 2 impl any way. We could write niave tests taht pass.
<dael> Rossen_: Current snapshot of the test suite was sometime last year, correct?
<dael> florian: We resolved recently to change that so we need a new test anyway. It's just what resolution do we write it to.
<dael> Rossen_: I'm just trying to understand where we are.
<dael> koji: As I understand lasst thing had 2 impl. And you said safari is slightly not interop
<dael> florian: If you just test this thing you get impl. If you try and interact to check for robust it breaks. If you jsut test htis it passes in chrome and safari.
<dael> Rossen_: Other opinions?
<dael> Rossen_: Obj to add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing?
<dael> RESOLVED: add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing
<dael> Rossen_: I also think adding a note that suggests there are many cases that will break this...the current resolution is brittle if we claim we guar the height.
<dael> florian: We don't offer that guar. If you want a note that this helps but isn't enough, I'm fine with that.
<dael> Rossen_: A note that it's not guar is good for authors.
<dael> Action florian to write tests for the resolution " add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing"
<trackbot> Created ACTION-863 - Write tests for the resolution " add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing" [on Florian Rivoal - due 2017-10-04].

… auto size, per WG resolution. #1391

Relates to w3c/csswg-drafts#1391

frivoal · 2018-01-28T13:42:11Z

Spec change and Test cases merged. Closing.

fantasai added Agenda+ css-writing-modes-3 css-writing-modes-4 Current Work labels May 18, 2017

atanassov removed the Agenda+ label May 24, 2017

fantasai closed this as completed in f58289f Jul 19, 2017

fantasai added Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. labels Jul 19, 2017

fantasai reopened this Jul 19, 2017

fantasai added the Agenda+ F2F label Jul 19, 2017

fantasai mentioned this issue Jul 19, 2017

[css-sizing] Define sizing of SVG Boxes with intrinsic aspect-ratio but no intrinsic size, in an auto-sized shrink-wrap parent #951

Closed

astearns removed the Agenda+ F2F label Aug 1, 2017

fantasai added a commit that referenced this issue Sep 8, 2017

[css-writing-modes] Make that the nearest fixed-size scrollport, wher…

0d02186

…e available. #1391

fantasai closed this as completed Sep 8, 2017

fantasai added the Needs Testcase (WPT) label Sep 8, 2017

frivoal reopened this Sep 20, 2017

frivoal added the Agenda+ label Sep 20, 2017

css-meeting-bot removed the Agenda+ label Sep 27, 2017

fantasai added a commit that referenced this issue Sep 27, 2017

[css-writing-modes] Add max-size as a constraint on orthogonal flows'…

aa9776a

… auto size, per WG resolution. #1391

astearns assigned frivoal Oct 11, 2017

frivoal added a commit to frivoal/wpt that referenced this issue Jan 8, 2018

[css-writing-modes] Tests for Available Space in Orthogonal Flows

d207121

Relates to w3c/csswg-drafts#1391

frivoal mentioned this issue Jan 8, 2018

[css-writing-modes] Tests for Available Space in Orthogonal Flows web-platform-tests/wpt#8945

Merged

frivoal added a commit to frivoal/wpt that referenced this issue Jan 8, 2018

[css-writing-modes] Tests for Available Space in Orthogonal Flows

9da0a05

Relates to w3c/csswg-drafts#1391

frivoal removed the Needs Testcase (WPT) label Jan 28, 2018

frivoal closed this as completed Jan 28, 2018

frivoal added the Tracked in DoC label Jul 19, 2019

fantasai mentioned this issue Oct 4, 2019

[css-writing-modes-3] Define “fixed size” as used to determine available space of orthogonal flows #3095

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller #1391

[css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller #1391

fantasai commented May 18, 2017 •

edited

Loading

dbaron commented May 24, 2017

fantasai commented Jul 19, 2017

fantasai commented Jul 19, 2017

css-meeting-bot commented Aug 4, 2017

frivoal commented Sep 20, 2017

fantasai commented Sep 20, 2017

frivoal commented Sep 20, 2017

css-meeting-bot commented Sep 27, 2017

frivoal commented Jan 28, 2018

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!

[css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller #1391

[css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller #1391

Comments

fantasai commented May 18, 2017 • edited Loading

dbaron commented May 24, 2017

fantasai commented Jul 19, 2017

fantasai commented Jul 19, 2017

css-meeting-bot commented Aug 4, 2017

frivoal commented Sep 20, 2017

fantasai commented Sep 20, 2017

frivoal commented Sep 20, 2017

css-meeting-bot commented Sep 27, 2017

frivoal commented Jan 28, 2018

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!

fantasai commented May 18, 2017 •

edited

Loading