3 ms·
That would be an accessibility nightmare.
by microcolonel 6y ago
That would be an accessibility nightmare.
- laszlokorte 6y agoWhy exactly? Indeed I have not thought about every detail but as I see it: - pushState is only used for overriding the default behavior, mostly to keep the url bar in sync with changing client state - pushState pollutes the browsers history - users have a mental model of how many steps/clicks they performed on a site and expect that an equal number of clicks on the back button brings them back to the beginning - users are upset if that expectation is not matched The site should not have control over the users history in the first place but for SPA it's necessary to achieve the expected behavior. But the browser should make sure that it's not misused. In the same way that pop-ups are blocked outside of whitelisted event listeners to prevent a website from polluting your screen, pushState should be blocked to prevent history pollution.
- thayne 6y agowell, limiting it to just click events won't work if you navigate using the keyboard, or voice commands.
- laszlokorte 6y agoWell as you can say the same for popup windows which should work for keyboard navigation and voice commands as well, I assume there is a defined class of events that count as active user interaction and I assume that onload, mousemove and onresize do not fall in that category but click, keypress do. Anyway if you focus a button and press it by hitting the spacebar or enter key a javascript click event is triggered as well. So even if you would limit it to click events I guess it would for a large portion of keyboard navigation as well.
- avianlyric 6y agoI think it’s reasonable to assume that’s GP meant any user interaction. Reminder from the HackerNews guidelines > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.