enyo

A short introduction to Swift for web developers. It's not meant to be a learning resource, but highlights some of Swift's features and language decisions that are interesting coming from web development.

Learn how you can reap the benefits of TypeScript and still write plain JavaScript.

A short introduction on how to use JSDoc to type your JavaScript, and when it’s useful to use it instead of TypeScript.

Thanks! Could you please tell me if this is still happening (make sure to reload first) and if so, would you mind sending me the email address you used for signup to [email protected]?

You didn't actually say anything other than that it's bad and not to use on production. Care to elaborate?

The use of this symbol in the article is a placeholder. Obviously nobody would actually use this on their website...

Unfortunately there are still plenty of issues with the details element, especially around accessibility. Read more here: https://cloudfour.com/thinks/a-details-element-as-a-burger-m...

Hopefully this will change soon. I’ll amend the article when this will be the case.

This would be way too frustrating to me :)

Mh.. yes I agree. "Expand menu" and “Collapse menu" is probably a better wording.

Oh you’re right, I forgot to add this in the article + codepen. (It’s how the button on the site itself is implemented and I forgot to integrate it)

> "but it did not become 'de facto' on small screens decades ago”

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 :)

I never said that it did.

> Screen reader users do not need to open or close menus.

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?

That’s why the anchor gets the role=“button”. Unfortunately you can’t set the target of the page with a button (without JavaScript), that’s why an anchor link is used.

The icon was designed and introduced in 1981. The popularity dramatically increased in the last decade due to smartphones that’s for sure.

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.

Thanks for letting me know! Seems to happen because it’s not a high dpi screen. I’ll get on it.

That is a terrible user experience for SSR though and will lead to a layout shift every time the page is loaded.

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.

Which image (and which browser)?

Learn how to create an accessible hamburger button with pure HTML and CSS and why that is important.

Yup. Built with Svelte & Supabase.

That's the plan :) It currently links to Telegram, but next up is Slack integration.

I'm currently building a service for exactly this. It's still in Alpha but it allows you to take short 4-5min breaks with friends (+ voice chat) with instructed stretches + strength exercises. https://www.pausewith.me

As I said, still in Alpha, but I'm always happy for constructive feedback.

I thought that Josh Wardle found a great way to incentivise playing the game on a daily basis and thought that combining this with something useful like ear training would be a perfect fit.

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.

Because Dart is similar to JS, easy to learn, and better in regards to performance, tools and security. JS is a mess, just look at the equality operators and the fact that you can manipulate classes like String, etc...

Thank you.