Comment by robocat | Hacker News Reader

Comment by robocat | Hacker News Reader

Parent Full thread

SharedWebWorker is another browser feature I hadn’t heard of.

One minor niggle for your friend re: “To not pollute the DOM, neo.mjs is sticking to global event listeners. E.g. there is just 1 click listener on the document body node.”

That is a problem on Mobile Safari (I know Safari isn’t supported but...). For Mobile Safari registering an onclick event on say a img affects the touch zones of adjacent controls (and also turns on tap highlighting). Say you place an img of a ▼ adjacent to an input. The ▼ needs its own onclick handler, otherwise a tap on the img near the input gets shifted to the input (causes the focus to shift to the input.) Tap zones for inputs are larger than the actual boundary of the input element.

I should have phrased it like: "by default neo.mjs is using global listeners" => you can add local listeners as well if you want to.

regarding safari: https://caniuse.com/#search=worker

workers are supported, so the dist versions not using shared workers can run there already.

2 missing items on the webkit side:

1) adding support for shared workers (they dropped the development on those, but recently put it into "inRadar" again. So there is hope.

2) adding support for JS modules inside the worker scope. missing in FF as well. not too bad, since it is good enough in case 1 browser can do it (chrome) so that the dev mode can run there. the dist versions will run in FF, safari & chrome, since webpack is replacing all import statements, so that there are no real JS modules.

to fully support mobile, neo.mjs still needs to support touch events (similar to hammer js). on the todo list.

> neo.mjs still needs to support touch events

For taps, I recommend you always use the click event. Faking tap events using touch events causes a variety of problems beyond the one I mentioned (unnatural feel, scroll cancelling a tap, taps on foreground popovers, allowable finger movement and still tap varies by platform, accessibility, automated testing).

for the default tap event, this sounds right.

for "longtap" we probably have to stick to touchstart & end though. not sure about doubletap yet.

Reply on news.ycombinator.com