(People are less likely to hand-edit them when they move steps around, which is what we want for stable IDs.)
-
-
Replying to @tabatkins
And I guess you're using UTF-16 internally so that makes sense
1 reply 0 retweets 0 likes -
Replying to @qntm
Nah, utf8, but visual weight in the spec source is roughly as important to minimize as transferred page weight.
1 reply 0 retweets 0 likes -
Replying to @tabatkins @qntm
(Given that the spec is huge and nearly all ASCII, using utf16 would be kinda dumb.)
1 reply 0 retweets 0 likes -
Replying to @tabatkins
Then is there any particular reason for not using Base65536? It would yield shorter markers.
1 reply 0 retweets 0 likes -
Replying to @qntm
Only in the limit. We want more than a 6x margin, just in case, so we'd need 2 chars anyway. Also: much less font support.
1 reply 0 retweets 0 likes -
Replying to @tabatkins
Two other comments: (1) Base32768 uses CJK characters which may *not* look like gibberish to CJK readers, particularly in short strings
2 replies 0 retweets 0 likes -
Replying to @qntm @tabatkins
(2) It may not be easy to visually distinguish one Base32768 string from another if you are using them as a "visual checksum"
2 replies 0 retweets 0 likes -
Replying to @qntm @tabatkins
Are there any performance concerns here? That's the one aspect of Base32768 which I put no work into.
1 reply 0 retweets 0 likes -
Replying to @qntm
Nope, this is an offline operation that will mostly happen automatically from the CI build.
1 reply 0 retweets 0 likes
Alright then, just wanted to do my due diligence. I'm glad Base32768 finally meets someone's needs!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.