559 karma · joined February 20, 2013
Hopefully this will change soon. I’ll amend the article when this will be the case.
To me saying that something becomes something over a few decades doesn’t imply that it has been that way from the beginning. It has become a de facto standard over two decades doesn’t mean that it was a de facto standard two decades ago.
I feel like this is really not important, and I’ll change it to the last decade because it doesn’t matter. It’s definitely true that the adoption was most relevant in the last decade. I remember building hamburger menus over 20 years ago though.
What is more important is your second point that I sort of endorse hamburger buttons as a good UI element choice with this introduction. To me, this introduction was not meant to be controversial in any way. I believe that hamburger buttons are one of the most recognisable UI elements, and I don’t think that companies like Apple would use them without doing their homework.
That being said, it was not my intent to promote them as such. I didn’t do any profound research on the topic, and this article is not meant for user interface designers, but for developers that want or need to implement such a button because it either fits their use case or because the designers made the decision.
I’ll amend the intro to be more careful in the wording.
You came in a bit hot with your initial comment, but thanks for your feedback :)
Agreed, but you don’t want keyboard accessible menu items available for users that aren’t visually impaired. Offering a “show menu” button to screen readers is not less accessible to them than skipping the navigation section.
If you’re building a page that is only meant to be used by screen readers, then you are absolutely right.
> Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.
The main menu? Which is behind the same ≡ button on most pages on the internet?
It’s used by Microsoft, Apple, Youtube... the list goes on. I think it’s not too much of a stretch to say that it is ubiquitous and familiar to users.
That being said, it's not the point of the article. There are definitely reasons not to use a hamburger button. But this article helps you build one if you want it.
I wouldn’t really call this a CSS “hack” either. There is a checkbox that defines whether the menu is open, and CSS that styles the menu accordingly. I think that this is rather elegant really.
As soon as the :has pseudo class has widespread support, the checkbox can also just live inside the nav element, which removes the awkward general sibling combinator.
As I said, still in Alpha, but I'm always happy for constructive feedback.
I decided to deviate from the Wordle concept a bit because I realised that simply copying the concept didn't make that much sense given that there are only 12 notes (7 in easy mode). It would have been too easy to solve the melody without even listening to it.
The project is written in Svelte + Svelte Kit.
As stated below, I will probably remove this Introduction, since it seems to distract from what this article is about. I hope you consider reading the article anyway.
I will probably remove that statement though, since a lot of people seem to have extremely strong feelings about that, and are distracted from what this article is actually about.
It becomes necessary when you have elements that you want to persist on your page. That might be an audio player or the state of a menu that you want to avoid painting.
It's just about a better UX for your users.