Re: [w3c/manifest] Remove Trim() logic on string members (#620)

I've done an analysis of a large corpus of about 50,000 manifests (from January 2017, so somewhat out of date).

The results are that there are only 6 manifests that have leading/trailing whitespace in a field other than name, short_name, description; all of them are the "src" field of an icon. 4 of them are completely non-sensical (the whitespace is a backslash before a word starting with 't' or 'f', like `"\the"` (i.e., "<tab>he"), so obviously that's not correct). So we're going to break ~2 sites' icons.

I also found 9 manifests with a trimmable description, 15 with a trimmable short_name, and 100 with a trimmable name. Though as discussed, I think if we drop the "Trim" behaviour from these fields, it will have no observable effect, because user agents will still be allowed to to trim those fields at their discretion (and they should continue to do so).

I'll try to get a newer corpus to re-run the analysis, but at this stage, it looks like we can just remove Trim now.

Maybe we do it in a separate PR to @kenchris's major refactor, so we have a small change that explicitly breaks backwards compatibility, and Ken's change should have no real observable effect.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/620#issuecomment-333746001