[css-writing-modes] Should max-height also limit orthogonal flows?

[fantasai]

Imagining a vertical flow inside a horizontal document: right now if the containing block of the orthogonal flow has a fixed height, we use that as a limit on the height of the orthogonal flow; otherwise we use the nearest fixed-size scrollport or the ICB. Should we also consider max-height?

[frivoal]

Are you referring to this part of the spec?

Putting a box in an orthogonal flow can result in the opposite: for the box’s available block space to be definite, but its available inline space to be indefinite. In such cases a percentage of the containing block’s inline size cannot be defined, and inline axis computations cannot be resolved. In these cases, [...]

Given that what we do "in these cases" does take max-height (of the scrollport) into account, then yes, it would make a lot of sense that deciding whether or not we are "in these cases" also takes max-height (of the parent) into account.

As far as Implementations go, we already have two (Blink and Webkit) passing this. I just made this test case to support this claim: web-platform-tests/wpt#9255

Whether they count as separate or not I am not sure, but 7.3.1 is generally not fully inter-operable or spec compliant anyway (as evidenced by the test results of available-size-001 through -010), so bug fixes will be needed, and this can be fixed along the way as necessary since it is related.

[FremyCompany]

I always thought this behavior (taking max-height into account) would make sense.

What is way less clear is whether working on updating orthogonal writing mode is what browser vendors should be doing right now... or, you know, fixing all these flexbox spec violations ;)

[css-meeting-bot]

The Working Group just discussed [css-writing-modes] Should max-height also limit orthogonal flows?, and agreed to the following resolutions:

• RESOLVED: Accept proposal in issue #2239

The full IRC log of that discussion

<dael> Topic: [css-writing-modes] Should max-height also limit orthogonal flows?
<fantasai> lajava, rego: If we can't solve before subgrid needs to ship, we can drop to the next level :)
<dael> github: https://github.com//issues/2239
<rego> :-)
<lajava> fantasai: sounds good
<dael> fantasai: We use the...if you have orthogonal flow we need to come up with a height contraint on vertical text so there's a line length.
<dael> fantasai: By default we use a combo of containing block if it's defined or nearest scrollport or initial containg block.
<dael> fantasai: Scrollport we only use if its fixed height.
<dael> fantasai: For contianing block we forgot to look at max height.
<dael> fantasai: Proposal is to modify spec to look at max height when there's and auto and a max.
<dael> fantasai: There is one impl already.
<dael> florian: We have 1 1/2 impl. Blink and Webkit do it.
<dael> Rossen_: From impl PoV it sounds reasonable.
<dael> Rossen_: We might already support this. It's been a while since I played with orthogonal flows. But it makes perfect sense.
<dael> Rossen_: Other thoughts, ideas, obj on having max-height be a constraint?
<dael> florian: I'm in favor we should look in all cases, not some.
<dael> fantasai: Agree.
<rego> +1
<dael> Rossen_: Would be good when we spec lang to word it such that the used content box height will be defined rather then auto. I'm saying this b/c we don't want to have to come back and say min-height also needs to be looked at in case it's bigger. Would be better to define it as defined not auto.
<liam> presnet+
<dael> fantasai: Yeah. We need to make sure we word for all cases. We can't use used height because if it's auto it depends on this ortogonal flows.
<dael> Rossen_: Agree.
<dael> Rossen_: Something like content box height would be defined. There's a combo of max an dmin height to make a limit.
<dael> fantasai: Sounds good.
<dael> Rossen_: I jsut don't want to ignore min height in this or have it sound like only max applies.
<dael> fantasai: Good point.
<dael> florian: Rossen_ to make sure I follow you say if min ehight is large it could come into account but smaller doesn't matter.
<dael> Rossen_: If there's something that will define a limit, such as max or min height. Min height only pushes the limit if it exists. Provided a limit exists and you have to look at min height it's used. I don't want us to forget about min height which is pushing the limit.
<dael> Rossen_: I didn't know how to clearly define it so I said used height but that's weak.
<dael> florian: Your point should be equalliy valid for containing block as scope. But yeah, I agree.
<fantasai> sgtm, I'll make the edits and Florian will review ;)
<dael> Rossen_: I think we have enough in the discussion that will go into the minutes. Anything else to add?
<dael> florian: Good to resolve
<dael> RESOLVED: Accept proposal in issue #2239

[frivoal]

@fantasai I've added variants of the available size tests to account for min-width as discussed on the call yesterday in the web-platform-tests/wpt#9255 Pull request.