3 ms·

I would append 'unless you do it really well' to a lot of these statements. In fact, I bet you use websites on a daily basis that do many of these, but you don'

I would append 'unless you do it really well' to a lot of these statements. In fact, I bet you use websites on a daily basis that do many of these, but you don't even notice because they do it well. You only notice those who do it badly. Except for stealing the back button. There's a special hell for any dev who does that.

ori_b 6y ago
Yeah. With a lot of time and effort, you can get a result that's so good, it's indistinguishable from not doing anything special at all.
deleted 6y ago
[deleted]
mwcampbell 6y ago
The problem is that you can do it well enough that no one using a browser in the normal way would notice, but people doing things differently, whether by necessity (e.g. because of a disability) or preference, would still notice.
a1369209993 6y ago
No, it's especially if you do it really well, because then it takes longer for people to realize it's broken.
chrismorgan 6y ago
Trouble is that many of these things are impossible to do correctly. Taking some of the items in the list quoted: • Scrolljacking. The web doesn’t provide the APIs necessary to synthesise the effect of scrolling from mouse events. • Context menu behaviour: a tricky one, because there are some web apps where it seems reasonable and useful to provide your own context menu, but where it is conceivable that items in the native context menu may be desirable also. There’s no winning move here. There was a web API to handle this properly, where you could add items to the native context menu (<menu type=context>), but only Firefox has implemented it (and the writing is on the wall for it). I have no idea why the others have scuttled this seriously useful functionality. • Custom combo boxes: there’s a baseline of functionality (which most custom combo box widgets don’t cover properly anyway…), but beyond that each platform has its own subtleties that are not exposed in any way. If you truly want a custom combo box to feel native, you’ll need to sniff the platform and special-case. This leaves you open to getting things wrong in quite a few ways. • Custom scrollbars: all the relevant APIs are async and these days typically debounced a tad, so that it’s simply not possible to guarantee that your custom scrollbar will match the scroll container on every frame—and in almost all cases it will be delayed by at least one frame. (For the rest it is possible to do a flawless job. But it’s generally a much better idea to just not fiddle with things. I say this as someone who has made complex custom input controls and made sure they’re as close to perfect as is technically feasible without platform specialisation, but who definitely prefers to keep things simple. Oh, and I hate scrolljacking unconditionally.)

ori_b 6y ago

Yeah. With a lot of time and effort, you can get a result that's so good, it's indistinguishable from not doing anything special at all.

deleted 6y ago

[deleted]

mwcampbell 6y ago

The problem is that you can do it well enough that no one using a browser in the normal way would notice, but people doing things differently, whether by necessity (e.g. because of a disability) or preference, would still notice.

a1369209993 6y ago

No, it's especially if you do it really well, because then it takes longer for people to realize it's broken.

chrismorgan 6y ago

Trouble is that many of these things are impossible to do correctly. Taking some of the items in the list quoted: • Scrolljacking. The web doesn’t provide the APIs necessary to synthesise the effect of scrolling from mouse events. • Context menu behaviour: a tricky one, because there are some web apps where it seems reasonable and useful to provide your own context menu, but where it is conceivable that items in the native context menu may be desirable also. There’s no winning move here. There was a web API to handle this properly, where you could add items to the native context menu (<menu type=context>), but only Firefox has implemented it (and the writing is on the wall for it). I have no idea why the others have scuttled this seriously useful functionality. • Custom combo boxes: there’s a baseline of functionality (which most custom combo box widgets don’t cover properly anyway…), but beyond that each platform has its own subtleties that are not exposed in any way. If you truly want a custom combo box to feel native, you’ll need to sniff the platform and special-case. This leaves you open to getting things wrong in quite a few ways. • Custom scrollbars: all the relevant APIs are async and these days typically debounced a tad, so that it’s simply not possible to guarantee that your custom scrollbar will match the scroll container on every frame—and in almost all cases it will be delayed by at least one frame. (For the rest it is possible to do a flawless job. But it’s generally a much better idea to just not fiddle with things. I say this as someone who has made complex custom input controls and made sure they’re as close to perfect as is technically feasible without platform specialisation, but who definitely prefers to keep things simple. Oh, and I hate scrolljacking unconditionally.)