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?
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?
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).
Please elaborate, and please be kind. These are basic features of CSS, not hacks, but we could all stand to learn more about accessibility and usability.
@joshichinmay check out the CSS-Tricks link in the post. It has a long discussion about the accessibility of this approach, both in the main content and the comments.
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?
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?
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...
Very cool. I like to do stuff without taking any help of JavaScript.
CSS is very powerful. Thanks for sharing this.
CSS was not made for that. Using these hacks can put you inside a tunnel of accessibilities and usability issues
Please elaborate, and please be kind. These are basic features of CSS, not hacks, but we could all stand to learn more about accessibility and usability.
Hey @equinusocio , I am just saying its very beautiful how you can create things with CSS, without using any JavaScript.
Can you tell me how it can cause issues? I would love to learn more about it!
@joshichinmay check out the CSS-Tricks link in the post. It has a long discussion about the accessibility of this approach, both in the main content and the comments.
Hey, thank you. :)
...and not the first to do it. Steve Gibson does it here for a few years now.
grc.com/menudemo.htm