I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Another accessibility problem with hover-to-open is that touch devices sometimes emulate that with a long-press but you can't rely on it.
I'm not a fan of adding spurious markup to handle something cosmetic; adding a checkbox to a page that has no semantic purpose bothers me.
I wonder why you're avoiding Javascript? Is it just an exercise or is it because you want to support users who can't (or won't) run your script? If the former, fair play, but if the latter, then why not just make the menu visible in the first place?
Yes, I intentionally left aria attributes off to keep the examples readable (hence my warning at the end). Can you elaborate on what you mean about states, though?
Developers should use ARIA states to indicate the state of UI widget elements and use CSS attribute selectors to alter the visual appearance based on the state changes (rather than using script to change a class name on the element).
Thanks for the feedback! I agree about the problems with hover. That's why I used the click-to-open version.
Adding a checkbox to a page that has no semantic purpose bothers me.
I would argue that it has a semantic purpose. It is an element that clearly communicates its function, which is to open and close a menu. You might as well say a button has no semantic purpose.
I wonder why you're avoiding Javascript?
Let's flip that around: Why would I use JS for something that is this easily accomplished in a few lines of CSS? Common JS approaches often either:
add inline styles (not ideal, and sometimes disallowed by CSP)
add/remove classes, creating three-way coupling between the HTML/CSS/JS. Avoiding JS is simpler and has looser coupling.
Why not just make the menu visible in the first place?
This question makes no sense to me. I wanted a dropdown menu for the same reasons everyone does, why question that choice based on how I code it?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Another accessibility problem with hover-to-open is that touch devices sometimes emulate that with a long-press but you can't rely on it.
I'm not a fan of adding spurious markup to handle something cosmetic; adding a checkbox to a page that has no semantic purpose bothers me.
I wonder why you're avoiding Javascript? Is it just an exercise or is it because you want to support users who can't (or won't) run your script? If the former, fair play, but if the latter, then why not just make the menu visible in the first place?
Another issue is accessibility. Browser and e-readers doesn’t recognise this as dropdown list since it lacks of aria attributes and states
Yes, I intentionally left aria attributes off to keep the examples readable (hence my warning at the end). Can you elaborate on what you mean about states, though?
Ui component states should be defined with aria attributes.
developer.mozilla.org/en-US/docs/L...
developer.mozilla.org/en-US/docs/W...
Thanks for the feedback! I agree about the problems with hover. That's why I used the click-to-open version.
I would argue that it has a semantic purpose. It is an element that clearly communicates its function, which is to open and close a menu. You might as well say a button has no semantic purpose.
Let's flip that around: Why would I use JS for something that is this easily accomplished in a few lines of CSS? Common JS approaches often either:
This question makes no sense to me. I wanted a dropdown menu for the same reasons everyone does, why question that choice based on how I code it?