[csswg-drafts] [css-writing-modes] white space collapsing in text-combine horizontal (#4139)

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-writing-modes] white space collapsing in text-combine horizontal ==
This was previously filed as [a mail](https://lists.w3.org/Archives/Public/www-style/2018Aug/0011.html). Reproducing its content here:

> Hi,
> 
> I checked the following on Safari/Chrome/Firefox for macOS.
> http://jsbin.com/nocidux/edit?html,output
> ```
> <style>
>   #tcy {
>     border: solid 1px red;
>     text-combine-upright: all;
>     -webkit-text-combine: horizontal;
>   }
> </style>
> <div style="writing-mode: vertical-rl">
>   <span id="tcy"> </span>
> </div>
> 
> ```
> Safari shows the combined white space at the end of the line, but Chrome
> and Firefox don't show it.
> 
> Should the combined white space at the end of a line be removed?
> 
> It looks like Chrome and Firefox remove the combined white space to follow
> CSS 3 Text.
> https://drafts.csswg.org/css-text-3/#white-space-phase-2
> > A sequence of collapsible spaces at the end of a line (ignoring any
> intervening inline box boundaries) is removed.
> 
> However, Safari doesn't remove the combined white space because it should
> be considered as the Object Replacement Character
> https://www.w3.org/TR/css-writing-modes-3/#text-combine-layout
> > For other text layout purposes, ... the resulting composition is treated
> as a single glyph representing the Object Replacement Character U+FFFC.
> 
> I guess that Chrome and Firefox consider White Space Processing as line
> breaking and follow:
> > For line breaking before and after the composition, it is treated as a
> regular inline with its actual contents.
> 
> I'm not sure if the removing is line breaking because the removing is done
> after line breaking.
> 
> Which is correct?
> 
> Best regards
> Yuki Sekiguchi

@fantasai [replied](https://lists.w3.org/Archives/Public/www-style/2018Aug/0012.html):

> Wow, I don't know. From the specs you quote, it seems like Safari
> is correct, but I'm not sure it makes sense.
> 
> It seems to me we did not consider what happens if there is white
> space at the start/end of tate-chu-yoko in general, e.g.
>    text `<span id="tcy">tcy </span>` text
> Maybe such white space should always be trimmed? Probably the best
> thing is to combine TCY before white space collapsing, and then
> additionally trim the white space at the start/end of the TCY.
> 
> What do you think should happen?

Yuki Sekiguchi [then replied](https://lists.w3.org/Archives/Public/www-style/2018Aug/0019.html):

> 
> Thank you for answering.
> 
> I asked some people who know Japanese typography very well
> including Toshi Kobayashi.
> 
> Our conclusion is that white spaces at the start/end of tate-chu-yoko
> should always be trimmed. Therefore, your suggestion looks great.
> 
> I'd like to clarify:
> 1. The white-space property should prevent the trimming.
> 2. The Compression Rules should use the trimmed text.
> 3. The line breaking should use the actual contents of a text combine
> instead of the trimmed text.
> 
> If we can change (3) to use the trimmed text, it becomes easier to
> implement, but, I think it is needed to be compatible with the current spec
> and current implementations.
> 
> I could implement the above except white-space support for WebKit. I think
> it shouldn't be a problem from the perspective of implementation.
> 
> Best regards
> Yuki Sekiguchi


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4139 using your GitHub account

Received on Sunday, 21 July 2019 21:22:19 UTC