HNHacker News
TopNewBestAskShowJobs

enyo

559 karma · joined February 20, 2013

Projects: https://www.dropzone.dev https://www.yesmeno.com https://www.pausewith.me https://www.colorglare.com
submissionscomments
enyo··on [dead]
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.
enyo··on [dead]
Learn how you can reap the benefits of TypeScript and still write plain JavaScript.
enyo··on [dead]
A short introduction on how to use JSDoc to type your JavaScript, and when it’s useful to use it instead of TypeScript.
enyo··on Accessible hamburger buttons without JavaScript
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?
enyo··on Accessible hamburger buttons without JavaScript
You didn't actually say anything other than that it's bad and not to use on production. Care to elaborate?
enyo··on Accessible hamburger buttons without JavaScript
The use of this symbol in the article is a placeholder. Obviously nobody would actually use this on their website...
enyo··on Accessible hamburger buttons without JavaScript
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.

enyo··on Accessible hamburger buttons without JavaScript
This would be way too frustrating to me :)
enyo··on Accessible hamburger buttons without JavaScript
Mh.. yes I agree. "Expand menu" and “Collapse menu" is probably a better wording.
enyo··on Accessible hamburger buttons without JavaScript
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)
enyo··on Accessible hamburger buttons without JavaScript
> "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 :)

enyo··on Accessible hamburger buttons without JavaScript
I never said that it did.
enyo··on Accessible hamburger buttons without JavaScript
> 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?

enyo··on Accessible hamburger buttons without JavaScript
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.
enyo··on Accessible hamburger buttons without JavaScript
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.

enyo··on Accessible hamburger buttons without JavaScript
Thanks for letting me know! Seems to happen because it’s not a high dpi screen. I’ll get on it.
enyo··on Accessible hamburger buttons without JavaScript
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.

enyo··on Accessible hamburger buttons without JavaScript
Which image (and which browser)?
enyo··on Accessible hamburger buttons without JavaScript
Learn how to create an accessible hamburger button with pure HTML and CSS and why that is important.
enyo··on A little exercise each day improves muscles more than one big weekly workout
Yup. Built with Svelte & Supabase.
enyo··on A little exercise each day improves muscles more than one big weekly workout
That's the plan :) It currently links to Telegram, but next up is Slack integration.
enyo··on A little exercise each day improves muscles more than one big weekly workout
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.

enyo··on Show HN: Melodle – Guess the melody in 6 tries (Wordle offshoot)
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.

enyo··on Flutter will change everything, and is an excellent choice for iOS development
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...
enyo··on Stop writing stateful HTML
Thank you.
enyo··on Stop writing stateful HTML
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.
enyo··on Stop writing stateful HTML
"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.
enyo··on Stop writing stateful HTML
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.

enyo··on Stop writing stateful HTML
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.

enyo··on Stop writing stateful HTML
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.

Page 1 of 2Next →