Talk:Requests for comment/Vertical writing support

Previous page history was archived for backup purposes at Talk:Requests for comment/Vertical writing support/LQT Archive 1 on 2015-07-10.

Vertical writing mode is realized on Chinese Wikisource. It would be better if the whole interface becomes vertical.

What's the current state of browser support for vertical writing? Are all major browsers supporting, or do we have to do a subset?

Last I looked into this a few years ago, only IE supported vertical text and it didn't quite match the CSS3 spec. If other mainstream browsers support the new standard though, some fun could be had. :)

Google Chrome, Safari, Opera 15, and IE all support vertical text. Firefox does not (bug 145503).

Firefox supports vertical text. Though with some bugs https://bugzilla.mozilla.org/show_bug.cgi?id=1263810 .

Feel free to add to this list. Apologies for mixing module names with script names.

Generally visible scripts that result in broken behaviour: (These are the only ones I'd consider to be a necessity for deployment.)

• mediawiki.toc.js

  Two jQuery functions used in this script are shortcuts to a set animation properties. When vertical, $.slideDown and $.slideUp can be replaced with

  $tocList.animate({width: "show", paddingLeft: "show", marginLeft: "show", paddingRight: "show", marginRight: "show"}, "fast" );

  $tocList.animate({width: "hide", paddingLeft: "hide", marginLeft: "hide", paddingRight: "hide", marginRight: "hide"}, "fast" );

  respectively. The padding can be omitted if dealing with unusual CSS situations is unnecessary.

• jquery.mw-jump.js

  Causes very large gap of whitespace right now.

  .css( { height: 0 } ); and .css( { height: 'auto' } ); need to use width for vertical:

  .css( !vertical ? 'height' : 'width', 0 ); and .css( !vertical ? 'height' : 'width', 'auto' );

• (Only on Special:Preferences) mediawiki.special.preferences.js has the same code applied to .mw-navigation-hint. Same fix necessary.
• jquery.suggestions.js

  The variable newCSS needs some changes, similar to those applied in rtl situations.

• mediawiki.notification.js (minor)

  Most of this works well, but stacked notifications don't animate smoothly, and it doesn't react to scrolling like normal.

  offset = $area.offset(); becomes (in both vertical-lr and vertical-rl):

  offset = { left: $area[ 0 ].getBoundingClientRect().left - document.body.getBoundingClientRect().left };

  This is because scrollLeft and scrollTop are both broken in IE in vertical modes, and offset() relies on them.

  var isFloating = $window.scrollTop() > offset.top; becomes:

  For vertical-lr: $window.scrollLeft() > offset.left;

  scrollLeft won't work.

  For vertical-lr: isFloating = -document.body.getBoundingClientRect().left > offset.left;

  For vertical-rl: $( window ).width() < offset.left + document.body.getBoundingClientRect().left;

  IE gives incorrect values for clientHeight and clientWidth, which are used by $( window ).width(), when in vertical writing mode.

  For vertical-rl: $( document ).width() < offset.left + document.body.getBoundingClientRect().left;

  For vertical-rl: $( document.documentElement ).width() < offset.left + document.body.getBoundingClientRect().left;

  Newer IEs can handle this, but IE8 swaps height and width when handed $( document.documentElement ).width(). Window, body, document, and documentElement, offsetWidth and getComputedStyle, and pretty much everything else also breaks somehow or other.

  For vertical-rl: document.body.getBoundingClientRect().width < offset.left + document.body.getBoundingClientRect().left;

  Unsupported by IE8<...

  For vertical-rl: viewportRect = document.body.getBoundingClientRect(); var isFloating = viewportRect.right - viewportRect.left < offset.left + viewportRect.left;

  This actually tracks the original left side instead of the right. offset objects don't normally have right properties, though.

• Vector/collapsibleTabs.js
• Vector/vector.js
  • Contain numerous direct width and left references that need to be rotated. Also makes use of $.fn.offset() in calculateTabDistance, which can be safely switched to .top in vertical without issues.

Situation-dependent: (Not that much of an issue if these don't work.)

• mediawiki.action.edit.preview.js (really minor)
• mediawiki.page.gallery.js (minor)
• jquery.makeCollapsible.js
• jquery.ui/jquery.ui.button.js could use some minor fixes with the corners.
• Not sure about jquery.ui.resizable.js and jquery.ui.draggable.js.
• jquery.ui.listrotator (unused?)
• Spinner
• jquery.loadingSpinner (maybe)

Extensions used by Wikimedia:

• ULS: (Pretty sure this isn't so relevant.)
  • UniversalLanguageSelector/resources/js/ext.uls.webfonts.js
  • UniversalLanguageSelector/resources/js/ext.uls.interface.js
  • ext.uls.languagesettings
  • ext.uls.compactlinks (I think this is beta only, actually)
  • jquery.uls (This also needs design help for dealing with the map image.)
• Echo: (In terms of visible problems, there's some slight mispositioning of the box, I think. Mostly okay otherwise.)
  • Echo/modules/overlay/ext.echo.overlay.js
  • Echo/modules/overlay/ext.echo.special.js
• Some MultimediaViewer stuff.
  • Possibly MultimediaViewer/resources/jquery.scrollTo/jquery.scrollTo.js, but I think not.
  • Various MMV scripts that I haven't written a list of yet.
• WikiEditor: (minor)
  • jquery.wikiEditor.js (maybe)
  • jquery.wikiEditor.dialogs.config.js
  • jquery.wikiEditor.dialogs.js
  • jquery.wikiEditor.toolbar.js
• Quite possibly many of the TimedText modules and their dependencies. I haven't checked.
• VisualEditor doesn't have as many complications as one might expect, it seems.
  • The top bar doesn't follow the scroll.
  • The arrow keys should probably be switched.
  • Some issues with navigation.
• Beta:Popups could use some fixes.
• I haven't checked:
  • ext.guidedTours
  • mobile
  • Mantle
  • math
  • pageTriage
  • wikibase (I didn't even know this was on the regular wikis...)
• Flow needs some fixes.

Page-specific scripts:

• Possibly mediawiki.special.upload.js, not very relevant to our cases anyway, though

(In progress/Incomplete.)

Sign Languages:

["cse","fse","bqn","dse","ise","mre","esn","csn","mdl","hab","hps","pso","aed","hds","hks","hsl","hos", "psl","gsm","icl","okl","lst","csc","cds","csq","csf","bfk","prl","sfs","jhs","yds","fsl","jsl","csl", "esl","vsl","ysl","zsl","mfs","psc","kvk","svk","mzc","lbs","jus","gus","gse","tsq","nzs","bzs","sgg", "sqk","vsv","tza","zib","lso","uks","jos","ins","xms","rms","jls","tss","lsl","gss","fss","kgi","sqs", "lsp","xki","lls","bfi","prz","sgx","ugy","psr","msr","nsr","ssr","isr","csr","sls","rsl","sfb","swl", "vgt","sdl","syy","pys","inl","vsi","fcs","ecs","ncs","gds","rsi","nsi","bqy","nbs","isg","csd","msd", "psd","tsy","lsy","bvl","tsm","doq","mzy","tse","asq","dsl","pks","ukl","ugn","asp","hsh","psp","nsp", "ssp","eth","bog","lsg","psg","csg","gsg","slf","xml","haf","asw","mzg","ads","ase","afg","eso","nsl", "aen","jcs"]

Other vertical-lr:

• Mongolian: The Incubator project is using the ISO code mvf ("Peripheral Mongolian", opposed to Halh Mongolian) for Inner Mongolian/Mongolian in Mongolian script, which seems to be a reasonably accurate designation.
• Xibe,: sjo
• Manchu: mnc

Vertical-rl: (All as alternate directions.) Various Chinese languages (ISO codes:cdo, cjy, cmn, cpx, czh, czo, gan, hak, hsn, mnp, nan, wuu, yue, och, ltc, lzh..., Wikipedia codes: zh, zh-min-nan, zh-yue, zh-classical), Japanese ja, Korean ko.

By script:

• Vertical-lr: Sgnw, Mong
• Vertical-rl: (All as alternates) Hans, Hant, Jpan, Hani, Hira, Hang, Kana, Kore, Yiii

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.

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.

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.

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.

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

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.

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.

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.

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.

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).

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

We'll discuss this RfC next week.

It looks like Pau Giner, the designer who works on language engineering, will not be able to attend this meeting. Brandon Harris (User:Jorm (WMF)) said: 'I'm not going to attend the meeting, but I can give you design's opinion: "Yes, we should improve this support."'

Action items:

• group working on ASL needs someone to help with the CSSJanus improvements
• brion to look into the cssjanus provisionally
• YairRand to propose at wikitech-l next steps for this RfC after Wikimania
• brion to report on cssjanus progress to wikitech-l somewhere in the next few weeks

Hi Yair Rand. Have you had a chance to take a look at the issues that TheDJ noted down, as people discussed during the architecture summit in January? If so, maybe we could talk about this RFC in this week's meeting.

Unfortunately, I missed this meeting. :(

Hopefully the RFC can be discussed at a later time.

Yair rand, how about sometime in late May or early June? Are there dates that would work for you?

Ping! :)

So sorry for taking so long to reply (again). (I'm hoping that the disappearance of the "New messages" box from the interface for a length of time counts as a reasonable excuse...)

Most dates that aren't Fridays or Saturdays work for me. Is there a set calendar of when IRC meetings take place? Architecture meetings doesn't list any upcoming dates. (Or are these just set up whenever there's a particular issue that needs discussing?)

It would probably be quite helpful to have User:Slevinski, who's been working on tech issues of SignWriting (which is probably the most relevant script for the vertical writing issue) for years, at the meeting. (That mention sends out a notification, right?)

Emailed this to both of you but also saying it here:

Hi, Slevinski and Yair rand! I'm following up on https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Vertical_writing_support/Could_discuss_during_RFC_meeting_this_week/reply_(4) .

Have you had a chance to take a look at the issues that TheDJ noted down, as people discussed during the architecture summit in January? https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Vertical_writing_support/Arch_summit_summary has that. It would be great if you could respond to it.

Once you've done that, please say so on wikitech-l and I'll be happy to put this RfC into one of the weekly discussion slots! It would probably be on a Wednesday somewhere between 1600 and 2300 UTC; in the note to wikitech-l, please mention your timezones.

• text-orientation also important in some languages
• CSS only I think, we currently use dir attribute need a new way to apply this ?
• is the orientation info in CLDR ?
• ASL most important ?

http://www.omniglot.com/writing/direction.htm#ltrv

...I didn't understand most of that comment.

Text-orientation is simple to deal with, since it just requires a simple CSS statement without reorienting anything.

ASL is probably not the most important language using vertical writing direction, but it is the only one that we have a running incubator project and localization effort for. It seems that Chinese Sign Language, Indo-Pakistani Sign Language, and Brazilian Sign Language all have more native speakers, with several million each.

Yeah, sorry, i had to do some quick note taking just before i left the hotel :D

@Yair rand, you are not at the summit right ?

Correct, I am not at the summit.

Is it worth supporting multiple direction variants? For instance, switching a CJK wiki's display between horizontal-LTR and vertical-top-to-bottom-RTL?

Life gets much simpler if we don't allow switching, and only use vertical for languages that require it.

I could see it being useful to have the option available for those who might be slightly more comfortable reading vertically, but I think that right-to-left vertical script could be a much lower priority than getting left-to-right vertical text working.

(According to Omniglot, "In Taiwan [Chinese] is often written vertically, while in China and Singapore it is usually written horizontally.", so it might make sense to have the Taiwanese variant on the Mandarin Chinese Wikipedia default to vertical if that's possible at some point.)

I think Taiwanese are comfortable with reading horizontally online. But some book and all of ancient Chinese books are written horizontally. A vertical mode should be good for all Chinese use case.