- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Fri, 27 Jun 2014 04:30:04 +0000
- To: Zack Weinberg <zackw@panix.com>
- CC: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, Anne van Kesteren <annevk@annevk.nl>
I did some tests by inserting control characters into DOM directly, so that we could split encoding issues from rendering issues. The test is here[1] if you want to see by yourself, but in short, 0x80-0x9F is handled at encoding layer and therefore we don�t have to worry about in CSS Text. A few issues were found by the test, but it�s a different topic. So I think we do not require any changes to the spec on this point. Please let us know if any. In case you�re interested in the test results, in terms of rendering: * IE11 does not render Cc except 0x0B. * Firefox (Win/Mac), Chrome (Win/Mac), Safari does not render Cc at all. In terms of letter-spacing: * IE11 and Firefox (Win/Mac) applies letter spacing to Cc. * Chrome (Win/Mac), Safari does not apply letter spacing to Cc. [1] http://jsbin.com/quciq/ /koji On May 11, 2014, at 7:17, Zack Weinberg <zackw@panix.com> wrote: > On Sat, May 10, 2014 at 6:07 PM, fantasai <fantasai.lists@inkedblade.net> wrote: >> On 03/20/2014 02:11 PM, Zack Weinberg wrote: >>> For compatibility with legacy content naively converted to UTF-n, >>> U+0085 (and, indeed, the entire C1 controls block) need to be >>> interpreted as graphic characters per Windows-1252, instead of as >>> control characters. >> >> Should this be handled at the render layer or at the encoding layer? > > I believe HTML5 does this at the encoding layer, so we should do the > same. (Also, as far as I know, all characters encoded by Windows-1252 > but not ISO-8859-1 do have Unicode equivalents.) > > zw >
Received on Friday, 27 June 2014 04:30:41 UTC