That may be a standard thing to do with unicode in domain names, run it through the standard unicode denormalization first? Understanding what browsers are "supposed" to do with unicode in domain names (and URLs generally) is very confusing for me.
I would be curious to learn more about what standards govern how browsers handle unicode in domain names, the history of it, how compliant browsers are, etc. I also don't entirely understand the goal here -- the original `Ⅷ.fi` isn't actually only two bytes in any encoding... what is the value of having something that shows up as two "glyphs" even though it's more bytes and denormalizes to something else with a yet different number of bytes?
Internationalized Domain Names (IDN) FAQ (https://unicode.org/faq/idn.html)
Unicode® Technical Standard #46: UNICODE IDNA COMPATIBILITY PROCESSING (https://www.unicode.org/reports/tr46/)
Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale (http://tools.ietf.org/html/rfc5894)
Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework (http://tools.ietf.org/html/rfc5890)
Internationalized Domain Names in Applications (IDNA) Protocol (http://tools.ietf.org/html/rfc5891)
The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) (http://tools.ietf.org/html/rfc5892)
Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) (http://tools.ietf.org/html/rfc5893)
Since browser already turns it into ascii format before resolving, how would it work in XSS for server-side max length limitation as he mentioned in his other article, "Minimum Viable XSS" [1]?