Open r12a opened 7 years ago
[scheduled for initial discussion 2017-03-23]
So i spoke with @fantasai about this during the i18n call, and here is a summary. The writing-modes values of sideways-lr and sideways-rl have been deferred to CSS Writing Modes Level 4 purely in order to speed up the progress of Writing Modes level3 to PR, which is hopefully imminent. There are no plans to drop the sideways- values of writing-modes, quite the contrary, CSS is just waiting on a second implementation to be completed, but want to publish the rest of the spec as a Rec sooner than that will happen. The plan is to publish Level 4, containing just those values, and move to CR almost immediately, where it will await the completion of the second implementation.
So i don't think TTML needs to worry about following a similar path in terms of adding sideways- writingMode values.
The Working Group just discussed Incorporate CSS advances into TTML vertical text handling ttml2#277
, and agreed to the following resolutions:
RESOLUTION: We are willing to evaluate the use case for the new writing-mode values but will defer this to a future version of TTML.
@r12a Bringing the above resolution to your attention.
[i passed this by Fantasai for a sense check before posting, and she said LGTM]
Cyril: Writing Mode in CSS has additional values we don't have. Glenn: But we do have all of them. We just have different keywords. Nigel: Do we have sideways-left and sideways-right that weren't in XSL-FO? Glenn: Yes, you use writingMode and textOrientation together.
I believe that conclusion is incorrect. The sideways-x values of writing modes in CSS effectively rotate the lines of horizontal text rather than rotating characters. This has significant benefits for managing side-on horizontal text (such as preserving start and end where you'd expect, and automatically wrapping text after line breaks in the right direction). It's essentially just a 90º transform of the text box.
CSS works on the basic premise that in the normal use case text-orientation
is only needed for vertical-rl/lr
values of writing-modes, and that those are tightly bound with Japanese, Chinese, Korean and Mongolian usage. This is where it is normal to find some characters that would normally be side-on switched to upright (eg. in acronyms such as FIFA).
My understanding is that the chance of ideographic or kana or hangul text needing to be rotated in vertically set text is extremely unlikely. The sideways
value of text-orientation
is, iiuc, a relic – (which explains why there's no -90º rotation) that is not expected to see much use. The sideways-rl/lr
values of writing-modes
should do that job.
As i understand it, therefore, In CSS and in the overwhelming majority of use cases, the text-orientation
property is really only there to address the need to stand certain letters upright in vertical lines of CJKM content (or other scripts with a natural vertical text orientation).
I therefore recommend that TTML drops or marks as at-risk the sidewaysLeft
and sidewaysRight
values of tts:textOrientation
, and possibly sideways
also, in favour of increased compatibility with CSS in the next version through introduction of the sideways-rl/lr
values for the writing-modes
property.
Thank you @r12a I've added this to the agenda for tomorrow's call. It may be possible to modify our resolution so that we adopt your recommendation, which I see still defers introduction of sideways-rl/lr
into tts:writingMode
, in other words, it is a low cost option to mark features as at risk in CR and I think that's all you're proposing for now.
Btw, the at-risk notes about the sideways-rl/lr values of writing-mode in the editor's draft of CSS writing-modes level 4 are now gone.
@r12a Thank you, that's good to know.
Given that tts:textOrientation
sidewaysLeft
and sidewaysRight
are already marked at risk (see https://github.com/w3c/ttml2/pull/637), the only point to discuss is whether we want to mark sideways
at risk too, but it is only a suggestion by @r12a . The inclusion of new values in tts:writingMode
can only be envisaged in a next version of TTML.
The current status is that we have no feature designator exclusively for the sideways
value and have not marked it as at risk. Unless there is any new call to do so, I propose that we close this issue with no further change.
The Working Group just discussed Incorporate CSS advances into TTML vertical text handling ttml2#277
, and agreed to the following:
RESOLUTION: Close without marking sideways as at risk
10.2.52 tts:writingMode http://w3c.github.io/ttml2/spec/ttml2.html#style-attribute-writingMode
10.2.46 tts:textOrientation http://w3c.github.io/ttml2/spec/ttml2.html#style-attribute-textOrientation
I think it would be useful to make the text in this section more closely resemble the approach in CSS, recent developments for which, i believe, have fixed some issues related to vertical text handling which apply to the model described for TTML.
CSS has the following values for vertical writing modes: vertical-rl (equivalent to tbrl) vertical-lr (equivant to tblr) sideways-rl sideways-lr
The latter two values are intended for use with 'horizontal scripts' when one wants to set them vertically (usually alongside something). They are useful additions because they effectively rotate the progression of lines in one direction or the other, which is what you typically need for such use cases. This affects where the start and end points lie, and how text will wrap to the next line, as well as the default orientation of the characters. For example, for sideways-lr, start is at the bottom of the vertical line, Latin characters would lie on their left side, and lines would wrap when they reach the top of the vertical line. These are things that don't happen with vertical-lr.
I believe there are some technical advantages to this approach, but also it will help authors if the models for TTML and CSS are similar.
Perhaps there will be some resistance because vertical text values such as sidewaysLeft and sidewaysRight existed previously in TTML, i'm not sure. If so, and therefore things can't be removed, then i suggest that sideways-rl and sideway-lr values be added, and the user be advised to use those rather than the sidewaysLeft and sidewaysRight values of tts:textOrientation.
(The TTML model also doesn't adopt all of the values used in XSL, and so the -rl and -lr parts of tb-rl and tb-lr don't have equivalents in the vertical text values. In CSS the inline direction of the block is not indicated by an explicit -rl/-lr on the container. That is set by the direction property. I'm guessing that you don't want to go there.)