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 support@pausly.app?

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.

You are very mistaken if you think that I wish for JavaScript to die. It is neither my wish nor my forecast. I just hope that other languages will make it into the browser at one time.

"overly-clever"? Not sure about that... BrowserScript seemed to fit. I didn't expect to get whipped that much over it. Maybe I'll just change it back to JavaScript and add a note that this can be applied to any other browser side language. I don't quite see what the big fuss is though, to be honest.

In my opinion, Dart is the first browser side language, that has any possibility of changing this monopoly. I don't think that it's a good thing that JavaScript is the only language you get in the browser, but that has nothing to do with dogma (I coded a lot in JavaScript, and it has it's place).

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.

In all fairness, I stated "hopefully". I agree that it is more wishful thinking than reality. It just seemed strange to me to call "BrowserScript" JavaScript, since it should not be limited to JavaScript in my opinion.

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.

Loading the content resources with AJAX allow you to preserve the current UI state. Depending on your website and your needs this step might be completely unnecessary.

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.