Re: [w3c/manifest] Add IDL section and define IDL for some of the members (#612)

Hi Ken,

This is a good start. Thanks for taking this; I wasn't expecting you to do it but if you're happy to continue, go ahead.

One point that keeps coming up is DOMString vs USVString. The difference is DOMString allows illegal surrogate pairs while USVString does not. The WebIDL spec tells you not to use USVString unless you have a good reason (the main accepted use of USVString is URLs). My opinion is the opposite; that USVString should generally be preferred because illegal surrogate pairs are meaningless, and cannot be represented outside of UTF-16. I think the rule of thumb should be that if the string characters are displayed to the user or leave the browser, then it should be a USVString, but if it's an internal string only (e.g., an ID string) then it can be a DOMString.

I successfully argued this logic in Web Share which is why the [ShareData fields are USVStrings](https://wicg.github.io/web-share/#sharedata-dictionary).

At the very least, all URL fields should be USVStrings. For Manifest, many of the strings will be exported out to the OS (e.g., on shortcuts) and illegal surrogate pairs may not be representable. I would advise the following strings be USVString:

- name
- short_name
- description
- scope
- start_url
- related_applications: all fields
- categories
- Image.src (but not size)

Agree/disagree?

-- 
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/pull/612#issuecomment-330742455