[css-text-4] hyphenate-character doesn't accept just a character

[litherum]

https://drafts.csswg.org/css-text-4/#hyphenate-character

Name: 'hyphenate-character'
Value: | auto | <string>

Shouldn't it accept just a single character? Or the prose should say everything except the first code point (or grapheme cluster) should be ignored? Or perhaps the property should be renamed to hyphenate-string?

[kojiishi]

cc @r12a

[kojiishi]

Good point. All hyphenations Android supports today are one code point (Hyphenator.cpp @ android.googlesource.com)

[litherum]

I would be wary of any place in CSS that operates on single code points instead of graphemes clusters. For example, if this feature works with arbitrary ASCII text, I see no reason why it shouldn’t work with combining accents and combining emoji (like the families). In general, humans (even programmers) don’t understand the relationship between code points and things they see on the screen.

[litherum]

That being said, I don’t think it’s very valuable to put emoji or tons of stacked combining marks in the string. Perhaps a better solution is for the property to just accept keywords for the various popular kinds of hyphens.

https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-hyphenate-character/

[kojiishi]

I like that idea. With keywords, we can also support more complex cases.

[css-meeting-bot]

The Working Group just discussed hyphenated character name, and agreed to the following:

• RESOLVED: no to rename and add normative text desc how UI are allowed to truncate additional characters

The full IRC log of that discussion

<dael> Topic: hyphenated character name
<dael> github: https://github.com//issues/2809
<bradk> Initial-text?
<dael> myles: it allows you to put in a whole string so hyphenate-character seems disingenuous
<dael> fantasai: I think from user view it's a single char that goes in there. hyphenate-string seems fine
<dael> fantasai: But I think we have impl shipping
<dael> myles: We are one of those impl. I was thinking you could go other direction and have accept a string and all grapheme clusters except first get ignored
<dael> fantasai: Happy to have UA truncate appropriately. Not sure first grapheme cluster is enough. There's CJK punt that's >1 code point. If that's covered seems fine
<dael> myles: How about we don't have to specific details and have that sep issue. We can say text is truncated to something similar to a grapheme cluster
<dael> fantasai: At min include 1 grapheme cluster
<dael> fantasai: Other comments?
<dael> fantasai: Propsal: hyphenate-character keeps name, but UI may/can/should truncate if it's more than one grapheme cluser
<dael> myles: Should be normative
<dael> florian: Decide how strict?
<dael> florian: If we'r enot sure may/can/should we should decide.
<dael> Rossen: Let's resolve on renaming property. We're saying no and add normative text desc how UI are allowed to truncate additional characters
<dael> Rossen: Objections?
<florian> I'd go with "required to truncate" rather than "allowed to truncate"
<dael> RESOLVED: no to rename and add normative text desc how UI are allowed to truncate additional characters

[r12a]

fwiw, I checked out the use of hyphenate-character at the link in #2809 (comment). I could only find it being used in two sites (exlibris and hurriyetaile), and in both cases the 'string' identified was "\2010", ie. not a string at all.

I don't know of any real world hyphenation approach that uses multiple characters, or have decompositions into multiple characters (though that's not to say that there aren't any).

[fantasai]

Committed text allowing (MAY) the UA to limit the hyphenation string to a single typographic character unit in bfb538a

I wanted to check with the WG on a few points, though:

• Should we limit it to a single character unit or the UA's choice of N character units?
• Should this affect the computed value or only the used value?
• Should it be MAY or MUST?

Also, @r12a, do you have an example I can use that's not "\2010"? It's not a very good example for the spec since hyphenate-character: "\2010" is essentially a no-op...

[litherum]

Committed text allowing (MAY) the UA to limit the hyphenation string to a single typographic character unit in bfb538a

I wanted to check with the WG on a few points, though:

• Should we limit it to a single character unit or the UA's choice of N character units?

Let the UA just do the right thing here. If the author supplies some ridiculous long string, I don't think I would consider content "broken" that cuts it in one place as opposed to another place. So it's probably okay if browsers differ here.

Similarly, it's conceivable that an implementation might not handle hyphenating with multiple characters at all, and such an implementation probably shouldn't be nonconformant.

• Should this affect the computed value or only the used value?

It's conceivable that an implementation might decide to cut the string at different places depending on the font size and the width of the containing block. This information isn't known at style resolution time, so not affecting computed value would be better.

• Should it be MAY or MUST?

I'd say MUST, because if the UA doesn't do any cutting at all, it's broken.

Also, @r12a, do you have an example I can use that's not "\2010"? It's not a very good example for the spec since hyphenate-character: "\2010" is essentially a no-op...