- From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
- Date: Fri, 20 Jan 2012 23:58:52 +0800
- To: Mathias Bynens <mathias@qiwi.be>
- CC: WWW Style <www-style@w3.org>
(Cc+ www-international) (12/01/20 21:57), Mathias Bynens wrote: > Ok so what’s the status here? Should we file bugs with all browsers except > Firefox, asking to fix this? Does the spec need amending? Do you have reasons to use the "composing two code points to one trick" besides the fact WebKit doesn't support 6 digits decimal? I go for amending, although I can sort of imagine the trick being easier to use because this is what you get if you query the identity of that character from JavaScript and doing the 2 * UTF-16 code units → Unicode characters math isn't that easy. If we are to go to Firefox's direction, I propose a simple fix like this: # If the number is outside the range allowed by Unicode (e.g., "\110000" is above the maximum 10FFFF # allowed in current Unicode), the UA may replace the escape with the "replacement character" (U+FFFD). to | If the number is outside the range allowed by Unicode (e.g., "\110000" is above the maximum 10FFFF | allowed in current Unicode) or the character this number represents can not be stored in the UA (e.g. | surrogate characters can't be stored in a UA that uses UTF-16 as the internal encoding for characters), | the UA may replace the escape with the "replacement character" (U+FFFD). although it seems to be better it this is a 'should' or a 'must' instead of a 'may'. I don't know if characters in ISO 10646 means a Unicode code point or a Unicode character. If it means the latter, the prose needs to change to match that (i.e. s/above the maximum 10FFFF/above the maximum 10FFFF or in between D800 to DFFF/ ) Cheers, Kenny
Received on Friday, 20 January 2012 15:59:21 UTC