Topic on Talk:Requests for comment/Vertical writing support

Arch summit summary

11
TheDJ (talkcontribs)

There was no opposition to implementing this, but some barriers were identified.

  • We know of some bugs in browser support, but that was not seen as a big problem since it won't impact anything else.
  • Some languages actually switch between directions these days (Chinese, Japanese, Korean can be horizontal or vertical, and are often vertical in print) (Use language variants ?)
  • CSSJanus will need fixing for vertical support. Actually doing this would be trivial and Roan & Trevor will gladly help anyone to do this.
  • However before fixing CSSJanus, we need a language -> rotation map, like we have for rtl/ltr directionality. Ideally we would get this information from CLDR (http://unicode.org/cldr/trac/browser/trunk/common/properties/scriptMetadata.txt), but it is not in that so we need to bolt it on top of our language data first. (the Translate/Localization team can be involved)
  • Scripts will need rotating. style.top becomes style.left, width > height, $.slideUp > $.slideLeft, etc. hopefully some way to make this at least semi-automatic. (Since we don't have too much centralization of this and significant upstream, this might be problematic)
  • Automatic rotating of inline styles for languages that need to switch between rotation. (if we start with the languages that don't switch [ASL] then this would be less of a blocker.
Mxn (talkcontribs)

CSS's logical positioning properties like margin-start and padding-end could be used to support left-to-right, right-to-left, and vertical layouts without having to do too much dynamic rewriting via CSSJanus.

Yair rand (talkcontribs)

Unfortunately, those properties are not part of the specification, and are also not supported by IE, so I don't think using them would really be feasible.

Slevinski (talkcontribs)

Using the current standard of vertical writing mode is not a complete CSS solution for SignWriting. For SignWriting, within a paragraph of text, the line-height of each column needs to vary based on the column's contents. Extremely wide columns need to be able to coexists with skinny columns. Changing the text area size should automatically reflow the signs between the columns and adjust each column's line-height. This feature is not supported in any browser or any spec.

To support this unique aspect of the script, the old ASL Wikipedia on Labs is currently being used to print the 48 articles.

The ASL Wikipedia on Incubator should probably use the vertical writing mode, but it is not a complete CSS solution. The SignWriting gadget would need to be adjusted according to the environment.

Yair rand (talkcontribs)

(I think I might have a CSS solution to the line-height issue, actually. Still working on it.)

Yair rand (talkcontribs)

Apparently there is an Editor's Draft on CSS logical properties.

I doubt this will be usable for a very long while, but it might be beneficial to add some JS $.cssHooks (or $.cssProps?) with those property names (perhaps prefixed with -mw-) to simplify adapting JS.

Mxn (talkcontribs)

Thanks for the link. The current support for logical properties is limited to WebKit/Blink (-webkit-) and Gecko (-moz-), though vertical text hasn't been implemented in Gecko yet. So physical properties are the only option for now, in which case it won't be necessary to worry about logical properties at all. Hopefully Vector's layout can be rotated without needing to know too much about the page's structure.

Slevinski (talkcontribs)

It would be great if we could move forward with vertical script support. This would benefit all sign languages written in the SignWriting script.

There are some circumstances where the SignWriting script is written horizontally, such as bilingual education, but these situations wouldn't apply to wikipedia or wiktionary.

Yair rand (talkcontribs)

Using language variants for dealing with languages that can be written in multiple directions sounds sensible to me.

Regarding scripts rotating: It appears that a horizontal equivalent of $.fn.slideUp doesn't actually exist. :-/ This and similar issues could make this difficult.

Cscott (talkcontribs)

Language variants aren't any part of the solution here. Switching language layout is a CSS change, not a "variant" (which usually involves rewriting the text on the page).

ASL is a strange use-case for this: as others have noted, even if we implement vertical writing support we will be far from an actual solution for ASL, due to other typography considerations. I would suggest containing the relevant CJK/Mongolian/Manchu communities and getting their input and support. Implementing what they need will be a "first step" towards the full support the ASL community needs, but will provide a more achievable short-term goal.

I'd also feel a lot more confident supporting this if implementation were further along. As it is, it is easy to say, "sure, we should do this" -- but that doesn't magically cause resources to appear or the work to be done by elves. If the question is: should we merge improvements to CSSJanus, then I don't think that needs an RfC, I think that can/should be done by the maintainers of CSSJanus, based on code quality issues not philosophical ones. The remaining (non-CSSJanus) work seems to be in adapting the default theme to allow vertical writing; I'd like to see some patches there (or at least thoughts about what needs to be patched).

Yair rand (talkcontribs)

I'm not sure what you mean by "adapting the default theme to allow vertical writing". Could you elaborate?

Reply to "Arch summit summary"