CSS Writing Modes 3 says:

As a special case for handling HTML documents, if the root element has a body child element [HTML], the used value of the of writing-mode and direction properties on root element are taken from the computed writing-mode and direction of the first such child element instead of from the root element’s own values. The UA may also propagate the value of text-orientation in this manner. Note that this does not affect the computed values of writing-mode, direction, or text-orientation of the root element itself.

It seems like the obvious way to implement this would be by changing the mWritingMode stored on the frame, and a nice place to do this might be here.

However, there are a few issues with this:

• we're currently set up so that dynamic changes to these properties cause frame reconstruction. This implies that we need to make insertion of the primary body, removal of the primary body, change of which body is the primary body, and style changes of these properties on the body all cause frame reconstruction of the root element. This doesn't seem all that expensive, but it's a bit of a pain.
• it seems like we don't want to modify the root's writing mode while we're initializing body, and I'm not sure if there's a great way to get the body's style while we're initializing the root.... although maybe if we've done the previous item we can assume that setting mWritingMode on the root while initializing the body is safe to do.

I'm curious if Emilio had a better idea for how to do this, since apparently he suggested to Florian that he could fix this.

There are a bunch of tests in the CSS test suite that this should fix, including wm-propagation-001 and wm-propagation-002, wm-propagation-body-032, etc.

I don't recall having mentioned particular interest on implementing this, other than it being both technically feasible and that Hiro mentioned it on a comment not long ago (but I couldn't find it from a quick email search :/).

I'd actually say that I'm midly sad about adding more propagation-from-body stuff. We have already some of those nasty reframes for overflow changes, and dynamic cases that no engine handles correctly...

(Also note that due to implementation details Chrome is p. unlikely to adopt this particular change)