- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Sep 2017 16:37:25 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Orthogonal Flow Constraint: viewport vs scroller<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1391<br> <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.<br> <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.<br> <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.<br> <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.<br> <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<br> <dael> Rossen_: My hopes is we either keep it more vague for now or we try and nail down all the permutations.<br> <dael> florian: For other permutations don't you need to do some kind of layout to figure them out?<br> <dael> Rossen_: You have to.<br> <dael> florian: My set you don't<br> <florian> s/my set/max height/<br> <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.<br> <dael> Rossen_: If we don't want that guar I'd prefer less rigerous and leave text as-is.<br> <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.<br> <fantasai> +1 to Florian<br> <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<br> <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.<br> <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.<br> <dael> Rossen_: I've stated my reason.<br> <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.<br> <dael> Rossen_: florian I thought you said that would also work with height auto<br> <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.<br> <fantasai> <div style="overflow: auto; height: 100px"><br> <fantasai> <div style="overflow: auto; max-height: 100px"><br> <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.<br> <dael> florian: I don't think it guar, I think it's never worse and sometimes better.<br> <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.<br> <dael> florian: I think it's easy, sometimes useful, never worse.<br> <dael> Rossen_: I would agree with that. It shouldn't make it worse.<br> <dael> Rossen_: Are there other opinions on this topic?<br> <dael> Rossen_: What is effect o nthe current tests for writing modes and what would it do for progress?<br> <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.<br> <dael> florian: If we write extensive tests we won't get 2 impl any way. We could write niave tests taht pass.<br> <dael> Rossen_: Current snapshot of the test suite was sometime last year, correct?<br> <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.<br> <dael> Rossen_: I'm just trying to understand where we are.<br> <dael> koji: As I understand lasst thing had 2 impl. And you said safari is slightly not interop<br> <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.<br> <dael> Rossen_: Other opinions?<br> <dael> Rossen_: Obj to add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing?<br> <dael> RESOLVED: add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing<br> <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.<br> <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.<br> <dael> Rossen_: A note that it's not guar is good for authors.<br> <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"<br> <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].<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1391#issuecomment-332581365 using your GitHub account
Received on Wednesday, 27 September 2017 16:37:16 UTC