[css-writing-modes] white space collapsing/processing in text-combine horizontal

@fantasai

This was previously filed as a mail. 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:

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:

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:

The white-space property should prevent the trimming.

The Compression Rules should use the trimmed text.

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

[css-writing-modes] Clarify handling of white space at the start/end …

Fixed in 53a5349
Agenda+ for CSSWG review.

[css-writing-modes] test for w3c/csswg-drafts#4139

(cc myself in case something needs to be done in Gecko)

The CSS Working Group just discussed white space collapsing/processing in text-combine horizontal, and agreed to the following:

RESOLVED: Make this undefined in L3. Define interoperable behavior in L4 and add tests to L4 test suite
RESOLVED: publish updated CR of Writing Modes L3

The full IRC log of that discussion

<dael> TOpic: white space collapsing/processing in text-combine horizontal
<dael> github: https://github.com//issues/4139#issuecomment-513589921
<dael> fantasai: There was an issue on www-style on how we handle whitespace at the beginning of a [missed] string where we want all text combined. Spaces within text straightforward how it's for whitespace, but question on start and end
<fantasai> https://github.com/w3c/csswg-drafts/commit/53a5349823a794923be057e29038e021f523451f
<dael> fantasai: Makes sense handled same as if inline block. Collapsible whitespace is collapsed away. Changes to make this explicit. Currently say composition of text is as if inline block. Makes it explicit whitespace collapses in that manner.
<dael> astearns: Matches impl except Safari. THere's a safari engineer to make the change?
<dael> fantasai: I haven't tested all impl. Safari engineer said it's reasonable
<dael> Rossen_: For the TR portion or writing modes?
<dael> fantasai: For L3
<dael> Rossen_: Why make this behavior change that late?
<dbaron> s/[missed]/tate-chu-yoko (縦中横)/
<dael> florian: Clarification, not behavior change. Already said lay text out as if inlineblock. Points out that that means you have to handle whitespace at beginning and end in a specific way
<fantasai> Looks like Gecko would need changes to comply
<dael> Rossen_: Proposing add a note
<dael> fantasai: Proposing addnormative text
<dael> florian: It's clarification of existing text that says do layout as inline block. It's phrased as normative that you're supposed to layout as inline block which means do this thing and pointing to css text
<dael> Rossen_: What would be effect...reading to catch up on IRC. Listing to fantasai and she was saying we will have to enter CR for this?
<fantasai> testcase http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22writing-mode%3A%20vertical-rl%22%3EA%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3Etext%3C%2Fspan%3E%3Cspan%20style%3D%22text-combine-upright%3A%20all%22%3Etext%20%20%3C%2Fspan%3EB%3C%2Fp%3E
<dael> florian: Already have to go through CR due to other changes. Since there was some disagreement on what this meant we clarify
<dael> AmeliaBR: L3 and L4 are as CR we're republish CR anyways.
<dael> florian: As fantasai mentioned a safari engineer was wlling to change. afaict this does not match impl though it matches spec
<dael> astearns: Rossen_ was asking process. We'd like L3 as fast as possible. If we clarify we need to update test suite and make sure we have enough impl passing. From process might be easier to clarify in L4.
<dael> florian: L3 needs to republish anyway so no difference. In terms of passing maybe. Given disagreement leaving it undefined for now and clarify in L4 might make it easier for publications
<dael> fantasai: In at risk?
<dael> Rossen_: THought it was.
<dael> florian: All value is in L3. Automatic was at risk and removed. Behavior wasn't at risk.
<dael> astearns: And putting this in L3 at risk if we take it out means there'sanother publishing churn
<dael> florian: No, at risk you can remove without repub
<dael> astearns: True
<dael> florian: Need new CR due to other nromative changes
<dael> astearns: Why nec to put in L3 given L4 is the thing we're working on. Clarifications in later modules is appropriate
<dael> florian: Given L3 text is ambig if we want it in L4 we can explicit undefine in L3. Does that work for you fantasai ?
<dael> fantasai: Seems fine
<dael> astearns: Prop: Make this undefined in L3. Define interop behavior in L4 and add tests to L4 test suite
<dael> florian: I've written the tests
<dael> astearns: Excellent
<dael> astearns: Objections to Make this undefined in L3. Define interoperable behavior in L4 and add tests to L4 test suite
<dael> RESOLVED: Make this undefined in L3. Define interoperable behavior in L4 and add tests to L4 test suite
<dael> florian: Only open issues on writing modes are expected to be resolved editorially. Can we repub CR with other changes and this resolution?
<dael> florian: Editorial can happen without patent wait. We have normative edits so pushing those seems useful
<dael> astearns: sgtm
<dael> Rossen_: List of editorial changes?
<dael> florian: It's open issues
<AmeliaBR> Changes already integrated in ED: https://drafts.csswg.org/css-writing-modes/#changes-201805
<dael> Rossen_: [missed] having test suite complied against the PR which was the organized test suite. Have we changed version for retest?
<AmeliaBR> Open issues: https://github.com/w3c/csswg-drafts/labels/css-writing-modes-3
<dael> florian: Impl report I'm planning to update. Would like to update on basis of CR. We have open issues fantasai thinks will be editorial. Not proven. If are editorial we can roll them in.I'm trying to update impl report from koji but easier against CR
<AmeliaBR> Whoops, above link was level 4 changes, here is level 3: https://drafts.csswg.org/css-writing-modes-3/#changes-201805
<dael> astearns: And against most recent CR is what will satisfy review
<dael> florian: And if we need changes it's easier to change something scoped. A stake in the ground now would be helpful.
<dael> Rossen_: It is disappointing to see it's been so long since we were almost REC with so much work. We have another meeting in Japan and I'm sure folks there will be interested in progress. DOesn't sound like we're close to ready.
<dael> Rossen_: THis is quite disappointing to see we are where we are. We're trying to get more and more into this spec which means it'll take longer and longer and not focus on L4
<dael> florian: That's what I'm trying to do. Get to PR or know why we can't so that we publish what we have resolved on and update koji's report. Not sure we'll be at PR but updating the report is the first step to know if we can.
<fantasai> No, they're geared towards me :p
<dael> Rossen_: This is fantastic. Comments aren't toward you and I appriciate the effort you put. We as a group are tending to try and put more into L3 rather then get it out the door. Your efforts are appricated
<dael> astearns: Proposal is publish updated CR of Writing Modes L3
<dael> RESOLVED: publish updated CR of Writing Modes L3
<dael> astearns: Any other writing modes progress we can make?

[css-writing-modes-3] Undefine processing of spaces inside text-combi…

[css-writing-modes] tests for w3c/csswg-drafts#4139 (#17970)

Triage css-writing-modes test failures

Bug 1567853 [wpt PR 17970] - [css-writing-modes] test for w3c/csswg-d…

[css-writing-modes] tests for w3c/csswg-drafts#4139 (web-platform-tes…

Bug 1567853 [wpt PR 17970] - [css-writing-modes] test for w3c/csswg-d…

Navigation Menu

Repository navigation

[css-writing-modes] white space collapsing/processing in text-combine horizontal #4139

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-writing-modes] white space collapsing/processing in text-combine horizontal #4139

Description

Activity

fantasai commented on Jul 21, 2019

upsuper commented on Jul 24, 2019

css-meeting-bot commented on Jul 24, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions