[css-writing-modes] Orthogonal Flow Constraint: viewport vs scroller #1391
Assignees
Labels
Closed Accepted by CSSWG Resolution
Commenter Satisfied
Commenter has indicated satisfaction with the resolution / edits.
css-writing-modes-3
css-writing-modes-4
Current Work
Tracked in DoC
Comments
|
The CSS Working Group just discussed
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 |
|
Official minutes at https://lists.w3.org/Archives/Public/www-style/2017May/0057.html |
|
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. |
|
The CSS Working Group just discussed
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> |
|
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:
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? |
|
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. |
|
That would work for me. Also, if we write the test without borders, we have two passing implementations (Chrome and Safari). |
|
The Working Group just discussed
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]. |
fantasai
added a commit
that referenced
this issue
Sep 27, 2017
… auto size, per WG resolution. #1391
frivoal
added a commit
to frivoal/wpt
that referenced
this issue
Jan 8, 2018
frivoal
added a commit
to frivoal/wpt
that referenced
this issue
Jan 8, 2018
|
Spec change and Test cases merged. Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Was going through old action items and found this one:
Specifically
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.
The text was updated successfully, but these errors were encountered: