Bookmark swipe UI is preventing access to transliteration tooltips

[seanmturley]

Description

This is a crucial bug - on mobile it's no longer possible to access the transliteration tooltips with a tap. This is because the swipe handling layer on top is intercepting touch events.

[seanmturley]

It looks like this issue is difficult/impossible to resolve if maintaining the current approach of an overlay with the swipe listeners. See this open issue: Click or tap through swipeable component.

Moving the overlay to the margin(s)

Instead of having a full screen swipe overlay, the overlay could be positioned to cover only the left margin of the page (or both margins). This would mean swiping has to start right at the very edge of the screen to add/remove bookmarks.

Edit: This actually isn't a practical solution, since Chromium browsers interpret swipes from the left or right sides as back or forward directives respectively.

Removing the overlay

Moving the swipe event listeners to the parent element of the text resolves this issue, as the overlay no longer blocks the swipe, and events can bubble up through the HTML hierarchy as expected.

So, can the swipe overlay be removed? It was added during the initial implementation (#27) to provide an easy method of disabling the swipe interface on larger screens (with a media query and display: none;).

The trackMouse: false config option gets part of the way there, by allowing swiping only for touchscreen devices. However, there will be some overlap in screen size between large tablet devices and small windows on a desktop device - this overlap makes it difficult to present the correct UI modality for the device if relying solely on the trackMouse feature and screen width media queries.

The hover media query provides the opportunity to separately target devices relying on touch or mouse input. This would allow:

• Mouse pointer devices: Always hover UI for bookmarks for any width > 480px. Smaller screens than that are awkward, but also not very likely to be used - it may still be possible to squeeze the hover interface into the left margin, or alternatives could be explored such as add a small hover icon inline at the end of each paragraph.
• Touch devices: Always swipe UI for any width. This will require a rework of the CSS for larger screens so that the line width isn't too extreme.

[seanmturley]

As a solution to the main problem, the bookmark swipe overlay has been removed, with the swipe event listeners instead being attached to the outer container of Bookmark (i.e. div.line).

As described above, this will require a slightly different approach to responsive CSS that considers not only screen width, but also device type via the hover media query. A new issue (#38) has been raised to deal with the implementation of this styling.