Oh, one more:

We will refer to the the typographic character unit as the basic unit of text. ... The typographic character represents ... a Latin alphabetic letter (including its diacritics), Hangul syllable, ..."

This seems to say that a typographic character unit often corresponds to more than one code point.

A typographic letter unit or letter for the purpose of this specification is a typographic character unit belonging to one of the Letter or Number general categories in Unicode

The general categories are categories of a single code point. How can we determine the general category for an entire multi-code-point-sequence?

@litherum Wrt #3461 (comment) see https://www.w3.org/TR/css-text-3/#character-properties , cross referenced from the sentence right after the one you're quoting.

Unclear whether or not the form feed causes breaks to be removed.

Shouldn't be, rendering as a different character doesn't change its identity....

Also, "rendered as a zero-width space" is probably not what you want. Zero-width spaces can participate in text shaping inside the font, and some fonts even have visible glyphs for zero-width-space that get removed by shaping. Why doesn't the spec say they're removed instead of rendered as U+200B?

Because you didn't want to in #855 (comment) ? :)

[Re-opened that issue because we later resolved on different handling for CR, but didn't re-discuss FF.]

Similarly to above, leaving behind the ZWS is probably not what you want, as it can participate in shaping. It seems CSS is trying to treat the ZWS as a flag to signal behavior for the following break; leaving the flag behind seems like pollution.

ZWSP isn't pollution, it's signal. It's the white space surrounding it that's noise we're trying to clear out. If we removed the ZWSP along with the white space, we'd lose important behavior that it represents, like a line break opportunity / break in joining.

A more useful link would be appreciated, instead of linking to the Unicode homepage.

That's not the Unicode home page (which is at http://www.unicode.org/), it's the table of contents for the core standard. I can't take responsibility for how the main content is in a sidebar. :/ Default_ignorable is defined, in this edition, in section 5.21. (Many of our references to Unicode are to its annexes, which each have their own HTML document at their own URL, but this is a reference into the core standard, which is a PDF linked from this version-agnostic landing page.)

These sentences seem contradictory. "Removed" is not "collapsed."

Adjusted the wording. Fwiw, the latter is trying to handle the requirements brought up in http://lists.w3.org/Archives/Public/www-style/2012Jan/0936.html I'm not sure how well it's succeeding.

It took me a while to figure out what the Segment Break Transformation Rules were trying to accomplish. An example showing uninterrupted Chinese text would be appreciated.

OK, I'll add an example. :)

In some other writing systems, soft wrap opportunities... This paragraph seems non-normative. Perhaps move it to a note?

That paragraph as well as the previous one are similar in that they're laying out the expectations. They're not strictly normative nor really solely informative... This is somewhat of an introductory section anyway, so I think it's better to leave them outside of a note. Notes are a type of aside, and this information is somewhat critical to making sense of the spec.

@litherum OK, I think I've addressed all your comments. Let me know if something still seems unresolved?

Unclear whether or not the form feed causes breaks to be removed.

Shouldn't be, rendering as a different character doesn't change its identity....

Okay.

Why doesn't the spec say they're removed instead of rendered as U+200B?

Because you didn't want to in #855 (comment) ? :)

heehee. Yes, I see now. I'll see if I can come up with an example where it matters.

If we removed the ZWSP along with the white space, we'd lose important behavior that it represents, like a line break opportunity / break in joining.

I'm not sure that preserving it is doing authors any favors. Is this implemented anywhere, and do we know of authors who have used this mechanism to un-break lines? I'd like to hear what their expectations / desires are.

it's the table of contents for the core standard.

Can't we do better somehow? 😕

Adjusted the wording.

👍

OK, I'll add an example. :)

👍

so I think it's better to leave them outside of a note.

🤷🏻‍♂️ Okay.

https://www.w3.org/TR/css-text-3/#character-properties

Ah, I see. It's pretty unfortunate we have to have special cases for Unicode. Presumably other text engines don't have these special cases, which means other editors should have the special cases, or CSS should adopt whatever behavior the other editors have.

Therefore, either:

1. These special cases should be moved into Unicode, allowing the behavior to be shared among all text editors, or
2. We should find a new way of solving this problem

I'm not sure that preserving it is doing authors any favors.

If the author didn't want it there, he shouldn't have put it there.

Can't we do better somehow?

Open to suggestions...

Ah, I see. It's pretty unfortunate we have to have special cases for Unicode. Presumably other text engines don't have these special cases, which means other editors should have the special cases, or CSS should adopt whatever behavior the other editors have.

Text engines generally don't do white space collapsing, which is the only place we're using EAW, so that's not something they need to think about, only we do. Wrt text orientation, we did end up with UAX50. Then there's justification which references things in https://www.w3.org/TR/css-text-3/#justify-symbols, which is outside the scope of Unicode and somewhat handwavy anyway... I don't see there's much benefit in getting Unicode involved here.

@litherum this issue contained a bunch of subtopics. As far as I can tell, they've all be addressed to satisfaction (fixed or explained away), so I'm closing this. If you think one or more of your concerns still need more work, please open individual issues to track them separately.