- From: <bugzilla@jessica.w3.org>
- Date: Tue, 05 Aug 2014 09:25:31 +0000
- To: www-international@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646 --- Comment #47 from Henri Sivonen <hsivonen@hsivonen.fi> --- (In reply to Simon Pieters from comment #46) > Examples of pages that break if us-ascii label doesn't encode as > windows-1252 for URL query component or <form> submission: Thank you! Can we now resolve this as WONTFIX, please? (In reply to Henri Sivonen from comment #45) > For example, the API should refuse to give you an encoder for "us-ascii" to > force you to resolve the label "us-ascii" to windows-1252 first and then > request and encoder for that. Once you've had to resolve the label to the > encoding anyway, you should then use the canonical name of the encoding when > labeling the outgoing data. FWIW, as real-world existence proof of API of this nature, the Gecko-internal API for obtaining a decoder and the Gecko-internal API for obtaining an encoder take encodings--not labels. If a label is what you have, you have to to first call a method that resolves a label into an encoding. (It's unfortunate, though, that Gecko represents both encodings and labels as strings of 8-bit code units instead of representing encodings either as an enumeration or aas singleton objects inheriting from an abstract class. When properly designing a new API, you should not use strings to represent encodings.) The introduction of this API has already exposed a bug in SeaMonkey. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 5 August 2014 09:25:33 UTC