Match browser implementations (e.g. １)

[mathiasbynens]

@annevk reported this one.

[13:19] <annevk> matjas: you around? saw that １ turns into some Punycode string per http://mothereff.in/punycode but no browser does that, not even Opera  
[13:20] <annevk> matjas: so if that's IDNA2008... well... 

http://mothereff.in/punycode#%EF%BC%91.com

AFAICT, that’s just the Punycode algorithm doing its thing. I guess browsers normalize the input first?

[annevk]

So I think you guys are good as far as the Punycode algorithm is concerned. But there's a bunch of pre-processing that's unclear and differs slightly between browsers. Trying to sort it out.

[mathiasbynens]

Another example: http://mothereff.in/punycode#%E2%84%81.vagosec.org http://℁.vagosec.org/ / http://xn--01g.vagosec.org/

Let’s wait until http://url.spec.whatwg.org/#concept-host-parser is complete. Ref. http://wiki.whatwg.org/wiki/URL#IDNA.

[mathiasbynens]

http://url.spec.whatwg.org/#concept-domain-label-to-ascii

[mathiasbynens]

web-platform-tests/wpt#4504 (comment)

[annevk]

I guess maybe this isn't as important for this library if other libraries are writing the ToASCII logic on top... Depends a bit on what you're aiming for and what users expect I suppose.

[mathiasbynens]

punycode.toASCII was altering ASCII-safe input strings: #59 This has been fixed in v2.1.0. 👍