Webdev 5735 use screenname

[mc2]

• Use screen name instead of user's item identifier.
• Replace string.length test that can split a unicode code point with code that better counts and splits by character.

webdev-5735

[latonv]

Just noted one possible improvement to the truncation. Otherwise LGTM!

[latonv]

Thank you for handling multibyte code points sensibly!

I'm curious, are screen names always stored in NFC-normalized form? If we don't have that guarantee, one additional step that might help here is normalizing the screen name string before any length-checking or truncation, to collapse any combining characters down to their "combined" form if possible. If a name has multiple combining accents that don't contribute to the visual width of the string, for instance, we can avoid including those in the length budget. Notably, this also prevents us from accidentally truncating an accent off, at least in cases where the combined character exists.

const normalizedScreenName = this.screenName.normalize('NFC');

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize

[mc2]

Hi Laton, I'd like to do more tests, but I believe converting the string into an array is the simplest mechanism for splitting a multibyte string by grouped (in a single character) sequence of code points.

If we use normalization to count, we might break the visual display of the original character -- or more complicated counting of normalized str.length.

[latonv]

The array conversion you're doing is indeed a great, simple way to get the sequence of multibyte code points from the original string. I fully endorse that approach!

Normalization here would accomplish a different goal: ensuring that sequences of separate code points that can be represented by an equivalent single one are always collapsed to the single-code-point version prior to the array conversion & truncation.

To demonstrate what I mean, consider a screen name like déjà rêvé, which contains several accents. These can either be encoded using combining characters (like e + ́ ), or with pre-combined accented letters like é. Note that in the first case, the letter and its accent are considered two separate code points.

So [...'déjà rêvé'].length is 13 when the accents are encoded as combining characters. Notice that without normalization, [...'déjà rêvé'].slice(0, 9).join('') produces 'déjà re' with the accent erroneously dropped from the final e.

[...'déjà rêvé'].length is 9 when the accents have instead been collapsed into their adjoining letters via normalization, so the string does not require truncation at all. (However, if we were to truncate it, we would not risk splitting up a letter with its accents like the above, because each letter/accent combination is now a single code point).

If anything, this should preserve the visual display of the original characters in cases where they would otherwise be broken apart.

[mc2]

Thanks for the detailed explanation. I'll use this.

[latonv]

There are, of course, further cases where even this normalization fails to help, and to address those we would need to consider entire grapheme clusters, which is substantially more involved. Consider tricky usernames like:

• hello! 👩🏾‍🚀 (many clients will render a single emoji comprising the final four code points; truncation in the middle of this sequence will result in a different emoji altogether)
• संवर्तस्थायिकल्प (contains several combining diacritics that have no corresponding pre-combined form)

(I'm not advocating that we deal with cases like those within the scope of this ticket! Just pointing it out for a clear sense of where the edges are.)

[mc2]

I've tested many different in-browser truncations of multiple code point characters in Chrome, FF, Edge, and Brave. The browsers have never chopped a multi-point character (can't really tell with the Indian(?) script above -- even with non-normalized composition unicode.

I've chosen to not normalize and rely on in-browser truncation. Code to follow after fixing problem with static top nav.

[mc2]

FWIW: https://developer.mozilla.org/en-US/play
HTML:

<div id="parent">
  <div id="child">
    Fusce pr संवर्तस्थायिकल्प vestibulum eros, sed luctus ex lobortis quis.
  </div>
</div>

CSS

#parent {
  background: lightblue;
  width: 300px;
}

#child {
  background: gold;
  max-width: 150px;
  text-overflow: ellipsis;
  overflow: hidden;
  white-space: nowrap;
}

[latonv]

Sounds good -- normalization would only be required if you're slicing up the string yourself. No need if we're going to use CSS truncation instead (which I assume is based on the width of rendered text, rather than the underlying text encoding).

[latonv]

👍

[latonv]

Just noting that browsers can also be made to perform this RTL character check natively, by adding a dir="auto" attribute to the enclosing element. The first strongly-directional character found in the element's text determines its overall directionality, placing nondirectional characters (like the ellipsis) on the corresponding side automatically: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir

(Maybe that wouldn't apply to this use case, but just figured I'd point it out as an option to explore)

[mc2]

Thanks Laton, yes, aware of dir="auto" and that, if I'm not mistaken, requires an rendered element to work on.

[latonv]

Yeah, it's true that the RTL checks would take place at render time rather than during JS execution, and the result would not be readily available to our code.

My thinking was that if we can get the browser to do all the RTL detection & rendering work for us natively, then we may not need JS-based RTL checks in the first place. Using dir="auto", the browser can determine which side to visually render the ellipsis on without our JS having to know anything about the directionality of the text.

[mc2]

Thank you for your considered discussion.
I checked with Jim Shelton about having truncation/ellipsis by max-width and not 9 characters. Gets rid of a good deal of code, which makes sense to me.