Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Note about choice of USVString imprecise #152

Closed
aphillips opened this issue May 14, 2020 · 4 comments · Fixed by #153
Closed

Note about choice of USVString imprecise #152

aphillips opened this issue May 14, 2020 · 4 comments · Fixed by #153
Labels
i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.

Comments

@aphillips
Copy link

WebShare
https://w3c.github.io/web-share/#sharedata-dictionary

These members are USVString (as opposed to DOMString) because they are not allowed to contain invalid UTF-16 surrogates. This means the user agent is free to re-encode them in any Unicode encoding (e.g., UTF-8).

The above "Note" about the choice of USVString over DOMString is imprecise. I18N would suggest the following wording instead:

These members are USVString (as opposed to DOMString) because they are not allowed to contain surrogate code points. Among other things, this means that the user agent can serialize them into any Unicode encoding, such as UTF-8, without change or loss of data or the generation of replacement characters.
@aphillips aphillips added the i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. label May 14, 2020
@aphillips aphillips mentioned this issue May 14, 2020
Closed
ewilligers pushed a commit to ewilligers/web-share that referenced this issue May 15, 2020
@ericwilligers
Clarify reason for choosing USVString
cf74259 
We use USVString members as they are not allowed to contain
surrogate code points.

chore: closes w3c#152
ewilligers pushed a commit to ewilligers/web-share that referenced this issue May 15, 2020
@ericwilligers
chore: Clarify reason for choosing USVString
4fe198e 
We use USVString members as they are not allowed to contain
surrogate code points.

closes w3c#152
@ewilligers ewilligers mentioned this issue May 15, 2020
Merged
ewilligers added a commit that referenced this issue May 15, 2020
@ewilligers @ericwilligers
chore: Clarify reason for choosing USVString (#153)
6c8c25a 
We use USVString members as they are not allowed to contain
surrogate code points.

closes #152

Co-authored-by: Eric Willigers <ericwilligers@chromium.org>
@hober hober mentioned this issue May 15, 2020
Closed
@marcoscaceres
Copy link
Member

@aphillips, just confirming that the text you suggested is in the spec. See the note:

https://w3c.github.io/web-share/#sharedata-dictionary

Could you (or @xfq?) kindly remove the i18n-needs-resolution label if you are satisfied?

@aphillips
Copy link
Author

@marcoscaceres Thanks for making this change. I am satisfied by the modification.

Please do not remove the i18n-needs-resolution label. It's how we can find this issue again (which assists in our closing our mirror issue w3c/i18n-activity#901, which is how you get a clean bill of health at transition time). You are welcome to close the issue.

@aphillips
Copy link
Author

In our teleconference today, the I18N WG confirmed that we are satisfied.

@hober
Copy link
Member

hober commented Oct 5, 2022

Perhaps this should reference https://www.w3.org/TR/design-principles/#idl-string-types ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

chore: Clarify reason for choosing USVString ewilligers/web-share
3 participants
@hober @aphillips @marcoscaceres