- 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