undefined | Better HN

0 pointstomxor5y ago0 comments

I can only speculate as to why because it's safari which i don't have. If the eval is throwing an exception it's probably something to do with the unicode encoding that packs 2 ASCII chars into each UTF16 surrogate pair - the second one ultilises slightly more of the 20bits available and some UTF16 implementations/interfaces are buggy.

You could replace 'eval' with 'throw' and see if the output looks like sane JS

0 comments

3 comments · 1 top-level

bronson5y ago· 2 in thread

Output from iphone 11 seems to confirm your theory: https://dpaste.com/GU8A3X4H7#wrap

tomxorOP5y ago

Hah, actually that code is correct (Although I realise it probably looks like gobbledygook :D) so it disproves my theory.

The code is mostly arithmetic, so the only thing I can see which could be implementation sensitive is the canvas fillStyle HSL string, which omits commas and spaces since the % postfixes are enough to delimit the saturation and luminance, but obviously this depends on the canvas interface implementation.

codetrotter5y ago

I looked into it and this turned out to be the problem exactly.

If you change the part of your code where you have

  hsl(${i*120} 99%${K*99}%

To instead

  hsl(${i*120} 99% ${K*99}%

(That is, by not omitting the space after 99%)

Then it works in the versions of Safari that I tested; Safari 14.0.3 on macOS Big Sur 11.2.2 running on a MacBook Pro M1, and Safari on iOS 14.4 running on an iPhone X.

j / k navigate · click thread line to collapse