New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
fantasai opened this Issue May 18, 2017 · 9 comments

Comments

@fantasai
Contributor

fantasai commented May 18, 2017

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 ancestor 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

This comment has been minimized.

Member

dbaron commented May 24, 2017

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 ancestor, 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 ancestor
<zcorpan> Rossen_: I recall discussing this
<fantasai> s/nearest ancestor/nearest scrollable ancestor/
<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 ancestor, 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 fantasai closed this in f58289f Jul 19, 2017

@fantasai

This comment has been minimized.

Contributor

fantasai commented Jul 19, 2017

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

@fantasai

This comment has been minimized.

Contributor

fantasai commented Jul 19, 2017

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

This comment has been minimized.

Member

css-meeting-bot commented Aug 4, 2017

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 ancestor?
<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 ancestor 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 ancestor.
<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 ancestor 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 ancestor'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>
@frivoal

This comment has been minimized.

Contributor

frivoal commented Sep 20, 2017

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?

@frivoal frivoal reopened this Sep 20, 2017

@frivoal frivoal added the Agenda+ label Sep 20, 2017

@fantasai

This comment has been minimized.

Contributor

fantasai commented Sep 20, 2017

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

@frivoal

This comment has been minimized.

Contributor

frivoal commented Sep 20, 2017

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

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Sep 27, 2017

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].
@frivoal

This comment has been minimized.

Contributor

frivoal commented Jan 28, 2018

Spec change and Test cases merged. Closing.

@frivoal frivoal closed this Jan 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment