robchur wrote:

Implementation will need to wait until there is support in more than one
browser; let's see what the situation is in a few months' time.

Might be cute to see a demo, though.

Component: UI -> i18n. Reopened.

Reopened too optimistic. Still no wide standard implementation.

Some progress is being made on this:

http://dev.w3.org/csswg/css3-writing-modes/

And webkit and firefox have prefix support for it, but i checked for mongolian on webkit, and it seems the glyphs are rotated, so it's still in very early stages it seems.

Are there any examples files or test cases for testing browser support for this?

Created attachment 8719
Example HTML for mongol script and writing-mode

Attached:

Created attachment 8720
Example image of the Mongol text in the Example HTML

Attached:

Created attachment 8721
Super-simple vertical text example (Japanese text)

Here's an HTML file with a few paragraphs of Japanese text and the body set to top-to-bottom & right-to-left (as is suitable for Japanese, Chinese, etc)

At least the basic vertical layout seems to work in IE 8+ (using a non-standard variant of the writing-mode value) and Chrome 12 (didn't test earlier versions; using -webkit-writing-mode). Firefox doesn't currently seem to recognize it; there's a bugzilla entry and somebody seems to have been working on patches a couple years ago but I don't think it's being actively worked on.

Actually maintaining the skins, editing etc in a vertical world could be.... interesting. :)

Being able to make use of the vertical layout for formatting of individual chunks of text -- such as in a Wikisource -- might actually be easier and more likely to be handlable than doing the whole UI.

IE info: http://blogs.msdn.com/b/ie/archive/2009/05/29/the-css-corner-writing-mode.aspx

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=145503

Attached:

