3 ms·

> where click handlers for <a> elements None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root

> where click handlers for <a> elements None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation. In terms of autoplay, a trick we have to play for iOS is, when you click on something we play a 0.25 second silent MP3 through the audio element. Once that's done, it's "active" and we can use it to play audio. It's a radio "boombox" type application, so this feature is expected by our users to keep audio playing when they navigate to different features within the player.

caditinpiscinam 3y ago
That makes sense for an audio-player application -- something like Spotify where the user expects playback to continue when navigating pages. Even so, I rely on the fact that Spotify links are actual links, so that I can open multiple tabs when I need to, for example when putting together a complicated playlist. Have you considered keeping <a> links as a fallback to support this sort of use-case?
MrJohz 3y ago
> None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation. This breaks a lot of navigation features though, right? For example, middle click or control click to open in a new tab, hovering to see where the link will take you, right clicking to save, copy, or share a link, etc. Why not just have them be anchor elements with hrefs that refer to the URL that you'll be using the history state with? You can still listen to the click events and perform the required history updates and navigation when that occurs, but if the user interacts with that link outside of just clicking it, it'll behave as they expect. Depending on how your navigation works, this could well be less work overall - this has certainly been my experience with similar projects.

caditinpiscinam 3y ago

That makes sense for an audio-player application -- something like Spotify where the user expects playback to continue when navigating pages. Even so, I rely on the fact that Spotify links are actual links, so that I can open multiple tabs when I need to, for example when putting together a complicated playlist. Have you considered keeping <a> links as a fallback to support this sort of use-case?

MrJohz 3y ago

> None of our SPAs use <a> elements for clickable navigation. In fact, most of them attach a click listener to the root element, then let the individual clicks bubble up to there. We use data parameters on the individual elements, and if the click handler sees one of those, then it activates the history state/navigation. This breaks a lot of navigation features though, right? For example, middle click or control click to open in a new tab, hovering to see where the link will take you, right clicking to save, copy, or share a link, etc. Why not just have them be anchor elements with hrefs that refer to the URL that you'll be using the history state with? You can still listen to the click events and perform the required history updates and navigation when that occurs, but if the user interacts with that link outside of just clicking it, it'll behave as they expect. Depending on how your navigation works, this could well be less work overall - this has certainly been my experience with similar projects.