Re: [w3c/manifest] Manifest name: USVString or not? (Issue #1228)

domfarolino left a comment (w3c/manifest#1228)

The other spec I was looking at is https://github.com/WICG/sub-apps/pull/1#discussion_r3529591796, so basically https://wicg.github.io/sub-apps/#dom-subappslistresult-appname, which is meant to expose in IDL a manifest's [`name`](https://w3c.github.io/manifest/#dfn-name).

Thanks a lot for the pointer to https://www.w3.org/TR/international-specs/#char_string. I have to say, I think the guidance around string usage is still unclear, even after reading (not that that's any one group or person's fault or anything). For example, i18n says:

> Use a [USVString](https://webidl.spec.whatwg.org/#idl-USVString) when defining an algorithm that iterates over the [code points](https://infra.spec.whatwg.org/#code-point) in a string. Use [USVString](https://webidl.spec.whatwg.org/#idl-USVString) for any process which involves [UTF-8 encode](https://encoding.spec.whatwg.org/#utf-8-encode) or for anywhere in which an unpaired [surrogate](https://infra.spec.whatwg.org/#surrogate) [code point](https://infra.spec.whatwg.org/#code-point) would produce an error.

In other words, use USVStrings only when you yourself have an algorithm that directly depends on the scalar values in the string. On the other hand, [TAG's design principles](https://w3ctag.github.io/design-principles/#idl-string-types) say:

> [USVString](https://webidl.spec.whatwg.org/#idl-USVString) is [...] For [...] operations which can’t handle [surrogates](https://infra.spec.whatwg.org/#surrogate) in input (such as APIs that pass strings through to native platform APIs), [USVString](https://webidl.spec.whatwg.org/#idl-USVString) should be used.

So in the manifest spec where nothing directly relies on the scalar values in a "name" or "short_name", i18n says I should use a DOMString. But writing that spec with the assumption that these bytes will be pumped into native platform APIs for display outside of the browser, the TAG"s guidance seems to say I should anticipate the native API's inability to handle unpaired surrogates / invalid UTF-16 strings, and cover for it by using a USVString before exposing my string bytes. Would love @jyasskin's take on this when he's back from leave.

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

Message ID: <w3c/manifest/issues/1228/5065713846@github.com>