(In reply to comment #7)

Created attachment 8719 [details]
Example HTML for mongol script and writing-mode

Loading that up in Chrome 12 on Ubuntu 11.04 with language-support-fonts-mn extra fonts packages installed -- for me it rotates the glyphs correctly for vertical view, but neither horizontal nor vertical text seems to have shaping/ligatures applied so I'm pretty sure the result is illegible both ways. :P :)

Attached:

Created attachment 8722
Screenshot of Webkit NB (6533.21.1, r88432) Mac OS X 10.6.8

Attached:

Created attachment 8723
Screenshot of Mongolian test page in Chrome 12/Ubuntu 11.04

-webkit-writing-mode chunk is correctly rotated, but none of the variants are being properly shaped/ligatured here. (Bug could be in the font itself, the font libraries on my system, or WebKit.)

Attached:

Created attachment 8724
Japanese rendering inconsistency in Chrome Mac & Linux

Even for the Japanese example there are rendering inconsistencies; in Chrome 12 on Mac OS X 10.6, ideographic punctuation shows correctly in vertical forms (eg parentheses open on the top/bottom instead of left/right, comma & period are aligned on the top-right instead of on the bottom-left) whereas in Chrome 12 on Ubuntu 11.04, these all remain in their horizontal-layout forms.

On the other hand, katakana long vowel marks do correctly show vertically elsewhere in the text, indicating that something is recognizing verticalness variants... So this again could be a difference in the font or the libraries (the fonts that Ubuntu ships might just not be specifying all the variants they should, or the font rendering libraries might be failing to apply the checks correctly to those characters).

Attached:

EN.WP.ST47 wrote:

*** Bug 7450 has been marked as a duplicate of this bug. ***

Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116

(In reply to comment #4)

Reopened too optimistic. Still no wide standard implementation.

Can we consider browser support "upstream"?

Currently, about three quarters of Wikimedia visitors use browsers that support vertical text.

I don't understand why it's necessary to wait for more widespread support when the alternative to using it is just to have nothing there. For Mongolian, the variants link to Mongolian script could be hidden with JS for non-supporting browsers. For languages that are exclusively written in vertical script, surely it would be better to have it work for some browsers than to not have it at all?

As I understand it, the ResourceLoader already does for rtl languages something similar to what would be necessary for vertical scripts. However, instead of just flipping left and right, for vertical-lr languages right would be flipped with bottom, top with left, and height with width.

ResourceLoader uses CSSJanus, which accomplishes rtl by performing text substitution on CSS properties like margin-left, text-align, and the like. Vertical text is a bit more complex, because some elements need to be "spun" while others spun and flipped and still others left alone.

JavaScript may not be necessary if we wrap all the vertical-specific rules in @supports, for the browsers that understand it. CSSJanus would need rudimentary knowledge of CSS syntax to be able to put duplicate rulesets in @supports blocks.

Also, Chrome 29 doesn't support vertical form elements, which kind of breaks Vector's layout.

(In reply to comment #17)

ResourceLoader uses CSSJanus, which accomplishes rtl by performing text
substitution on CSS properties like margin-left, text-align, and the
like.
Vertical text is a bit more complex, because some elements need to be "spun"
while others spun and flipped and still others left alone.

(Googles a bit...) Apparently there exists an extended version of CSSJanus called CSS::Yamaantaka, which works for vertical text. Dunno if it's usable.

(In reply to comment #17)

Also, Chrome 29 doesn't support vertical form elements, which kind of breaks
Vector's layout.

The SignWriting wikis need those elements replaced by a Javascript solution anyways, for other reasons, so that's not an issue for them. Still a problem for other vertical languages.

https://www.mediawiki.org/wiki/Requests_for_comment/Vertical_writing_support

If the hold-up is lack of Mozilla support, according to https://bugzilla.mozilla.org/show_bug.cgi?id=145503#c89 , in December 2012
"This bug is a meta bug. You can try vertical layout when using Nightly with layout.css.vertical-text.enabled=true."

@jayvdb, the [[ https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode | writing-mode ]] preference works in Firefox 36 and above. It’s now enabled by default in Firefox 41 (currently in the developer channel).

In T11436#1531264, @mxn wrote:

@jayvdb, the [[ https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode | writing-mode ]] preference works in Firefox 36 and above. It’s now enabled by default in Firefox 41 (currently in the developer channel).

Nice. Is this no longer Upstream then?

Quoting the description...

Don't wait another 5 or 10 years.

Eight-and-a-half years later... :(

Did @brion "report on cssjanus progress to wikitech-l somewhere in the next few weeks" as outlined in the RFC meeting notes from July 2014?

This one's been on the back burner... note that the just-released Firefox 41 has enabled vertical layout support, making this investigation less theoretical and more applicable now.

CSS3 Vertical writing mode is now supported by 90%+ browsers around the world and supported by basically all non-opera-mini browser as per http://caniuse.com/#feat=css-writing-mode , also note that due to the limited support provided by mediawiki on vertical script, there're already some ppl created their own non-wikimedia mediawiki site by using their own hack/method.

@siebrand i see. btw i think the upstream tag can ne removed now?

Is T353 a subtask or a duplicate of this task?

I think we should pay attention to some works on this wiki, which implemented vertical writing modes on their pages:

https://incubator.wikimedia.org/wiki/Wp/ase

What about editing interface, i.e. both WikiEditor and VisualEditor? (Not sure where's the sandbox of Wp/ase.)

In T11436#2605100, @Liuxinyu970226 wrote:

What about editing interface

It looks like the gadget they've written would work better as a proper IME so that it'd work more properly. VE as a browser-based editor works pretty well already, but the gadget doesn't work with it it seems, sadly. :-(

In T11436#2597750, @Great_Brightstar wrote:

I think we should pay attention to some works on this wiki, which implemented vertical writing modes on their pages:

https://incubator.wikimedia.org/wiki/Wp/ase

Wp/ase's most visible CSS was just rotated manually, as a temporary measure until CSSJanus is working for vertical writing modes.

In T11436#2605493, @Jdforrester-WMF wrote:

It looks like the gadget they've written would work better as a proper IME so that it'd work more properly. VE as a browser-based editor works pretty well already, but the gadget doesn't work with it it seems, sadly. :-(

Sign languages need a completely custom text editing system, not just a normal IME. I do plan to attempt to make it work with VE anyway, if possible, but since every bit of text on the page needs to be replaced with a bunch of DOM, and every keystroke needs to go first through the sign editing system, I don't know how well that will work. (Insufficient documentation makes investigating this a bit difficult.)

adding the tag because there're intention to make lzh wikipedia text run vertically

In T11436#2894280, @C933103 wrote:

adding the tag because there're intention to make lzh wikipedia text run vertically

Really? If I read that tag correctly, it only monitors the zh.* projects

PS: I think this task should be a Tracking-Neverending instead of Epic (or probably we should create Vertical-Writing tag instead), as we'll have more and more extension/skin/JS/CSS/Lua...-related issues on such topic. Anyone who against me here?

This is not a feature request; this is an outright bug. It’s 2023 already and all mainstream browsers have implemented writing-mode: tb, but when we try to use it we’re greeted with “Invalid or unsupported value for property writing-mode” and our CSS doesn’t even save. This is not an acceptable state of things.

@Al12si Please feel welcome to contribute patches which fix problems, provide clear steps to reproduce, links, and explain who we is. Thanks a lot!

In T11436#8616765, @Aklapper wrote:

@Al12si Please feel welcome to contribute patches which fix problems, provide clear steps to reproduce, links, and explain who we is. Thanks a lot!

“We” refers to anyone who tries to use writing-mode: tb. A minimal test case would be:

.test-vert-rtl {
writing-mode: tb;
}

Error message is as reported above.

I think that's kind of covered by T322482: TemplateStyles does not allow logical CSS properties. There are a few other bugs filed about the lack of support in TemplateStyles for some other relatively recent CSS features.

In T11436#8616757, @Al12si wrote:

This is not a feature request; this is an outright bug. It’s 2023 already and all mainstream browsers have implemented writing-mode: tb, but when we try to use it we’re greeted with “Invalid or unsupported value for property writing-mode” and our CSS doesn’t even save. This is not an acceptable state of things.

That's because writing-mode: tb isn't the right thing to use in CSS, see https://www.w3.org/TR/css-writing-modes-3/#svg-writing-mode

If you use writing-mode: vertical-lr (for Mongolian) or writing-mode: vertical-rl (for CJK), it will let you save it.