On 2010-08-26 13:58:24, Julian Reschke wrote:
Not convinced. There's already one way to escape these things, and this is supported in all UAs.
Totally agree. If a web author isn't sufficiently experienced to remember to call an HTML-encoding function, there is no reason to believe they'll think to call a base64-encoding function either. The proposal adds more parsing complexity (and XML incompatibility) for no obvious gain.
However, I'm all for making standardised HTML-encoder/decoder and base64-encoder/decoder functions available at a `window` or ECMAScript language level.
`atob`/`btoa` do the job, but they're byte encoders not characters; they expect 'binary' strings where each charCode is the ordinal value of a byte. That is to say, they `btoa` encodes the input string using genuine-ISO-8859-1 and not UTF-8. This is necessary for a general-purpose base64 implementation (otherwise many base64 strings would not be decodable at all), but may be unexpected.
Is it worth providing a UTF-8-based variant or argument? Otherwise users would have to convert from UTF-8-misdecoded-as-ISO-8859-1 strings manually. (That's not difficult, using `decodeURIComponent(escape(s))`, but this trick isn't obvious or well-known.)
-- And Clover mailto:[email protected] http://www.doxdesk.com/
