3 ms·

I really wish developers would just ask themselves if a feature is actually necessary before trying to create it without JS For example, you can make an accord

I really wish developers would just ask themselves if a feature is actually necessary before trying to create it without JS For example, you can make an accordion menu with plain HTML, but should you? Accordions are horrible. They just hide information. 20 years ago an accordion was a design pattern that made a bit of sense - scrolling meant moving the mouse to the scrollbar or pressing Page Down which took you out of the reading flow on the page. Not to mention screens were tiny so a long page didn't work very well. Today though, users can scroll easily with a mouse wheel or a swipe, and screen are much bigger. Just show the text and let the user scroll past it. CSS-derived dark mode is another example of "Yeah, you can, but it's a bit rubbish." The site won't retain the user's choice if you use plain CSS which is pretty horrible. Either use JS, or use your build step to bake two versions and serve them on different URLs like "/dark/page-1" and "/weird-bright-mode-wtf/page-1". The off-canvas menu and sticky bar are quite nice, but again it does feel like developing something that could be better without any clever CSS or JS through sensible design choices.

throwamon 5y ago
On accordions, I'm of the opposite opinion... sort of. I love outliners such as Workflowy and Dynalist. I'd like most textual content to look more like them. It's really great being able to expand/collapse/zoom into entire sections, link from one section to another, etc. You can expand everything with a single command and you should also be able to flatten the tree and read it like a normal page if that's how you like it. Regular pages with accordions are just a poorer version of this. I'd like it to go all the way in that direction.
- franciscop 5y ago
  Could you point to a specific example please? Or screenshot if those are apps. I'm curious about trying some accordion pattern that people actually _like_.
  - throwamon 5y ago
    Sorry, I can't send screenshots right now, but you can easily find some by googling (yes, they're apps). There's nothing much to it, it's just collapsible nested lists. And to be clear, I think most people would be weirded out by a blog post that looked like that. I think making the "flat" view the default one but adding a toggle for a hierarchical view would be the ideal UX for me, but I bet this is a very niche preference and it wouldn't be worth it for a larger audience.
  - tasha0663 5y ago
    What if I told you... (sunglasses) We're in one right now?
    - franciscop 5y ago
      Yes! I thought about it after writing this comment, HN's collapsible comments are one of the best features! But they work the opposite than when you think about an "accordion", where the default is closed and then you can show more info.
mushyhammer 5y ago
> The site won't retain the user's choice if you use plain CSS which is pretty horrible Correct, that's why the suggested solution here is just as bad. "Plain CSS" dark mode just follows your device’s setting via `prefers-color-scheme` @media query. Anything else is just unnecessary and should be suppressed. Just set your whole system once and be done. That "Plain CSS" works perfectly and indeed does not need any JS nor different URLs (wut? who does that.)
- derrikcurran 5y ago
  Some people want dark mode for some things and light mode for others. I don't, but I know people who do.
  - account42 5y ago
    Then those people should use a browser that lets them make that distinction. There is nothing saying that prefers-color-scheme needs to match the rest of the system or needs to be the same for all websites - but it should reflect what the user wants from that particular website so implemention an override on top of that should make no sense.
hnlmorg 5y ago
> 20 years ago an accordion was a design pattern that made a bit of sense - scrolling meant moving the mouse to the scrollbar or pressing Page Down which took you out of the reading flow on the page Scroll wheels were a thing 20 years ago too :) I've been building websites as well as surfing the web for nearly 30 years now and I can honestly say I've never once found the scrollbar or using the arrow keys (which I favored over the Page Down) as jarring to the reading experience like you said it is. Generally you'd just keep one hand hovered over the keyboard button or the mouse cursor on the scrollbar, much like you might keep your finger on the scroll wheel now. If anything, I find swiping on a mobile screen more jarring since it means I have to use both hands (since I'd be holding the phone with one hand), or do some "phone gymnastics" where I try to shift the phone position in my hand enough to slide the screen with my thumb while still holding the phone, and do so without dropping the phone. Which often results in scrolling either too far or not far enough. > Not to mention screens were tiny so a long page didn't work very well. Mobile screens display a lot less text than a webpage did on a 90's 800x600 PC screen. Remember that modern screens will have a higher DPI to make things look smoother. On older screens we just accepted that stuff would look pixelated because that was the state of the art.
lenkite 5y ago
Web pages without JS are web pages that are served faster, render faster and consume considerably less power. Incidentally, the biggest mistake the web 'committee' did was to make a web-components spec that mandatorily requires javascript even for a basic 'hello world' label. That made it strictly a no-go for many domains where HTML/CSS generation/rendering is accepted but JS is not. I am in hard-favour of approaches towards UX components without JS.

