Repository navigation
We should add a character limit to name and short_name #1070
Description
This directly impacts designing UX around displaying app names, and also can cause possible spoofing issues. The standard for extensions is 12 characters for short_name, and 45 characters for name.
Apple limits names to 30 chars, play store is 50.
Activity
marcoscaceres commentedon Feb 6, 2023
As noted, implementations use different strategies to deal with excessive length of these members. So, instead of imposing a limit, we could document that implementations need to find strategies to deal with excessive string lengths (or if there are spoofing opportunities, we should suggest mitigations). Similarly, we could suggest developers limit the length of these strings to something reasonable.
mgiuca commentedon Feb 6, 2023
I agree with @marcoscaceres . This feels very much in the domain of UX, not something where the spec should impose arbitrary limits.
If you were to apply the lowest common denominator here, Android's app list truncates names to somewhere between 8 and 12 characters (depending on the font and the width of the individual glyphs). In other contexts, limiting the name to just 8 characters would look quite silly next to other less-truncated names.
The spoofing issue here is that a name would be shown longer in the install / update prompt, than it is in the app list, so two apps that have distinct names at install time have the same name when truncated. The solution to this is that the UI at install time should use the same truncation as the system's app list (if possible), so that the user sees the same thing in both places. That doesn't require spec support.
Similarly, if we're talking about a denial-of-service where an app has a multi-megabyte name or something, the user agent can fix that by truncating it to, say, ~1K, which is longer than any UI will display. You don't need the spec to tell you to do that: you are free to ignore any part of any field you like.
aarongustafson commentedon Feb 6, 2023
+1 to what @marcoscaceres & @mgiuca. I think authoring guidelines are the extent of what we should do. I think we have similar language in the
shortcutssection. Perhaps it’s worth considering a section talking about variation in interpretation of the manifest and how authors should consider the values they provide.dmurph commentedon Feb 6, 2023
Great, I like this. Thanks for the discussion. I'll plan on authoring guidelines here so at least developers are aware that these strings may be truncated.
aphillips commentedon May 15, 2023
You may wish to refer to this section of Best Practices for International Specs for more info on length limitations.
dmurph commentedon Sep 30, 2024
@aphillips
Super interesting! Thanks for this. I'm guessing we COULD specify some large limit for physical storage on disk that hopefully shouldn't affect practically affect anything - (4kb for each?)
The main thing I'm concerned about / we've had to deal with: The main limitation here is the physical size of, say, the UX element. E.g. the 'uninstall' dialog needs to show the app name. Sometimes UX elements have fancy eliding functionality, but other times (and in Chromium usually for our browser UX) we have to pre-process the text to elide the physical length. I found the place we do this in Chromium for tab titles. Do you know if there are specifications around doing physical truncations-plus-ellipsis based on pixel width available? If not, we can easily put non-normative text that a UA may limit / elide
short_nameto pixel width for dialogs, and same forname.aphillips commentedon Sep 30, 2024
You probably want to provide some sort of author guidance. The short name should, presumably, be short, but super-specific limits run up against variation in language encoding and UX design. Elision should be on grapheme boundaries and, ideally, word boundaries (falling back to grapheme boundaries).
CSS does this in text-overflow and line-clamp (we're currently having a spirited discussion of the best way to do line-clamp, which is probably closer to what is wanted, since you want to truncate logically). Those might be places to look for descriptions.
Definitely you want to do something like this.
dmurph commentedon May 1, 2025
Great. I think the conclusion is that we should add some editorial text something like:
aarongustafson commentedon May 1, 2025
Maybe "truncate"? It feels a little more common than "elide".