site
site copied to clipboard
python-discord
Unable to toggle "More" on navbar without long-press on Safari
It's a rather weird and annoying issue that I have been experiencing for a few years.
On my iPad I can't get the "More" navbar-link item to show the dropdown, unless I long-press the word, which selects the More text, then the dropdown displays. After it is shown I can only hide it again after pressing a link. (Tapping in an empty space also fails to close it.)
Since we use Bulma I've tested this with the same device and browser on their live demo: https://bulma.io/documentation/components/navbar/ I am able to open and close the "More" dropdown item with no issues by simply tapping.
Using an iPad with Safari in full screen (landscape) so that "More" is shown rather than the hamburger menu icon. This is not an issue in Chrome.
Note that this is also not an issue if the screen width is small enough to make the navbar items hide away. Tapping on the hamburger menu icon works as expected.
The reason I open an issue here is because if Bulma works, our site should ideally work as well. And if a user visits the website with a similar device + browser the site can become a little annoying to navigate without the navigation links.
UPD: This is not an issue for the content pages with a Sub-articles dropdown.
After diving deeper into it, it turns out that it's a quirk of iOS/iPadOS + Safari. This SO question has a few solutions that worked perfectly for me: https://stackoverflow.com/questions/18047353/fix-css-hover-on-iphone-ipad-ipod
- With javascript
<script>
document.addEventListener("touchstart", function() {},false);
</script>
- Add tabindex to body
<body tabindex=0>
- HTML ontouchmove
<html ontouchmove>
These are the only solutions that worked through my testing. I'm not sure why 1) This codepen and Bulma's examples work without any "hacks", and 2) The pages that includes a Sub-articles dropdown also do not have this problem (it appears as though the existence of this other non-hoverable dropdown fixes the hoverable "More" dropdown on the navbar).
Note also that if I make the Sub-articles dropdown hoverable (and optionally also drop the bulma-dropdown dependency (only Sub-articles depends on it)), then the Sub-articles dropdown also have the same issue. Once I add one of the three solutions from Stack Overflow listed above, both the "More" and "Sub-articles" dropdowns both work perfectly.
Unfortunately, I couldn't find a way to reproduce this without using an iOS device + Safari explicitly.
I guess most users would not experience this issue, but as someone who uses the setup to browse pydis 99% of the times, it's been quite annoying. Is this too "hacky" to fix, or could I get a core dev approval for this issue so I can PR one of the solutions?
I think these are fine fixes. Personally I would prefer ontouchmove since it seems to be pure HTML?
Yes, I also prefer HTML solutions 👍
Seems like I forgot to add that, the second and third solutions included comes from this answer which also notes that:
TabIndex is the only one that works when Javacript is disabled.
The tabindex attribute is the standard way to make otherwise unresponsive HTML elements
:focus-ableand:hover-able.
Oh I was wondering about that, since ontouchmove sounded like it was something that invoked JS! I think tabindex is the best solution then, especially if it's the "standard way"
especially if it's the "standard way"
It's the standard way to do what it does, though I don't think it's any less hacky than the other solutions to solve this issue, since it's still not obvious why it fixes the issue (not a complaint about using it, just pointing it out).
My only question about using tabindex is if it has any other unwanted effects. It sounds like it should make the whole body of the page selectable through using tab, which doesn't sound ideal. In that case, ontouchmove, which seems like it should be a noop as far as standards are concerned may be nicer to use. I've not tested anything though.
My only question about using tabindex is if it has any other unwanted effects. It sounds like it should make the whole body of the page selectable through using tab, which doesn't sound ideal.
I was also concerned about this, but during testing I wasn't actually able to see any visual effects of having the body selected.
That said, setting tabindex="-1" also fixes the problem, and makes it so it can't be selected using tab.
Using tabindex="-1" sounds good. Super weird that any of these fixes do anything but if it works it works 😄
Web dev seems to be full of these things. 😄 Well I'm glad we finally have a fix for this issue that bugged me for quite a while.