Some notes from our discussion on the ALReq weekly meeting, specifically regarding this issue for Arabic script:

First, regarding underline position in Arabic script:

• It almost never (except calligraphy styles/situations) collides with dots or not-that-tall letters (like REH or WAW). So, this behavior is actually something new and needs to be developed. The current common-practice with exiting digital publishing tools is to set a border-bottom instead of underline.
• To get a good underline experience that's already a common-practice, the underline should be positioned below all the dots and not-that-tall letters. We can develop an algorithm to calculate this from font glyphs data.

Now, about the underline that's too high for Arabic script, assuming that users actually want it:

• In my opinion, min-underline-ink-width is a property of the typeface and shall be stored in the fonts, possibly per script or even per language.
• When not provided by the font, we can calculate min-underline-ink-width for the font based on the size of the dot glyphs (dot, two-dots, ...). A possible value would be 200% of the maximum of the dot glyphs' width.
• Of course some large values will result in underline not getting drawn for most of the width of some words. Well, that's why it shouldn't be positioned so high in the first place!

Personally, I highly recommend to focus on fixing the position problem first, and try to fix the ink issue for a better positioned underline (where in rare cases underline collides with ink, like for a MEEM with a long tail).

I don't think we want min-underline-ink-width. The dots are already not visible if you were not doing any ink skipping, the problem is that this underline position just does not work for arabic. You can control the underline position with existing css-text properties and avoid this problem altogether.

I agree that positioning the underline correctly should help the arabic case significantly, although we should probably also check whether interference with vowel diacritics could lead to similar issues (maybe not), since they may occur in the line of fire even if we avoid the dots.

But i'm also concerned that there may be similar, albeit perhaps not so dramatic, issues for other scripts, such as Thai or or scripts such as Myanmar or Khmer, that stack consonants with potentially only small intervening spaces between the ink below the line. I think this needs some more research.

We may not actually need a min-underline-ink-width property – one possible approach may be to just say something like that underline ink should never be less than two or three times the width of the underline's height. (Just an idea.)

I don't know if the spec really has to say something about that or should just continue to leave the door open to implementors to experiment and tweak this more freely based on user feedback, but I agree globally that it would make sense for User Agents optimized the width and amount of their underlines segments based on their aspect-ratio, and any other relevant information the browser has access to.

Maybe we could add a note to the spec inviting to give this a thought?

Here's an example of a possible problem with a Latin script language, Igbo, which has a low dot diacritic below vowels. In the image below the left sequence has a combining dot below, and the right doesn't.

Here's an Igbo word where it's hard to be sure whether a dot below is used or not.

It is, however, a little easier to spot the distinction in some fonts than others (ie. it's easier where the font makes the dot below more round, or where the letters are wider). The font used above is Arial Unicode.

There are also situations where the meaning is not so hard to detect, but the shortness of the underline is for me a little ugly. I wonder if these would be improved by not trying to underline the vowel at all.(?)

For example, here are a couple of Vietnamese words in Noto Sans font with very short underline fragments (the small dots to the right of the dot below).

and another African language

In the last two examples, perhaps the rule might be not to underline the part of the vowel with a dot below that is next to a descender(?)

@r12a Your suggestion above about what would be good behavior seems reasonable. But do you think it (or something close) needs to be mandated or encouraged by the spec, or is this something that can be left to UAs as a quality of implementation matter?

For the vietnamese, I'd be tempted to say that leaving it up to UAs may be sufficient. In the Igbo example, it does affect readability quite a bit though, so maybe that does call for spec text.

What do you think?

My initial thinking is that we should describe this as a potential issue in the spec, using a note or sentence, but wait to see how UAs implement solutions before being prescriptive – which i think coincides with the suggestion of @FremyCompany.

In case it's useful, this link allows you to see the examples above as text. You can then also apply various different fonts using the controls provided.
https://r12a.github.io/pickers/latin/?text=j%E1%BB%8Bg%20jig%0Aga%E2%80%90ejigide%0At%E1%BA%ADp%20nghi%E1%BB%87p.%0Ail%C3%A9%E2%80%90e%CC%A9j%C3%B3%CC%A9

Use the inspector to apply text-decoration:underline and text-decoration-skip: ink to the textarea.

It's also worth noting that if the underline and the text are in different colors (e.g. black text, aqua underline), there's less interference. So the ideal value of that minimum might be dependent on the contrast ratio between the two!