{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/presentation-api/issues/218","repository_url":"https://api.github.com/repos/w3c/presentation-api","labels_url":"https://api.github.com/repos/w3c/presentation-api/issues/218/labels{/name}","comments_url":"https://api.github.com/repos/w3c/presentation-api/issues/218/comments","events_url":"https://api.github.com/repos/w3c/presentation-api/issues/218/events","html_url":"https://github.com/w3c/presentation-api/issues/218","id":115525100,"number":218,"title":"Possibility for a character to be interpreted differently depending on locale","user":{"login":"tidoust","id":1122927,"avatar_url":"https://avatars.githubusercontent.com/u/1122927?v=3","gravatar_id":"","url":"https://api.github.com/users/tidoust","html_url":"https://github.com/tidoust","followers_url":"https://api.github.com/users/tidoust/followers","following_url":"https://api.github.com/users/tidoust/following{/other_user}","gists_url":"https://api.github.com/users/tidoust/gists{/gist_id}","starred_url":"https://api.github.com/users/tidoust/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tidoust/subscriptions","organizations_url":"https://api.github.com/users/tidoust/orgs","repos_url":"https://api.github.com/users/tidoust/repos","events_url":"https://api.github.com/users/tidoust/events{/privacy}","received_events_url":"https://api.github.com/users/tidoust/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/presentation-api/labels/I18N-WG","name":"I18N-WG","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":14,"created_at":"2015-11-06T15:24:12Z","updated_at":"2016-04-18T20:31:31Z","closed_at":null,"body":"Hi all,\r\n\r\n[I'm raising this as an issue for tracking purpose, but I do not think that there is any issue in the end, so actually suggests to close it once people have reviewed it, unless someone points out that I missed something, of course!].\r\n\r\nThe group discussed potential internationalization issues during its F2F last week [1]. One particular issue that was raised was the possibility for a given character in a JS string to be interpreted differently by both browsing contexts, meaning it would be represented by different glyphs with different meaning in a Japanese, Chinese and/or Korean environment (e.g. a glyph meaning \"Yen\" in Japanese and a different currency in Chinese).\r\n\r\nI said that I believed this was impossible in practice, and took an action \"to investigate the possibility for a JS string to be rendered differently by different glyphs and locales\".\r\n\r\nI had a quick chat with @r12a (Richard Ishida), internationalization activity lead at W3C, and confirm that, unless I missed something in the scenario presented below, such a problem should never ever happen. The Presentation API operates on JavaScript types which are not affected by the character encoding used to retrieve the content.\r\n\r\nThe hypothetical scenario where a problem could have happened was something like:\r\n\r\n1. the app running on the controlling browsing context is served encoded in Shift_JIS (usual encoding for Japanese characters);\r\n2. the app running on the receiving browsing context is served encoded in Big5 (usual encoding for Chinese characters);\r\n3. the app on the controlling browsing context extracts a string from a DOM element\r\n4. the app on the controlling browsing context sends that string over to the receiving browsing context using the Presentation API's \"send\" method;\r\n5. the app on the receiving browsing context sets the received value to a DOM element;\r\n6. the characters rendered on the receiving browsing context for that DOM element mean something different.\r\n\r\nIn particular, regardless of the encoding used to serve a page/app, extracting a string from a DOM element returns a DOMString [2], which is an UTF-16 encoded serialization of the underlying sequence of Unicode characters (in an ideal world, this would return the sequence of Unicode character codes directly, but JavaScript strings are 16-bits only, so some characters are actually represented as two 16-bits surrogate pairs).\r\n\r\nFor instance, the Unicode character of a Japanese's \"katakana letter small A\" is 0x30A1, so if a DOM element contains such a letter, extracting it will yield a sequence with one integer 0x30A1, even if the document that was used to produce this element was encoded in Shift_JIS where this character is represented as a 0xA6 byte.\r\n\r\nFrom the perspective of the Presentation API, the communication channel sends a DOMString to the other end point. The actual bytes sent over the channel depend on the transmission protocol: WebSocket will typically turn the DOMString into Unicode characters (thus creating what WebIDL calls a USVString) and encode the result using UTF-8 for transmission, while other protocols could do differently, e.g. Unicode character codes as 32-bit values. What is important is that the receiving end point will eventually see a DOMString, again to be interpreted as a UTF-16 encoded serialization of a sequence of Unicode characters, independently of the character encoding that was used to load the HTML content.\r\n\r\nWhat may of course happen in the katakana example is that the Chinese font used on the receiving browsing context does not contain the right glyph to represent a Katakana letter small A. The character would be rendered as an unknown one in that case (perhaps as a question mark or a square). This should never produce another character with a different meaning though!\r\n\r\n[1] http://www.w3.org/2015/10/29-webscreens-minutes.html#item07\r\n[2] http://heycam.github.io/webidl/#idl-DOMString\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/w3c/presentation-api/issues/comments/211564494","html_url":"https://github.com/w3c/presentation-api/issues/218#issuecomment-211564494","issue_url":"https://api.github.com/repos/w3c/presentation-api/issues/218","id":211564494,"user":{"login":"mfoltzgoogle","id":1910312,"avatar_url":"https://avatars.githubusercontent.com/u/1910312?v=3","gravatar_id":"","url":"https://api.github.com/users/mfoltzgoogle","html_url":"https://github.com/mfoltzgoogle","followers_url":"https://api.github.com/users/mfoltzgoogle/followers","following_url":"https://api.github.com/users/mfoltzgoogle/following{/other_user}","gists_url":"https://api.github.com/users/mfoltzgoogle/gists{/gist_id}","starred_url":"https://api.github.com/users/mfoltzgoogle/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mfoltzgoogle/subscriptions","organizations_url":"https://api.github.com/users/mfoltzgoogle/orgs","repos_url":"https://api.github.com/users/mfoltzgoogle/repos","events_url":"https://api.github.com/users/mfoltzgoogle/events{/privacy}","received_events_url":"https://api.github.com/users/mfoltzgoogle/received_events","type":"User","site_admin":false},"created_at":"2016-04-18T20:31:31Z","updated_at":"2016-04-18T20:31:31Z","body":"Reviewing this thread in light of our desire to publish a Candidate Recommendation for the Presentation API.\r\n\r\nSome background: I reached out a while ago to blink-dev@ and got feedback that indeed, the lang= does influence font selection when rendering. [1]\r\n\r\nIt sounds like there are two distinct issues that we may want to address with specification language.\r\n\r\n1.  When a user requests presentation, the receiving browsing context SHOULD apply the language settings of the controlling browsing context, so that when the receiving user agent fetches resources for the presentation an appropriate HTTP `accept-language` header is set.  (This is not a requirement, as the controller could also append a locale (BCP47) tag to the presentation URL passed to the server for language-specific resources.)\r\n\r\n2. When a human-presentable string is passed from the controller to the receiver (or vice versa), the application MAY want to include a locale tag describing the preferred display language for the string to assist the browser with font selection.   The page would be responsible for taking this locale and setting the lang= tag on the appropriate element rendering the string.\r\n\r\nIn the scope of the current Presentation API, I believe item 1 would be included as guidance for implementors and 2 as guidance for authors.  I can craft a PR along these lines.\r\n\r\nBoth 1 and 2 would certainly be features that we could include in a forthcoming presentation control protocol.\r\n\r\n[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/7O6NPCuVWlo/1CwqmrQ4AQAJ"}}