Consider removing TextEncoder support for UTF-16

[hsivonen]

AFAICT, non-UTF-8 encoders are exposed in three places in the Web Platform:

1. TextEncoder
2. Query string parsing for URL and the associated APIs
3. Form submission

URL parsing and form submission use UTF-8 when the encoding of the document is either of the UTF-16 encodings, AFAICT, TextEncoder is the only place where the Web Platform exposes UTF-16 encoder functionality.

This is pretty sad, if TextEncoder support UTF-16 just because it can and the support doesn't have strong use cases.

Am I wrong and do proper use cases exist for UTF-16 in TextEncoder to a degree that sets UTF-16 apart from the other legacy encoding that aren't supported in TextEncoder?

[inexorabletash]

Since the API is live in Chrome, let me try and get numbers on usage before we consider removing. That may take a release cycle.

[inexorabletash]

Early stats (Chrome Canary) show a whopping 0.0000005% of page loads use TextEncoder with UTF-16 variants. I'll report in again once the counter hits stable.

[peteroupc]

@inexorabletash : Have you gathered stats on use of UTF-8 with TextEncoder? It's possible that use of UTF-8 in TextEncoder (or TextEncoder in general) might be equally rare.

[inexorabletash]

@peteroupc : Good question! Not directly but https://www.chromestatus.com/metrics/feature/timeline/popularity/429 shows the usage of the TextEncoder constructor itself at ~0.0004% of page loads. (So 3 orders of magnitude higher.)

That'd be UTF-8 + UTF-16 + any calls into the constructor that throw due to unsupported encodings. I'm assuming the failure #s due to unsupported encodings are low. https://www.chromestatus.com/metrics/feature/timeline/popularity/430 shows the actual number of calls to encode() at 0.0001% of page loads, which puts a lower bound on the successful construction calls. (4x constructions vs. usage calls is a bit odd)

[annevk]

@inexorabletash given https://www.chromestatus.com/metrics/feature/timeline/popularity/1061 can we go ahead with this?

[inexorabletash]

I'd like the counter to hit the stable channel first. It only went in in December, so it'll be in the M49 release, which should be at the start of March.

That said, it looks extremely promising, even in the internal (absolute, not %) numbers.

[jungshik]

I wonder if web-based OS such as Chrome/Chromium OS and Firefox OS has any need for UTF-16 encoder. One (edge) use case I can think of is to produce ID3 tag for mp3.

[annevk]

@jungshik that also applies to "pure ASCII" or "unaltered iso-8859-1" which we so far have easily resisted to add. Might not hurt to ask though.

[jungshik]

Oh. I forgot that ID3 v2.4 supports UTF-8 ( https://en.wikipedia.org/wiki/ID3 ). In that case, my case for UTF-16 encoder with ID3 tag is not valid any more.

[inexorabletash]

Counter has hit stable. Usage is around 0.00000000001%. Seems safe to remove.

[annevk]

Review of #36 appreciated.

[inexorabletash]

Tracking bug for Chrome update: https://crbug.com/595351

[inexorabletash]

We'll want to update web-platform-tests as well.