Open Bug 1310551 Opened 8 years ago Updated 1 year ago

orthogonal flows (vertical writing-mode inside horizontal) can produce intrinsic sizes of 0, e.g. in floats & flex items

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

People

(Reporter: birtles, Unassigned)

References

(Depends on 1 open bug, Blocks 4 open bugs)

Details

Attachments

(4 files, 1 obsolete file)

Test case
(deleted), text/html
Details
Screencast demonstrating the problem
(deleted), video/webm
Details
testcase 2 (text should be inside box)
(deleted), text/html
Details
testcase 3 (using float instead of flex)
(deleted), text/html
Details
Attached file Test case (deleted) —
STR: 1. Load the attached test case 2. Observe that the text block is off center 3. Trigger a layout flush by, e.g. resizing the window 4. Observe that the text block is now centered 5. Reload the page 6. Observe that the text block is off center again Slightly simplified test case: http://codepen.io/birtles/pen/kkRxZd Try tweaking the CSS (e.g. add flex-direction: column to the styles) and notice that the block becomes centered. In Chrome the block is centered from the beginning. I'm not sure if writing-mode is actually related, however.
Attached video Screencast demonstrating the problem (deleted) —
Apparently, the width of div.content is not calculated correctly. Probably issue of intrinsic size calculation? I'm not quite sure how intrinsic inline size should be calculated if the two blocks are orthogonal... That may need us to support calculating intrinsic size on both axes, I suppose? Also cc jfkthame as he may know more about our implementation of writing modes.
For what it's worth, it would be really nice if we could fix this in the next week or so. We were hoping to use this content at MozFest.
Here's a reduced testcase. (It doesn't reproduce the "unstable layout" aspect of this bug, but it does have the content shifted too far to the right.) (Note: If I modify this testcase by removing the unstyled <div> (which wraps the vertical-writing-mode div), then we change to the correct rendering.)
Priority: -- → P3
(In reply to Jonathan Kew (:jfkthame) from comment #5) > I believe this is a case that's hitting the problem noted here: I think you're right, yeah. We're intrinsically sizing a horizontal-writing-mode element (asking for its ISize to resolve its default flex-basis), but it contains a vertical-writing-mode child, so we fail at measuring its ISize because its ISize is a function of its child's BSize. So we end up with an intrinsic size of 0. I'll attach a version of the testcase that demonstrates this with a float instead of a flex container.
Attachment #8948725 - Attachment description: testcase 3 (using float instead of flex container) → (incomplete version of testcase 3)
Attachment #8948725 - Attachment is obsolete: true
This testcase shows shows that we yield the same results in a float. (We produce a 0-width float -- which corresponds to the 0-width flex item in the earlier testcases here). Chrome does the "graceful" thing here -- probably needing to do layout during the intrinsic-sizing step in order to do so. Edge does something in between -- they produce a float with a width of 1-line-height, which isn't wide enough to hold the wrapped vertical text, but is big enough for some of it.
Summary: Flexbox layout unstable with writing-modes → orthogonal flows (vertical writing-mode inside horizontal) can produce intrinsic sizes of 0, e.g. in floats & flex items
Attachment #8948727 - Attachment description: test3.html → testcase 3 (using float instead of flex)
(In reply to Daniel Holbert [:dholbert] from comment #8) > Created attachment 8948727 [details] > testcase 3 (using float instead of flex) > > This testcase shows shows that we yield the same results in a float. (We > produce a 0-width float -- which corresponds to the 0-width flex item in the > earlier testcases here). > > Chrome does the "graceful" thing here -- probably needing to do layout > during the intrinsic-sizing step in order to do so. I believe so, if I'm remembering correctly what I've heard about it in the past. IIRC, dbaron has been pretty strongly opposed to doing this, though. FWIW, Safari (at least on macOS 10.12) behaves similarly to Firefox on this example. (Requires -webkit-prefixed version of writing-mode on the testcase.)
I think this is a version of bug 1166120 -- marking as dependency for now, though it may really be a duplicate.
Depends on: 1166120
(For my own notes, the original STR don't seem to reproduce the problem for me currently by simply resizing the window. But adding `flex-direction: column` and removing it again does.)

(In reply to Jonathan Kew (:jfkthame) from comment #9)

(In reply to Daniel Holbert [:dholbert] from comment #8)

Chrome does the "graceful" thing here -- probably needing to do layout
during the intrinsic-sizing step in order to do so.

I believe so, if I'm remembering correctly what I've heard about it in the
past.

IIRC, dbaron has been pretty strongly opposed to doing this, though.

It appears the CSS Writing Modes spec normatively requires that we do flow the child to figure out its used block-size:
https://www.w3.org/TR/css-writing-modes-3/#orthogonal-flows

This means that when applying shrink-to-fit formula to a box such as an inline-block, float, or table-cell, if its child establishes an orthogonal flow, the calculation dependency must be changed so that the sizing phase of the child runs first and its used block size becomes an input to the inline-size shrink-to-fit formula of the parent.

Blocks: 1506817
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)
Duplicate of this bug: 1839249
Duplicate of this bug: 1848512
Duplicate of this bug: 1473789
Duplicate of this bug: 1788187
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: