Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-writing-modes] Should max-height also limit orthogonal flows? #2239
Imagining a vertical flow inside a horizontal document: right now if the containing block of the orthogonal flow has a fixed
referenced this issue
Jan 30, 2018
referenced this issue
Jan 30, 2018
Are you referring to this part of the spec?
Given that what we do "in these cases" does take
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.
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 ;)
The Working Group just discussed
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
<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.
<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.
<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