Thanks. Supposedly if we supported both "vertical-scroll" and "horizontal-scroll" as separate features (bug 841668) wouldn't this example have been resolved through applying "horizontal-scroll" instead?

Yes, it will be possible to accomplish by a smart developer correctly choosing vertical or horizontal in the right cases. My concern was whether it will be easy enough / caught by the developer when the other policy must be used. For example, imagine a CMS setting the vertical scroll policy (to ensure that the page scrolls smoothly) and a separate language setting which causes the primary writing direction to change to horizontal.

The problem itself makes a lot of sense to me (unrelated: I remember ScrollFocusedEditasbleElementIntoView() is one example where we  zoom to a proper rect around input caret -- assuming the caret is for LTR horizontal editing).

I also agree it could be an abstract concept -- or a method which relates "enforcing vertical scrolling" to some direction to be determined based on context.

The part that concerns me though is that to determine this direction seems complicated. Essentially it does not look very clear-cut. What happens if frame includes various types of writing modes; or what if the content's style changes between different modes?

On a separate note this bug should be blocked on having both 'vertical-scroll' and 'horizontal-scroll' implemented.

I think making these logical direction and not physical directions potentially makes sense in the spirit of having different writing modes just do the right thing without authors needing to think about it (block-scroll/inline-scroll). It would be based off the writing mode of the parent of the frame though, not the contents of the frame.

I guess it does weird things if you nest orthogonal writing modes, so I think the simplest thing would be to just having it be the writing mode of the iframe's parentElement and ignore the rest of the ancestry chain.

Although, that does potentially lead to an abuse of this to reenable scrolling by nesting a the frame in question into an iframe with an orthgonal writing mode. That only works if scrolling is disabled in a specific direction though, and is probably hard enough to find, with low enough benefit, that it's not likely to be a common exploit.

+tabatkins, the master of all things writing mode.