Re: [css-writing-modes] Propose writing-mode: sideways-left

On 20/8/15 09:12, John Daggett wrote:
>
> Florian wrote:
>
>  > > So, when the minutes[1] says:
>  > >
>  > > > Okay. We don't have Koji so I suggest we resolve on the
>  > > >          mailing list.
>  > > >
>  > > > - Everyone on the call was in support of the proposal to create
>  > > >      sideways-lr and sideways-rl in writing-mode, but all the
>  > > >      interested parties weren't on the call, so a decision will
>  > > >      occur on the mailing list.
>  > >
>  > > I'm good, and no objections doesn't seem to be seen on this ML so far.
>  > >
>  > > Can we say this is resolved now?
>  > >
>  > > [1] https://lists.w3.org/Archives/Public/www-style/2015Aug/0051.html
>  >
>  > I mentioned during the call that you were in favor, but it is John
>  > Daggett's opinion we're waiting for.
>
> No, I still don't think this is a good idea. It's exchanging complexity
> of implementation for authoring model complexity and that's almost
> always a poor choice in my opinion.

I don't agree that the proposal being considered here would increase 
authoring model complexity. If anything, I'd say it offers authors a 
cleaner and more understandable model. We'd have three modes 
(horizontal-tb, sideways-lr and sideways-rl) that all lay out text in 
the same way, but with a ±90° rotation in the sideways-* cases. In all 
three cases, the text is laid out according to the conventions of 
horizontal writing, even if it is then rotated in its entirety. No 
question of glyph orientation within the line ever arises in these modes.

And then there are the two vertical-* modes, which lay out text 
according to vertical writing-system rules. And for these, the 
text-orientation property may be used to override the glyph orientation 
when the default behavior is not suitable.

The one thought that occurs to me is that perhaps sideways-lr and 
sideways-rl would be clearer if they were renamed to rotated-left and 
rotated-right, or something like that.

>
> Anyone involved in publishing here in Japan that I mention this to seems
> baffled by this proposal to add sideways-lr and sideways-rl to the
> writing-mode property. And I think implementors of EPUB viewers here are
> frustrated at changes like this and the impact it will have on this spec
> going to REC quickly.
>
> To summarize the proposal from Elika as I understand it:
>
> Current definition [1]:
>
>    writing-mode: horizontal-tb | vertical-rl | vertical-lr
>    text-orientation: mixed | upright | sideways-right | sideways-left |
> sideways
>
> Authors use the writing-mode property to enable vertical text display
> and the text-orientation property to override the orientation of text
> within a line, when needed.
>
> Proposed change [2]:
>
>    writing-mode: horizontal-tb | vertical-rl | vertical-lr | sideways-lr
> | sideways-rl
>    text-orientation: mixed | upright | sideways
>
> CJK authors use vertical-rl while authors wanting vertical headings in
> tables use either sideways-rl or sideways-lr. CJK authors use
> text-orientation to override the orientation of text within a line but
> text-orientation has no effect on authors using sideways-rl or
> sideways-lr.

Yes, though perhaps it's fairer to say that (for both the current and 
proposed models), text-orientation is only relevant to vertical-* 
writing modes. In horizontal writing modes (whether physically 
horizontal or rotated left/right) it has no effect.

>
> It seems to me this proposal is being driven by some complexities that
> don't really exist in content, for example when the orientation of text
> changes within a line:
>
>    p { writing-mode: vertical-rl }
>    span.left { text-orientation: sideways-left }
>
>    <p>This is a <span class=left>strange ball of beeswax</span></p>
>
> But how this sort of complexity is solved isn't really important. It
> won't occur frequently in content so we can use implementation
> experience to come up with better proposals in later levels of the spec.
> Cluttering up the writing-mode property seems like a mistake to me and

I don't see the sideways-* (or rotated-*) values as "cluttering up the 
writing-mode property"; ISTM they're very reasonable ways to express the 
ways people want to be able to render text.

I'd guess that for CJK authors, the use of text-orientation:sideways 
will be virtually non-existent, as that simply isn't how these languages 
are written vertically. they have a well-established tradition of 
vertical-upright writing. This is entirely distinct from horizontal 
writing that is rotated by 90°; so why overload the 
writing-mode:vertical-* values to support both use cases, requiring the 
addition of the (messy, asymmetrical) text-orientation property for the 
rotated-horizontal-text case? The proposed change, IMO, offers authors a 
simpler model.

 > making this change will affect implementations that already implement
 > the writing-mode/text-orientation properties as defined up until this
 > proposal.

Has anyone implemented text-orientation:sideways-left yet? Aside from 
that, the impact of the proposed change on existing implementations 
should be minimal, AFAICS.

Regards,

JK

>
> The discussion within the group has been relatively limited and I think
> we haven't heard enough from implementers that depend on these features.
> Apple? Microsoft? EPUB viewer vendors in Japan? Amazon? Getting that
> feedback is important I think.
>
> Regards,
>
> John Daggett
> Mozilla Japan
>
> [1] CSS3 Writing Modes ED
> https://drafts.csswg.org/css-writing-modes-3
>
> [2] Elika's proposed change
> https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html
>
> ​

Received on Thursday, 20 August 2015 14:23:40 UTC