throwamon 5y ago

On accordions, I'm of the opposite opinion... sort of. I love outliners such as Workflowy and Dynalist. I'd like most textual content to look more like them. It's really great being able to expand/collapse/zoom into entire sections, link from one section to another, etc. You can expand everything with a single command and you should also be able to flatten the tree and read it like a normal page if that's how you like it. Regular pages with accordions are just a poorer version of this. I'd like it to go all the way in that direction.

franciscop 5y ago
Could you point to a specific example please? Or screenshot if those are apps. I'm curious about trying some accordion pattern that people actually _like_.
- throwamon 5y ago
  Sorry, I can't send screenshots right now, but you can easily find some by googling (yes, they're apps). There's nothing much to it, it's just collapsible nested lists. And to be clear, I think most people would be weirded out by a blog post that looked like that. I think making the "flat" view the default one but adding a toggle for a hierarchical view would be the ideal UX for me, but I bet this is a very niche preference and it wouldn't be worth it for a larger audience.
- tasha0663 5y ago
  What if I told you... (sunglasses) We're in one right now?
  - franciscop 5y ago
    Yes! I thought about it after writing this comment, HN's collapsible comments are one of the best features! But they work the opposite than when you think about an "accordion", where the default is closed and then you can show more info.

mushyhammer 5y ago

> The site won't retain the user's choice if you use plain CSS which is pretty horrible Correct, that's why the suggested solution here is just as bad. "Plain CSS" dark mode just follows your device’s setting via `prefers-color-scheme` @media query. Anything else is just unnecessary and should be suppressed. Just set your whole system once and be done. That "Plain CSS" works perfectly and indeed does not need any JS nor different URLs (wut? who does that.)

derrikcurran 5y ago
Some people want dark mode for some things and light mode for others. I don't, but I know people who do.
- account42 5y ago
  Then those people should use a browser that lets them make that distinction. There is nothing saying that prefers-color-scheme needs to match the rest of the system or needs to be the same for all websites - but it should reflect what the user wants from that particular website so implemention an override on top of that should make no sense.

hnlmorg 5y ago

> 20 years ago an accordion was a design pattern that made a bit of sense - scrolling meant moving the mouse to the scrollbar or pressing Page Down which took you out of the reading flow on the page Scroll wheels were a thing 20 years ago too :) I've been building websites as well as surfing the web for nearly 30 years now and I can honestly say I've never once found the scrollbar or using the arrow keys (which I favored over the Page Down) as jarring to the reading experience like you said it is. Generally you'd just keep one hand hovered over the keyboard button or the mouse cursor on the scrollbar, much like you might keep your finger on the scroll wheel now. If anything, I find swiping on a mobile screen more jarring since it means I have to use both hands (since I'd be holding the phone with one hand), or do some "phone gymnastics" where I try to shift the phone position in my hand enough to slide the screen with my thumb while still holding the phone, and do so without dropping the phone. Which often results in scrolling either too far or not far enough. > Not to mention screens were tiny so a long page didn't work very well. Mobile screens display a lot less text than a webpage did on a 90's 800x600 PC screen. Remember that modern screens will have a higher DPI to make things look smoother. On older screens we just accepted that stuff would look pixelated because that was the state of the art.

lenkite 5y ago

Web pages without JS are web pages that are served faster, render faster and consume considerably less power. Incidentally, the biggest mistake the web 'committee' did was to make a web-components spec that mandatorily requires javascript even for a basic 'hello world' label. That made it strictly a no-go for many domains where HTML/CSS generation/rendering is accepted but JS is not. I am in hard-favour of approaches towards UX components without JS.