Thanks for filing the issue!

Tried checking the issue on reported chrome version 71.0.3578.98 and on 60.0.3112.0 using Windows 10 and Mac 10.14.1

Our Observations:
-----------------
Version 71.0.3578.98 has different behaviour when compared with Safari, later checked for regression/non-regression on version 60.0.3112.0, but this version has neither the behaviour of Safari nor reported M71. Attaching the screen shot of the same for reference.

@Reporter: Could you please have a look at the screenshot showing behaviour of Safari and M60, and let us know if version 60.0.3112.0 is the expected behaviour. Your confirmation helps us to triage this further in a better way.

Deleted: 916277.png 861 KB

	916277.png 861 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for comfirming. In terms of displaying as multi-column, yes in chrome I could see xhtml is rendered with 3 columns which is good enough for this issue.

But I found some other issues from 916277.png:
1. most left side is cut-off (I guess this is because of location of snapshot?)
2. each column seems has width of 4em instead of 5em. I think from following css it is supposed to be 5em.
```
        html {
          width: 20em;
          columns: 5em auto;
          column-fill: auto;
          column-gap: 2em;
        }
```

This is correct behavior. When writing-mode is set on BODY, that writing mode is propagated to the viewport, but NOT to the root (HTML) element. So in that case we end up with a viewport in vertical-rl, a root (HTML) element in horizontal-tb (initial value; no properties are inherited from the viewport), and BODY in vertical-rl (as specified).

So, the root (HTML) element establishes a fragmentation context (multicol container), which is in horizontal-tb. The BODY child is vertical-rl, i.e. a new writing mode, which means that the block progression direction of lines of text is orthogonal to the block progression direction of the fragmentation context - so there'll be no break opportunities.

I guess this used to fragment nicely into columns before this fix:
https://chromium-review.googlesource.com/c/chromium/src/+/548379

Prior to that, Blink would actually propagate the BODY writing mode to the root (HTML) element, which isn't correct according to spec. I guess WebKit hasn't fixed this, and that this is why it still behaves differently in Safari.

I suggest that you instead specify both writing-mode:vertical-rl and columns on the root (HTML) element. Or, specify both writing-mode:vertical-rl and columns on the BODY element. I.e. do it all on the same element. Then it should work as you expect, I guess?

Thanks for explaining. Could you please point me to the css spec I should look for current hehavior (from "which isn't correct according to spec")? And where is css spec for "When writing-mode is set on BODY, that writing mode is propagated to the viewport, but NOT to the root (HTML) element."?

Yes the behavior changed at least once which caused this confusion. And we have work around to just apply vertical to body. But was wondering how this should be from chromium and css point of view.

https://www.w3.org/TR/css-writing-modes-3/#principal-flow

Thanks!

Oh, wait. From the principal-flow portion I can see this is kind of special case that root element has a body child element. So if I understood correctly in this case principal writing mode should be taken from body, right?

```
As a special case for handling HTML documents, if the root element has a body child element [HTML], the principal writing mode is instead taken from the values of writing-mode and direction on the first such child element instead of taken from the root element. Note that this does not affect the values of writing-mode or direction on the root element itself. 
```

Yes, it will be taken from BODY, but the writing-mode of the root (HTML) will not be affected by that.

ok I see what you meant. I took a look at multicol spec again and it seems multicol container is an element in this case it's root.
This might be grey that in writing mode 3 it said " Note that this does not affect the values of writing-mode or direction on the root element itself. " which I thought it's just value instead of layout because of following sentense "thereby affecting the layout of the root element" in next section.

Let me also check this out with editor.

The problem for us Digital Reading System (RS) using chromium as a rendering engine is vertical writing mode is specified by creator inside xhtml of "book" while multicol is specified by RS so that we as RS are not sure which element between root and body will creator use to specify vertical writing mode.

Oh, I see. Thanks for explaining.
But as long as you don't specify multicol on an ancestor of the element that establishes the writing mode, you should be fine, right? I don't know what assumptions you are allowed to make, but wouldn't it work if you specify multicol on BODY, for instance?