[css-text-4] hyphenate-character doesn't just put hyphen at end of line

[r12a]

8.1. Hyphens: the hyphenate-character property
https://drafts.csswg.org/css-text-4/#hyphenate-character

If a string is specified, it appears at the end of the line before a hyphenation break.

I can't find an example at the moment, but i'm pretty sure i have come across languages that put the hyphen at the beginning of the second line, rather than before the hyphenation break. This appears to be supported by the Unicode Standard, which says:

A common default rendering is to insert a hyphen before the line break, but this is insufficient or even incorrect in many situations.

[litherum]

I hope we don’t need a new property or new syntax for this. Can the UA use the lang attribute and just do the right thing?

[r12a]

Yes, that's what i was assuming for the normal case, ie. where you're doing what a language normally does during hyphenation.

If you're using hyphenate-character: "\01F449" for fun, then i don't know whether people using that language would expect the 👉 to appear at line start.

[Crissov]

Isnʼt that quote more about not adding an additional hyphen when you are, for instance, breaking an already hyphenated word?

[Crissov]

Would hyphenate-character: "\0A\1F449" work, by the way?

[r12a]

@Crissov I almost wrote another issue about this, but in the sentence

This property specifies strings that are shown between parts of hyphenated words.

'between parts of hyphenated words' is somewhat ambiguous, but i assumed the sentence refers to strings defined using hyphenate-character which are inserted between words that are split during the process of hyphenation (ie. not necessarily hyphenated in the sense of words-with-hyphens-in-them).

[r12a]

Can the UA use the lang attribute and just do the right thing?

@litherum it may be worth noting that presumably the UA has to do its own thing to an extent anyway, since it needs to change things in Dutch like cafeetje → café-tje, autootje → auto-tje, or skiërs → ski-ers, not ski-ërs. Maybe that would also apply to the position of the 'hyphen' at line end/start.

[kojiishi]

IIUC this was one of the motivations @litherum proposed keywords for hyphenate-character in #2809?

[r12a]

I can't find an example at the moment, but i'm pretty sure i have come across languages that put the hyphen at the beginning of the second line, rather than before the hyphenation break.

Unicode Standard, v11, p536:

In writing Mongolian and Todo, U+1806 mongolian todo soft hyphen is used at the beginning of the second line to indicate resumption of a broken word. It functions like U+2010 hyphen, except that U+1806 appears at the beginning of a line rather than at the end.

[faceless2]

Given the point of hyphenate-character is to allow overriding the current language's default hyphen, I'm not sure you can just rely on the language to do the right thing.

• in english, hyphenate-character: auto will add U+002D to the end of the first line.
• in mongolian, hyphenate-character: auto will add U+1806 tp the start of the second line.
• what do I do if the language is english and I specify hyphenate-character: "\1806"?

But I really like @Crissov's (low-key) idea of using a newline. If the hyphenate-character has a newline, split at the first newline and put the first half and the end of the first line, and the second half at the start of the second line. If not, it goes at the end of the first line. Covers every situation, and no new property required.

p { hyphens: auto; hyphenate-character: "…\A…" }
<p>Welcome to Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch!</p>

Welcome to Llanfair...
...pwllgwyngyllgoge...
...rychwyrndrobwllll...
...antysiliogogogoch!

[jfkthame]

But I really like @Crissov's (low-key) idea of using a newline. If the hyphenate-character has a newline, split at the first newline and put the first half and the end of the first line, and the second half at the start of the second line. If not, it goes at the end of the first line. Covers every situation, and no new property required.

I'm a bit uncomfortable with this, as it's impossible for an author to know whether this extended functionality is supported or not; given that it's a fairly obscure case, and may involve some implementation complexity, it may be preferable to make it clearly distinct from the "normal" case where the hyphenate-character string simply appears before the break.

An alternative way to extend the property would be to allow an optional second value; if two strings are provided, then the first string (which could be empty) appears before the break, and the second string after the break. This allows for graceful degradation in the usual CSS way if the browser doesn't support the extended syntax.

[fantasai]

My preference here is to leave the position of a single-string value up to the language, and only replace the character rather than changing its insertion behavior.

If we want control over where it goes, though, things get a bit more complicated. I agree with @jfkthame that if we're having separate values for before/after the break, it would make sense to use two strings to indicate that. But then how do we handle rules such as “hyphenation character goes on the first line, unless the word was hyphenated already in which case it goes on both lines”?

[fantasai]

Agenda+ to propose that a single-string value only changes what character is inserted, and does not change where it is inserted.

[css-meeting-bot]

The CSS Working Group just discussed hyphenate-character doesn't just put hyphen at end of line, and agreed to the following:

• RESOLVED: A single-string value changes what is inserted, but not where

The full IRC log of that discussion

<emeyer> Topic: hyphenate-character doesn't just put hyphen at end of line
<emeyer> github: https://github.com//issues/2975
<emeyer> fantasai: Last two comments on issue clarify that single-string value changes what is inserted, but not where
<jfkthame> +1
<emeyer> Rossen_: Any opinions?
<emeyer> florian: I think it’s the right thing to do for now
<emeyer> …When we look into expansions, we’ll need to think harder about whether this is a novelty thing or about symbols in other languages
<emeyer> RESOLVED: A single-string value changes what is inserted, but not where
<florian> s/symbols in other languages/manually defining hyphenation in unsupported languages/

[frivoal]

Made the fix in 2a23164. Let me know if there's anything wrong with it.