[css-text-3] Ogham Space Mark needs to disappear at the end of a line

[fantasai]

http://unicode.org/reports/tr14/#BA

[fantasai]

Checked in this rule in f047b93

Agenda+ to verify with CSSWG.

[frivoal]

I agree with the general idea of this change, but it seems to me that while trailing OGHAM SPACE MARK with white-space: normal | nowrap | pre-line should get removed, I don't quite see why we'd drop those with white-space:pre.

As for pre-wrap and break-spaces, I am less sure. Probably do as we do with other kinds of spaces: keep it for break-spaces, and keep it + hang it for pre-wrap, but I am not 100% sure.

[fantasai]

@frivoal Oversight in the wording, you're right that only collapsible marks should be removed.

[fantasai]

@frivoal Feel free to adjust the wording if you've got a better suggestion. :)

[frivoal]

Oversight in the wording, you're right that only collapsible marks should be removed.

After the edit, it now looks correct.

As for pre-wrap and break-spaces, I am less sure.

Never mind, this is already covered, since the Ogham Space Mark is part of unicode category Zs, and thus of "other spaces separators", so that's handled already.

TL;DR: we're good.

[fantasai]

Chatted with @kojiishi , there's basically several ways we can handle this in the details. Note that from a practical perspective, it really does not matter which one we choose, since mixing OSM and spaces isn't a real use case, so we should do the most efficient thing for implementations.

• Include Ogham Space Mark among the white space characters trimmed at the end of a line (phase 2), but don't do anything with them when collapsing within the line (phase 1).
• Trim Ogham Space Mark as a separate step after trimming white space characters at the end of a line.
• Add Ogham Space Mark to the list of white space characters and collapse them just like spaces everywhere. (This is probably overkill, it makes the CSS document white space set different from CSS and HTML syntactic white space, and it likely has bad perf implications.)

The difference between 1 & 2 is what happens in the (very unnatural) sequence [Letter][Space][OSM][Space]. 1 would trim everything after the Letter. 2 would leave the inner space intact.

[fantasai]

@kojiishi Also suggests marking this behavior at-risk for L3; I agree with that.

[css-meeting-bot]

The CSS Working Group just discussed [css-text-3] Ogham Space Mark needs to disappear at the end of a line, and agreed to the following:

• RESOLVED: Let editors choose the behavior and mark this at-risk
• RESOLVED: Publish new WD of css-text-3

The full IRC log of that discussion

<dael> Topic: [css-text-3] Ogham Space Mark needs to disappear at the end of a line
<dael> github: https://github.com//issues/4893
<dael> fantasai: Issue is that there is an ogham space mark. Let me show a pic
<fantasai> https://omniglot.com/writing/ogham.htm
<dael> fantasai: Writte on the line. In paragraphs it's on the line. Character called Ogham space mark
<dael> fantasai: When breaking lines should disappear at end of line.
<dael> fantasai: Wanted to add a rule you should drop final Ogham space mark when trimming
<fantasai> https://github.com//issues/4893#issuecomment-613175286
<dael> fantasai: Question how to do that.
<dael> fantasai: Implication are about what happens when you mix spaces and Ogham space marks
<dael> fantasai: Not likely to happen so it's what's easiest to implementa and we should pick that
<dael> florian: Main alternatives is at end of line you get rid of any mix of reg and Ogham spaces. Or you do in phases. Remove spaces, any Ogham left, you remove those.
<dael> AmeliaBR: Any other characters we treat as trimmable spaces for line wrapping but aren't classified in collapsable?
<dael> fantasai: Not that I know of and this is the only one mentioned in the report
<dael> florian: Tabs have been converted to spaces at that point
<dael> fantasai: Other visible word spacer marks but they don't disappear at end of line
<dael> fantasai: There might be others
<dael> astearns: Any notion which is easiest to implement?
<dael> AmeliaBR: Any cases where the two algorithms have different effects?
<dael> fantasai: Different effects. You can see it in the comment linked above
<dael> florian: I suspect two pass is easier to implement b/c you let unicode do normal and than a second pass rather than hacking to know about Ogham spaces. But I'm not implementing
<dael> fantasai: If no one on the call knows, please comment on issue. If not I'll do whatever Koji says
<dael> fantasai: Spec wording is new and not entirely clear so I'll tighten up a bit so it's clear
<dael> astearns: Any opinions?
<dael> astearns: We could resolve to do what koji says and mark at risk?
<dael> fantasai: Yep. Just say up to editors
<florian> s/you let unicode do/you let ICU do/
<dael> astearns: Prop: Let editors choose the behavior and mark this at-risk
<dael> astearns: Obj?
<dael> RESOLVED: Let editors choose the behavior and mark this at-risk
<dael> astearns: Publication with this change?
<dael> fantasai: Let's just publish to get an updated draft. Some issues left. Can do new WD
<dael> astearns: Does this publication need resolution?
<dael> fantasai: Yes
<dael> astearns: Prop: Publish new WD of css-text-3
<dael> astearns: Not in CR?
<dael> fantasai: Not yet.
<dael> astearns: Should push to CR
<dael> fantasai: That's the goal. I've triaged. A couple of things need comments. There's the whole removing break transformation which we've drafted.
<dael> astearns: Objections?
<fantasai> main open issue for css-text-3 is https://github.com//issues/337#issuecomment-612686124
<dael> RESOLVED: Publish new WD of css-text-3

[fantasai]

@jfkthame @kojiishi Any thoughts on which option is easiest to implement? See #4893 (comment)

[jfkthame]

In general, I'm guessing option 1 (include Ogham Space Mark among the white space characters trimmed at the end of a line) would be the most straightforward.

However, I have one somewhat-related question. The current text in 4.1.2 step 3 says:

A sequence at the end of a line of collapsible spaces is removed, and any trailing U+1680 OGHAM SPACE MARK is also removed if it’s ‘white-space’ property is ‘normal’, ‘nowrap’, or ‘pre-line’.

ISTM this will lead to a surprising user experience in editable content, in that when U+1680 is typed at the end of the current text, it doesn't appear (as this rule removes it); but then when another letter is typed after it, the intervening space mark suddenly pops into view.

Does this case need to be addressed somehow? I'm not sure exactly where/how, though...

[frivoal]

the user experience with editable content when white-space isn't pre-wrap (or break-spaces) is already quite weird anyway, so I am not too sure we should be worried about that in particular.