undesirable word-internal linebreaks

[solpahi]

See the end of the first line.

[solpahi]

The breaks still happen.

[uakci]

@solpahi proof?

[solpahi]

Same as in the screenshot as above. https://toaq.github.io/TwE/03/

On mobile, this happens in lesson 1, where it splits dẻ into d and ẻ.

[uakci]

That's weird. I might need to rewrite accents.js entirely in order to fix this.

[lynn]

I pushed kind of an extreme fix: now nothing in boldface (**asterisks**) is ever word-wrapped.

This is actually quite nice for readability of the "textbook" because even something like sa pỏq won't get split into “sa (newline) pỏq”.

However, it means you have to manually word-wrap (with <br>) example sentences at the start of the lesson if they get too long.

[uakci]

Indeed it's an extreme fix, and I'm afraid it's too extreme a fix to be useful (why should we word-wrap anything manually?). There's another way to do it, though: change (not necessarily you) the script to break a single <strong> into multiple ones, split at spaces. Then, leave the wrapping behaviour as it is right now. This allows for finer control, since ¹) longer runs of text won't need to be broken into bits manually, which would be tedious, and ²) should anything need to be left as an unbreakable unit,   would be here to help.

-------- Original Message -------- On 25 Nov 2019 3:56 am, Lynn wrote:

I pushed kind of an extreme fix: now nothing in boldface (asterisks) is ever word-wrapped.

This is actually quite nice for readability of the "textbook" because even something like sa póq won't get split into “sa (newline) póq”.

However, it means you have to manually word-wrap example sentences at the start of the lesson if they get too long.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

[lynn]

why should we word-wrap anything manually?

Below a certain line width, humans are much better at deciding how to wrap text into a small space than algorithms. This is especially true compared to the naïve “fit as much text as possible on this line, then move on to the next one” algorithm used by a browser. For example,

Hu m⁠á⁠m⁠ā⁠, k⁠ú⁠n⁠ē⁠ by, t⁠ỉ⁠ h⁠ó⁠ hı r⁠ả⁠ı moq?
②③

is better wrapped as

Hu m⁠á⁠m⁠ā⁠, k⁠ú⁠n⁠ē⁠ by, t⁠ỉ⁠ h⁠ó⁠ hı r⁠ả⁠ı
moq? ②③

to visually attach the footnote numbers to the end of the sentence rather than letting them sit alone on a line.

In HTML, you can indeed hint the algorithm not to break in certain places with  , but it doesn't always work when mixing tags. Sometimes manually wrapping is the best recourse, provided that you have at least a rough idea of the font metrics and the amount of available space. Placing a <br> where necessary is no more laborious than placing a   where necessary.

[lynn]

Ah, how ironic.

---

All that said: I think your solution is the way to go. However, I'll just leave the strong { white-space: nowrap; } rule out of the CSS, and reprogram the script to turn h⁠ó⁠ into <span style="white-space:nowrap;">h<span ...>ó</span></span>. That way, a user who has JavaScript disabled will never face an overlong sentence that the script was supposed to chop up.

[uakci]

Gut gemeint. I'm looking forward to your contribution, Ms. Lynn.