You don't need JavaScript for that

Of course, designers may not like the way this looks and we want to create a great looking custom switch.

The general UI rule is use a switch when toggling has an immediate impact (similar to pressing a light switch) vs a checkbox when there's a submission step before it has an impact (similar to ticking a paper form then mailing it). See:

https://www.nngroup.com/articles/toggle-switch-guidelines/.

It made sense after learning this but I didn't find the difference that intuitive before. A lot of UIs get it wrong (e.g. switches in forms, checkboxes for settings that immediately change something) but it only bugs me now I know which one to use. It's not only for cosmetics though.

I wish someone came up with a better UI than the toggle. Usually, I understand what it means, but I often find toggles where it isn't clear what the state of the toggle is. Right vs left, color vs no color, just isn't obvious to me. A visible check in a box is crystal clear.

A toggle works fine if it's not treated as boolean, due to the exact problem you mention. What fixes it for me is having the meaning spelled out on both sides of the toggle, e.g. like this:

  dark (o  ) light

Separately, some UI's make it very hard to tell which side is selected. It's a rare problem, but especially anxiety-inducing for me when it does appear.

are you using anxiety with a bit of hyperbole here, or is it really making you anxious? I can see it being confusing and needing extra time to really look at it rather than being instantly obvious, but it's nothing to cause stress. It's just a setting/option. It's not going to cause significant issues if misinterpreted. You can just set it the other way, and do it again.

Is this the same thing that separates those that like to mash all the buttons and twist all the knobs to see what happens vs those that don't want to touch anything because they don't know what will happen?

The worst offender to me is the ambiguous ui around creating a teams meeting for meetings created through whatever we are calling the outlook web thing these days. You don’t find out if you did it right until you have sent an email to your attendees with an erroneous teams link. And yes that is anxiety provoking.

Of course part of what makes it ambiguous is that there is a setting somewhere completely different which when set will add a teams link whether the slider is set or not.

are you using anxiety with a bit of hyperbole here, or is it really making you anxious?

Depends on the setting. Sometimes they're for things that have greater than usual effects, like getting locked into a subscription payment or agreeing to additional charges for Spirit Airline flights. Other times they're for things that I have difficulty taking the initiative to address, like notification/unsubscribe settings, for which my ADHD only allows me occasional "windows" of time where I'm able to initiate or follow-through on changing the settings.

Sometimes it doesn't really matter and I just scoff at the bad UI and it's not a problem.

(o ) "Do you want to receive marketing emails from our partners?"

This is absolutely a dark pattern.

Even worse when there's not even a grammatical structure, like

"opt-out options"

"annoying marketing emails (o )"

am i... enabling the thing? opting out of the thing?

This can be used as a dark pattern. If you want a user to use a particular setting (e.g. “Customize my ad experience.”) you can just make it unclear which they’re choosing.

I agree, but it seems like a lot of times you get:

    (o foo)
    (bar o)

And I don't know if I'm supposed to click it to change to `foo`, or if that means it is already in the `foo` mode.

That's definitely much worse, both due to what you describe, and due to the fact that you don't know what the label on the other side says.

Radio buttons would work better.

It depends on the structure of your site. If you have, say, 10 pairs of boolean options in quick succession, toggles work way better than radio buttons.

The most annoying toggle is the Spotify no-repeat/repeat-all/repeat-one button. Is it currently not repeating? When it has the dot, is it repeating one song, or all of them, and will pressing it make it repeat just one?

Agreed. The Spotify UI is bad in general, but this one especially. I’ve been using it for years and I still have no idea what I’m doing there.

A big offender here is (was?) instagram’s privacy settings. I recall trying to help my mom turn her profile to be private and we were both confused: does the blue mean it is private or not?

The article linked by the commenter above addressed your concern. They mention the toggle should have an _immediate_ state change. I really liked the iOS airplane mode example the article used:

When turning airplane mode on for iOS, Apple provides immediate results by changing the cellular bars in the upper left-hand corner to an airplane icon.

To summarize, it sounds like the toggles you've experienced haven't led to an immediate state change, which likely identifies them as better candidates for a checkbox like you mentioned.

Total aside: but related to ambiguous true/false designation: A lot of times when people write articles like "Ten Myths About NodeJS", it is unclear in each of the numbered items whether the stance initially described is the incorrect myth, or the correct view as proposed by the author. To make it worse, some writers vary the structure between items!

A visible check in a box is crystal clear.

For the "off" state though, I've never found an empty square outline being that clear (this looks similar to a button or a text field) or easy to spot, and a cross/X in the square instead can also be confused with "on".

Honestly, besides being standard, checkboxes solve all of your problems.

That separation between immediate and delayed effect seems quite artificial to me, and doesn't exist at all on other types of inputs. It looks like a bad, post-fact justification created just to placate some masses instead of for good fundamental reasons. (And yeah, I do know who I'm criticizing here.)

Anyway, it's a lost battle, so whatever, let's leave with the bad consequences.

Switches seems like an innovation that just makes UI worse.

Checkboxes are easy to understand.

If there is immediate effect then using a checkbox also works perfectly fine.

The switch is just always worse (IMO).

Yeah, too often. But that's not the toggle's fault. The majority of the time the design (colors) and the associated label are the root problem. A toggle doesn't have to be ambiguous. Unfortunately, designers / UX'ers seem to think so.

I personally had not heard this but it does sound intuitive to me. A checkbox is literally something you would check on a form (i.e. piece of paper) before handing it in. A switch on the other hand, it something that offers immediate feedback in the real world.

Idk. There are enough switches that don't have an immediately noticeable effect, e.g. when you have to open a panel to turn things on or off, or when you have to go to another room. It's always hard to come up with the perfect definition/metaphor, but perhaps it's more like an operation that has a lasting effect.

But like designers shouldn't overdesign, we shouldn't overthink what's "correct" use. If it works and/or feels natural, it's ok. If it doesn't, it's time to consider alternatives, but you shouldn't implement them because some rule says so.

It’s a useful distinction but frustrating to apply in practice because we don’t have a similar convention for many other UI elements like input fields and date pickers. You can’t tell at a glance whether these will produce an effect immediately after entering a value, or whether there is a separate submission action.

In terms of primitive types and common UI platforms, we have this immediate/deferred distinction for booleans and enums.

Booleans are represented by checkboxes vs. switches as already discussed. And enums are represented by radio buttons (the traditional form element) vs. multi-part buttons (which Apple calls segmented controls).

I can absolutely see this. But to share a different perspective since “instantly vs. submit” doesn’t make sense in some of my software that’s constantly applying input changes on change:

I use a switch to toggle one specific thing, checkboxes to pick zero, one, or many related things.

Eg: switch: “slow mode is active for robots in this zone.” Checkboxes: “this applies to robot types A, C, D.”

Apple can scarcely pretend to adhere to it, but their HIG on checkboxes, radios, and switches is good: https://developer.apple.com/design/human-interface-guideline...

Also worth noting that on macOS (where you’d see checkboxes), things like settings dialogs very rarely have “save” or “apply” buttons, with any settings changes taking effect immediately. Checkbox vs switch has no bearing on immediacy.

The only exceptions are cases where partially applied settings can cause problems (like network settings) and the odd holdover that’s survived since the pre-OS-X days (like the settings dialog in Music, preciously known as iTunes, previously known as SoundJam MP).

This was very nice!

I will make an important nit. Keep in mind this is a nit. It's text in bold in the page, but this is NOT an attack on anything else in the article, which describes good design practices.

There is no principle that one should "Choose the least powerful language suitable for a given purpose."

This would, in fact, be an incredibly stupid principle. One want the most powerful language for any purpose. However, "purpose" is broadly defined:

1) We want code to be semantic. This allows a11y tools, search engines, and various performance optimizations to understand what's going on.

2) We want clean abstractions. In a horizontally-abstracted system, we would like the content designer to be focused on the content, the UX designed to be able to focus on the UX, and the back-end engineer to be focused on the back-end. (Note that, contrary to the beliefs of most people who have only worked on database-backed web applications, vertical abstractions are okay too, and break things up completely differently).

3) We want systems to be bug-free and understandable.

This can leads to programming paradigms like functional programming + React, where no mutation is allowed. This isn't a random restriction which reduces power; to the contrary, it increases power by allowing predictable state, avoiding a whole class of bugs, and allowing debugging with time travel.

In other words, you want good design discipline. However, the point here is much more on "good design" and not "discipline."

Every one of the changes proposed can be derived from first principles from the above. But this does not come from some principle of "least power."

To make this even simpler: Think of diet discipline. The goal isn't discipline about being hungry and eating yucky food. The point is about being healthy and losing weight. That probably involves being hungry and eating yucky food, but that's not the point. Food should be as tasty as possible and people should not be hungry to the extent goals on weight, heart health, insulin resistance, etc. can be accomplished.

Same thing here. Languages should be as powerful as possible, while allowing goals around readability, introspection, a11y, abstraction, etc. to be accomplished. That requires very specific and narrow constraints on what one bans.

There is no principle that one should "Choose the least powerful language suitable for a given purpose."

This is mistaken. https://en.wikipedia.org/wiki/Rule_of_least_power

It’s a stupid rule. Why?

In my career there are two types of software projects. Ones that start off using a powerful language and libraries, and those that don’t because “this is just a prototype/small project”. 9 times out of 10 the second type naturally evolves into something more complex and requirements become harder to solve with some “least powerful” language. Inevitably a costly migration is made to a more powerful toolset, be that react, Spring, or whatever.

I think it’s a bit different in infrastructure where the core of what you want is a declarative set of requirements and properties. But in SWE you’re a fool to start your project with the least powerful tools.

Is C more or less powerful than TypeScript?

More. JavaScript is deeply constrained by design.

If you're using Deno and run into the limitations of the JavaScript language/ecosystem, you use its FFI to call out to libraries written in languages like C and C++.

Similarly you might address a performance issue in your C code by writing assembly code, which is the most powerful language essentially by definition, and which of course has plenty of downsides.

I think it does make sense if you consider it in terms of actual language power (a la Automata Theory) as opposed to just varying kinds of Turing-complete languages as it seems you're framing it.

If what you need is a configuration language, please don't express it in Python. If what you need is a regular expression matcher, please don't express it in a bespoke recursive-descent parser written in the enclosing language. If what you need is a SELECT over a large dataset, don't download all rows from the DB and then iterate/filter them on the local host.

I think there are many reasons for this, not just for human readability -- also for performance and security. Berners-Lee is quoted in that wiki article as saying it helps semantic extraction, too, but I personally consider that less convincing.

EDIT: automistake/grammar

If what you need is a configuration language, please don't express it in Python

Oh god please express it in Python more so than anything else. The configuration language file -> templating the configuration language file -> scripting the templates to the configuration language file pipeline has to die.

If you're going to use the simplest thing possible make it easy to throw away when the nerds get more complex instead of having to build the complexity on top. Regex is a great example -- if used internally when you need something more you just throw it away. But if you make a single static regex part of your configuration your users are stuck with it.

html or css is less total power in exchange for being better at some specific things.

If html can reasonably do X then it's probably better at doing X than doing it js. If that rule of thumb isn't true then there's no point for js to exist at all, it would mean js is strictly better in all scenarios.

I'd say Spring and React are less powerful than just plain Java/Javascript, in fact having any framework usually reduces the "power".

I believe "power" in this context describes the amount of freedom the language allows. The less powerful the system is, the better you can reason about it and the more external tooling you can add around it without breaking corner cases. A webpage is less powerful than a .exe running on your system, but that is what makes it so useful - you can run it at 144 fps, use it with a screenreader, custom CSS, high DPI (even if the webpage was written in the 90s), etc. and all of this relies on the lack of power of the webpage.

Can we not use language like mistaken and stupid to describe what is clearly a heuristic?

It is mistaken to assert that there is no such principle/heuristic.

It's not mistaken to disagree with the principle, but that's not what the comment you replied to was doing.

You put it very diplomatically. In my world I’m a lot more no-nonsense about the anti-react movement: they can go spend their careers making dull static websites with progressive enhancement and I’ll work on the interesting stuff without them.

This is interesting. React / Vue 3 has totally destroyed the creativity involved in webdev for me after working on multiple larger projects.

Having just finished a pure JS + Petit Vue project the creativity and fun came back for me, while highlighting some important parts of the larger ecosystems.

I'm still anti the newer frameworks though - and i think most are like me because of the ridiculous complexity these days, the sweetspot for me was around Vue 2, Angular 1.

The newer frameworks just have too much "magic" going on, way too many files, dependencies, ever changing tooling, and no one seems to understand even small parts of it fully. It becomes about reading manuals and following conventions, instead of being creative and getting things done.

Sharing simple data from one div/component to another is a good example of too much complexity; from 1 minute sharing across your app/teams through window.sharedObj, to 40 intermediate steps, 100 files, 100 imports, stores, 10 dependencies, .value.value.data.data, and extremely long nonsensical errors when your data has stranded somewhere.

I'm still anti the newer frameworks though - and i think most are like me because of the ridiculous complexity these days, the sweetspot for me was around Vue 2, Angular 1.

But it's the exact opposite? At least if we're talking Vue 3, literally everything about it is less complex than Vue 2 was, especially with Vite. You're telling me that Webpack is less complex than Vite? At my work our 1 Million+ LOC Vue app the Vite config is like 40 lines for Prod, Staging & local dev each, and every single line of the config is dead obvious without even needing to check the docs, especially when you compare it to the monstrosity that Webpack setups usually end up looking like. Plus there's the insane speed at which even gigantic projects get built, whereas Webpack can easily take 100x the time. Hell, even HMR would take around 15 seconds on an uber powerful machine before we made the switch to Vite, where it now takes ~500ms.

Sure, there's a small bit of adaptation to be made with refs and calling `.value` outside of templates, but once you grok it it's actually a lot more logical than the magical `this.` you'd see everywhere in Vue 2, since `this` can refer to a LOT of things at any given moment, and it's never 100% clear what it is.

Sharing simple data from one div/component to another is a good example of too much complexity; from 1 minute sharing across your app/teams through window.sharedObj, to 40 intermediate steps, 100 files, 100 imports, stores, 10 dependencies, .value.value.data.data, and extremely long nonsensical errors when your data has stranded somewhere.

Again, this is the complete opposite to my experience with Vue 3. In Vue 2 you had to deal with Vuex and the weird getter/mutation/state stuff, whereas with Pinia you just set some state as an object, and you can directly manipulate that state wherever you want, even with excellent devtool support.

And I definitely wouldn't call sticking all your state into a random `window.` object less complex than using something like Pinia, if that's your idea of less complex then I'm happy to not be working on the same codebase as you. I'd rather you not be creative with state management like that, cause every time I've ever had to deal with some monstrosity of an untyped `window.GodObject` I've wanted to throw my laptop against the wall.

Not to mention that if you opt for TS (which is like a single line in the Vite config), it's WAY more productive than Vue 2 since you now have properly typed emits and props and can actually have an overview of what data is flowing where. Plus CompAPI in general is just objectively less boilerplate and less code than the old Options API. An identical component will have much less code in 3 vs 2, especially complex ones, and ESPECIALLY once you start talking about mixins.

Also, passing props hasn't changed between Vue 2 & 3. You still just pass it in the template via `:myProp="myProp"`, all the same caveats as before still apply, except now it has proper type hinting that your IDE can help out with without having to scan the file itself. If you wanna avoid prop drilling (passing data from a parent to a deeply nested grandchild component), then provide/inject (also typed) or just Pinia (which again, is dead simple in comparison to Vuex or heaven forbid some monstrosity of a `window` object) is there to help.

The Vue 3 docs are also the best I've ever had to work with, and if you read through it just a single time you'll have an extremely clear understanding of how the framework actually works. No guesswork needed, and they always outline drawbacks as well as how to work around those drawbacks.

Thanks for the hint on Petite-Vue, it's just enough framework to my taste!

The newer frameworks just have too much "magic" going on

Either that or they don't have nearly enough magic to separate the developer from all of the paradigms of the web, so they can apply their own idea with any clarity.

But yeah, they sit there, at just about the worst possible spot. One can improve them by going either way.

shrug And I won't be visiting. The only thing I care about is useful content well presented. I always disable JS for security reasons (that, and because pages load a hell of a lot faster and with far less memory). Yes, things break but it's a price I'm more than happy to pay.

The interesting stuff tends to be webapps, that people pay for and are often internal to a company.

If you just care about sites that are document based, of course you’d prefer the static content stuff! But he wouldn’t be working on a project you’d be visiting anyway, so who cares if you stop visiting?

You don’t have to support, use or even like React in order to like responsive clients that don’t roundtrip to a server for every little thing. Heck, it doesn’t have to be reactive programming at all for all I care, as long as the result is good. It just happens to be that currently reactive programming is generally the least bad system to program in. But even CSS transitions can do a lot of heavy lifting and degrades well.

I promise you that the majority of React apps are effectively “dull static websites” that happen to be rendered on the client and that you can do a ton of interesting stuff without it. Here’s a full-on Photoshop clone in the browser built without any libraries: https://www.photopea.com/

> Choose the least powerful language suitable for a given purpose.

No. Choose what you like, what you enjoy, or what the boss told you to use. Ideally the project defines prioritize that give guidance. Otherwise do what feels right.

Don’t follow some arbitrary doctrine.

Do this only if you don't care about the people that use (sometimes: have to use) your software. Otherwise,

> Choose the least powerful language suitable for a given purpose.

(Don't make me needlessly enable JavaScript to use your site.)

> Do this only if you don't care about the people that use (sometimes: have to use) your software.

Rubbish. Web technologies are way too sophisticated to boil down to some silly rule of thumb that “the least powerful technologies are the” best in some way.

As a professional developer, use every technology at your disposal and use it in whatever way you like, including the most advanced techniques.

Ridiculous to be given the most one of the most powerful development tools ever made - the web browser - and artificially constrain how you use it for some dogma.

And if you’re a junior developer, ignore people who tell you how you should program - do it how you like unless the boss says different.

Your web app is most likely rubbish and 20 times as complicated as it needs to be, and probably still nothing special.

A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript.

A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript.

Are users happy? Is dev speed of improvement good enough? Can you onboard new devs easily enough?

That’s it. Nobody cares if you used CSS or JS for a toggle switch.

The only people who disable JavaScript in their browsers and expect the 2023 internet to accommodate them are right here in this thread.

Just componentize it and move on to solving the next business problem, not the next code elegance problem.

Nobody cares if you used CSS or JS for a toggle switch.

Other than the people who have to wait several minutes for your 20MB JavaScript framework to load on their slow metered connection just so you can make an expandable section using a bunch of <div>s rather than the native <details> element. But those people don’t matter because they should just move to a country with unlimited fast internet, am I right?

Vanilla JavaScript is supported natively by all web browsers now.

Nobody is suggesting using a 20mb framework to make a toggle switch work on a standalone page that isn’t a web app.

If you’re building a web app either way, then choosing between a screen full of CSS or a handful of lines of js is negligible.

For expanding sections, you should use native HTML elements when they do the job with less effort/code. You should use JS when they don’t.

I don’t know exactly where you’re going, (and to be fair the parent comment is rude) but it’s wise to be humble even if you are a professional. Some of the most experienced people in the field frequent these threads, HN is not a monolith of neo-luddites.

My 2 cents: native solutions like HTML and CSS are preferable: they are designed to degrade well, they work with screen readers, with increased font size, high contrast, and other less-known or unknown and even future use-cases and needs. No dev team has the time to test their custom JS solution on all possible browser targets, and in reality they frequently fail even basic accessibility needs for no good reason.

At least to me, honoring the principles of the web is our responsibility, especially in our current time when they are arguably under attack from well-funded players. I would hate to see the web degrade into a delivery mechanism for opaque executables that work only on corporate blessed mega-browsers.

Sure, maybe if it accomplishes exactly the same. That’s why I disable JavaScript on most news sites. But in the real world most web apps simply can’t accomplish the same without JavaScript, which is why we use JavaScript.

Sure, I guess. Just act like all of those vision impaired folks don't exist, and put the entire website in JS that their screen reader can’t handle. Nice.

Remember kids, if a minority is a "rounding error" it's okay to ignore, block, and hurt them though your profession. That's what webdevs tell me.

As a professional developer

This qualifier probably applies to >90% of this website’s audience, so I don’t think it’s useful.

Using less power if you can get away with it is absolutely sensible. If my implementation is suitably robust without the use of type families, data kinds, singletons, lenses, etc., then that’s a more economic solution.

The article seems to be suggesting to remember to use the power the the web browser already provides instead of needlessly using frameworks.

The walkthrough in the article seems to demonstrate pretty effectively that the powerful development tools offered by a modern browser may obviate the need for elaborate frameworks in many cases.

Where this is the case, then, relying a framework instead of the tools the browser already provides artificially constrains an application, potentially for dogmatic reasons, and regardless of a developer’s level of advancement.

Browsers have rapidly come a long way even just in recent years. Frameworks well and truly have a place, but narrowly relying on frameworks, particularly out of beliefs about browser capability established years ago (like when React was introduced), can neglect browser-native functionality that can provide same-or-better results, with potentially better outcomes in performance, accessibility, maintainability, and more.

(Don't make me needlessly enable JavaScript to use your site.)

Only a very small but vocal minority of users disable JavaScript, as it's not a default setting in any of the web browsers with a market share higher than the rounding error.

In a lot of cases, designing a no-JS website disadvantages both the service provider and the users:

- the service provider has to support a higher load to render the page and process the data on the server,

- the user has to endure longer processing times for their data, since their request necessitates a round trip from/to the server adding additional latency.

For example, let's think of an image processing web app. All of this can be done on the client side (and this gives the user a higher sense of privacy since their data doesn't need to reach the server). It's much faster there, reduces the server load - allowing the service to be used by more people at once.

And there is no value in appeasing the no-JS minority, since either maintaining a no-JS version of the app in parallel, or building the entire app without JS, outweighs the potential ROI from the <1% of users[1].

If you disable JavaScript because of tracking and ads:

- browser extensions exist to only prevent tracking JS from running without affecting the websites,

- you can still be tracked server-side.

[1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi... - 0.2% of users of the UK online government services had JavaScript disabled. Based on the research I can find online, most of the no-JS users are using TOR, which isn't a terribly profitable demographic for commercial websites.

Many websites that use JavaScript, particularly news sites, would be much faster without it.

True. As an user, I just don't visit websites that disrespect me, though.

I keep JavaScript always on and if I see a website abusing my trust, I just blacklist the entire website from my browser and never visit it again.

As a developer, all of my publicly available personal projects feature no tracking, no advertisements, and no third-party JavaScript in general. JavaScript is a really good tool, but as any tool can be, JS can be misused.

No. Choose what you like, what you enjoy, or what the boss told you to use

Don’t follow some arbitrary doctrine

Isn't choosing what the boss told you to use simply because they told you to following arbitrary doctrine?

If someone has a reasoned argument for a specific tool they should share it, at which point you're picking it for that reason not because of the boss said to

Developers, engineers, whatever need to be responsible with the product they make. Part of that means making tool decisions that fit the specific context and pushing back when necessary

The thing is, that sometimes javascript is a lot easier that 40 lines of css.

Yes, but the 40 lines of CSS puts the logic in the right place.

The point is that a person reading system logic shouldn't need to be distracted by layout, and a person worried about styling shouldn't need to think about code.

Whether that matters depends on the specific system and the types of abstractions used, but it can be very important to making code maintainable, and in some cases, org structures practical (where the team maintaining the CSS might not be the same as the team maintaining the system logic).

> puts the logic in the right place

There’s no “right place”.

It’s a web browser. You program it in whatever way you like that you enjoy that makes sense to you.

Use whatever approach you need to get the job done. Mix and match. Come up with new ways. Do it simple. Do it sophisticated. Combine JS and CSS. It’s all valid.

Don’t listen to people who try to tell you how to program.

JS for UI is wrong, because there will be FOUC, and if you preload JS, the page will be slower. Of course, if something is impossible with CSS, JS is fine.

> JS for UI is wrong

Yeah that’s showing an incomplete understanding of web application development.

Yeah, the 90% of web apps whose UI is broken, I don't understand them. Haven't we all seen multimillion $ airline mega web apps that can't present a decent form?

Javascript on the frontend is not for "systems" logic, it's for small changes to the layout without reloading the page. This myth that HTML, CSS and JS are all separate "systems" that need to be isolated has to die.

JavaScript on the frontend is not intended for "small changes to the layout without reloading the page", it's intended for changes to content. CSS is one of the tools intended to manage layout and appearance.

Is it possible to use one for the other? Of course.

The big thing you didn't mention is accessibility. Unless you know exactly what you're doing, just a few lines of javascript will let you break a user interface in so many subtle ways.

As a mostly backend guy that's the case most of the time for me.

I never really got my head around the correct way to think in CSS.

I am at the "I can see numerous ways of doing this" but I never really know the standard or best way to do it. It was the same when I started doing web dev / Django stuff, whereas now, with years of experience, I do know the best way to approach a problem, to keep code minimal and clean and readable.

(If anyone can suggest some tutorials that get me past that stag with CSS I would grateful).

https://every-layout.dev shows how to leverage CSS properly, from first principles.

Thanks, I'll check it out.

Of those 40 lines, many are styling to create the look of the switch in css, it could have been replaced with an image (and needed for a js solution anyway)

But it's also too often broken, fragile, and the worst sin of all, break default behaviours of browsers. It is the price we pay for html having been stale for 15 years between the late 90s and 2012-ish.

I was unaware of Datalist, but it does not appear to work on Chrome Android, at least not really.

I see the options in the keyboard [0], in the place where autocorrect suggestions appear. But that's the first time I have EVER seen that in a mobile web UI for a page's form control (aside from password auto-fill apps that use that same space).

I don't hate it -- it's actually much nicer than trying to awkwardly scroll a poorly built custom JS drop-down. But I have no confidence that all normal users would figure out how to use it. So I think it's DOA for mobile.

Also, it is flat-out not supported on Firefox Android [1].

[0] https://imgur.com/a/Ecb4503

[1] https://caniuse.com/?search=datalist

This is why these solutions take so long to catch on.

JavaScript is pretty well standardized, html and CSS is less so.

CSS is easier than JavaScript.

Here is an example of JavaScript-free CSS motion:

https://egbert.net/blog/index.html

CSS may be easier, but that's irrelevant to OP's point—it's less standardized across browsers, so if you have to support a bunch of different browsers of varying ages it's much easier to write JavaScript with boring CSS (and even transpile it if you want to use newer features!) than it is to polyfill all the missing CSS features you'd need to use it instead of JavaScript.

Hey browser makers, can we please be able to style the datalist dropdown?

Also: https://adrianroselli.com/2023/06/under-engineered-comboboxe...

This thing where the datalist options show in the keyboard is some recent thing, i.e. a few months ago. It used to be "normal" before that, but I guess someone wanted to change things only for the sake of changing things

Have you looked above the keyboard?

For me it shows the options above the keyboard where normally word suggestions are shown.

I wonder if adding autocomplete="off" to the input element changes the behaviour? It is in any case required for sanely using datalists. Otherwise the value selection history will be appended to the dropdown list (observed in Chromium).

Also, datalists still need JS in some cases like when a default value is set. I have the workarounds and browser quirk notes here in the (to-be-launched) new LibreOffice website code: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...

Good news is that a Firefox dev plans to look into improving datalist behaviour, so only a single click would be enough to display the list.

I really wish data list was better, shipped it on an admin dashboard for something, and while it works fine in safari it’s a bit broken in several ways on chrome and Firefox, leading me to need to replace it with JavaScript

works fine on chrome android

My favorite "no JS, we have CSS" stuff are side bar (drawer) and carousel. DaisyUI (a TailwindCSS components library) has components readily available too :)

1. https://daisyui.com/components/drawer/

2. https://daisyui.com/components/carousel/

I'm always initially excited about these frameworks, but like all other frameworks I've tested, DaisyUI has a number of issues in iOS Safari and other browsers.

It's as if authors of these frameworks severely underestimate the amount of testing required to make these things actually work across browsers. Once you have that many (themeable, no less!) components, all bets are off you'll still able to fix it without breaking existing themes and applications.

What framework is the best in your testing?

Not OP, but which framework is the best is a very subjective question. Frameworks in general make what you want to do easier to do, at least from a developer experience perspective. Generally this meets the mark for most use-cases, but has proven to be a problem (especially in ORMs) if you want to go outside of the box. They seek to abstract complex or cumbersome logic into more consumable APIs, and in most cases this ends up being a footgun.

Point I am trying to make is: learn all the nitty gritty about CSS (specificity, box layout, selectors, etc...) and really understand how the base language works. Then go play with frameworks, figure out which ones fixes the parts you don't like, and makes the parts you do like better.

Usually these frameworks don't survive a "try to click on each element in their official demo" test in iOS Safari without glaring, visual issues, so I don't see much reason to rank them.

How do you announce the drawer to the screen readers?

For the people down voting: Drawers and other content that appear on the page needs to be announced and needs to have a state aria-expanded next to the controlledby.

This is still a genuine question. Maybe there is a way, or maybe developers collectively think that's not important (our auditors would disagree but, anyway).

I believe it is announced as soon as you add it to the DOM and make it visible. I don’t have a computer near me to test it, but that’s what I remember when testing this stuff out a few years ago.

Every single time I go looking for JavaScript components like this I find myself asking the same question.

I really wish component providers would start explicitly documenting this. My dream is to find a component library where each component is accompanied by videos showing how each thing behaves in different accessibility tools.

Native smooth scrolling with scroll-behavior: smooth

But please limit how you use this; it’s not actually a good idea most of the time you might think of using it, and often has undesirable side-effects.

Native carousels with scroll-snap,

But carousels are still a bad idea, so scroll-snap is of extremely limited legitimate application.

Scroll driven animations

Pages that do this are normally improved by removing it.

The point of the article isn’t to dictate what design elements people use, it’s to point out more user friendly ways of achieving those designs.

Smooth scrolling is a great example. The native API allows a user to interrupt at any point. Most JS implementations are janky as all hell and users suffer.

Scold design choices all you like but don’t expect to be listened to. Especially when you’re not providing any actual reasons why “carousels are still a bad idea”.

Especially when you’re not providing any actual reasons why “carousels are still a bad idea”.

It’s widely understood and documented that carousels are a bad idea, and plenty has been written about it.

(I should clarify that the problems are with carousels as a way of presenting diverse widgets; as a way of presenting a collection of pictures about a single item, it can be acceptable.)

> The point of the article isn’t to dictate what design elements people use, it’s to point out more user friendly ways of achieving those designs.

If your goal is user friendliness, it would behoove you to use a design which is user friendly.

Using a design which is user unfriendly and asking "how can I make this unfriendly design seem friendly" seems to be approaching the problem from the wrong direction: the design choice itself is the biggest contributor to user friendliness.

Either you care more about yourself and your design choices than user friendliness, or vice versa, and both are totally valid options, but don't pick the former and claim the latter.

But carousels are still a bad idea

I too dislike carousels… But at the same time the Amazon homepage prominently features a carousel, and I know that Amazon ruthlessly A/B tests homepage variants so the carousel presumably tests well… so I’m not sure that they’re actually “bad” in some sort of universal objective way.

BigCompany A/B testing has this unfortunate tendency to demonstrate positive results to whatever you are testing. Like the A/B test that repeatedly demonstrated that after you buy a blender, your most likely purchase is another blender... (which Amazon still hasn't fixed nearly a decade later)

I believe you’re significantly overstating how good and thorough a job they do of such things. Also it’s not the sort of thing that’s particularly conducive to A/B testing.

This is anecdata but in my experience the way WebDev (esp. HTML and CSS) is being taught in academia is very crusty. I've seen Juniors enter the workforce with a solid understanding of table-based layouts from the 2000s for some reason.

The other end of the spectrum: I’m seeing graduates with great knowledge of frameworks, but no understanding of the fundamentals that these are built on. It’s all fine until they’re trying to debug a problem and don’t know where to turn. glares at Tailwind

That's not a tailwind problem that's an educational one.

I guess it's a sign of the domain expanding (exploding, really). "Software development" is not a single discipline, even though it's still taught as such in many places.

I mean you can't really use Tailwind if you don't understand at least some of the underlying CSS. It's not like it does anything magical for you, it just gets rid of having to give class names to things and has some nice little utility functions as well such as `grid-cols-x`.

Edit: my mistake, the first custom-styled switch example isn’t the full example. I realized that after I commented. Original comment below for posterity. It doesn’t apply to this case, but I think it’s still relevant as I’ve encountered the mistake I thought I was seeing in “you don’t need JS” contexts pretty frequently. In any case, sorry I misunderstood the example in the article.

The custom-styled switch doesn’t work on iOS Safari. It certainly can work without JS, but this kind of mistake is potentially informative in evaluating whether it should.

That’s not to say “if you want a custom-styled switch, JS is a better way to achieve that.” But if you’re already starting from the premise that HTML has a functional equivalent, it’s okay to use that for the default behavior and enhance it with JS to ensure it’s interactive when it’s enhanced with CSS to satisfy a non-standard design.

Did you try all of the custom styled switch example? The first one didn't visibly work for me on Safari but the others did - the examples are meant to build up a demonstration of the final pattern.

I was just coming back to edit my comment to acknowledge this. My bad! I think the principle still applies, because I have definitely encountered the mistake I thought I was seeing here. But it doesn’t apply to the example. That’s what I get for commenting before the morning coffee sets in :)

Author here. The first styled example doesn’t have the style to respond to the checked state. I explain that in the article right below the example.

The custom switch was honestly kind of impressive

From the UX point of view I very much prefer the oldschool way of „ticked“/„nonticked“ instead of „left/right“ switch.

I wonder how much the culture you're used to matters for this. What if you grew up with right to left writing system. Should your switches have the off state on the right?

To me, they have slightly different semantics: I perceive the checkbox as “passive” form element (i.e., only to have an effect on form submission), whereas the toggle switch I understand as instant action (i.e., effectuated immediately, on click). Unfortunately, it’s not consistently used that way in practice, which makes the situation confusing at times.

I'm ok with window.prompt(), window.confirm() etc

I was disappointed it wasn't there.

In my experience, managers will complain but the users don't actually care and just want something that works.

They're mentioned in the dialog section.

Moreover, unlike dialogs they are immediately accessible.

Dialog was rushed in without fixing many problems it has because Chrome (and apparently other browser, too) want to remove prompt/confirm/alert.

Nice. But the second switch doesn’t work on iPhone ( doesn’t toggle when I tap it)

they explain that it works but you need the next step to see it

It is not supposed to, the code is completed in the third example.

In general, good advice.

... But the trade-off is lack of control, and that can be a problem. The author notes, but I think under emphasizes, that the color picker, for example, has no standard on how it should be implemented and so browsers are free to choose. The Safari color picker, in particular, is so bad that color picking is the one thing I recommend people absolutely roll a custom widget for, unfortunately.

And, in general, if you go this approach you are trading off needing to care and feed for your own widget solution with needing at least a passing understanding of how the browser-implemented widget will operate in every browser that your team will choose to support actively. And the implementation spec for browser widgets is far more open-ended then the constraints placed upon a JavaScript implemented widget with assets you have created from scratch.

The Safari color picker, in particular, is so bad

What's bad about it? Can't test it on desktop right now, but on iOS it opens all the bells and whistles, including the "pick color from anywhere on the page".

What used to be horrible across all browsers is the date picker: tiny buttons, tiny numbers etc.

On desktop, the color picker in Safari has two stages: on first click it presents a 10x10 grid of colors with 10 extra basic colors on top, with a “Show Colors” button on the bottom that opens the macOS system color picker.

This is actually a bit better than the picker implementations in other browsers because it gives the user a chance to use any colors they’ve saved in the system picker, as well as any color picker plugins the user may have installed.

An other example of "you don't need js" carousel :

https://www.codepel.com/demo/css-carousel-slider-without-jav...

there's an other comment posting a tailwind version , and I thought having a raw version would be helpful too

that's the issue with raw things, as you don't need any library, they are not marketed and it's really hard to find them when libraries take all the first results

This works terribly on mobile and broke my back navigation…

fyi, "another" is a single word

The datalist element didnt work for me on Mobile Firefox (Fennec)

This has been a known issue for a long time. https://bugzil.la/1535985

A nice thing about using <details> instead of JavaScript is that Ctrl+F can see into the details and open them up whereas it can’t open a JavaScript accordion.

hidden="until-found" will make this possible in JS-based accordions and other hidden content but is unfortunately only in Chromium-based browsers for now: https://developer.chrome.com/articles/hidden-until-found/

The irony is using a JavaScript-based static site generator to make the site: https://www.11ty.dev

Nothing ironic here. It's a different domain problem and they're using a different domain solution for it. The generator might simplify an otherwise much more complex problem down to its essence.

Really nice. Some elements I wasn't aware of. Will def come back to this.

Other good example where no JS is needed: styling internal and external links

I use them and it saves a lot of time developing. Problem is that managers will complain that they are too simple. At least that's my experience working with "enterprise" consultancies

Some weird issue with <details> in Safari on iOS is that "open" attributes could disappear when iirc overscroll or something, so I was force to use JavaScript or disable overscroll behaviour.

It's a step in the right direction but CSS is another tool of abuse by what Philip Greenspun called "artistes" to make unreadable pages. I'm not a proponent of Gemini but basically all aspects of layout and typography need to be returned to the browser, which must be controlled by the user. Designers have endlessly shown that they can't be trusted with it.

Love this. I make heavy use of dialog elements on WireHub.org, along with bootstrap classes to achieve drop downs that work without JS and still look nice.

Only issue is you have to click the summary element to hide the dropdown, and that's where I cheat a little and use JS to hide it.

My principle is always: The principle of the most power.

I would use that to do simplest thing as possible, or i'm not afraid to do the best thing possible.

Let's say you start with pure html, now how to decompose your HTML into multiple components with state ?

Start with component-approach instead.

Compiling to HTML is just the implementation detail.

So the unofficial (?) input:before is safe to use now, what's the consensus?

Great article! Very clear. Nice examples.

I have some complaints about how Firefox handles these features, though. Closing modal dialogs with the escape key doesn't seem to work, even though it's described in the docs on MDN [0]. It does work in Chromium.

Also, the native color picker in Firefox is really weird: The Custom/+ button triggers on mousedown, which feels surprising and disconcerting as a user.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

Article has a typo, now instead of not. "In contrast to JS, which is imperative, HTML and CSS are declarative. You tell the browser what to do, now how to do it. That means the browser gets to choose how to do it, and it can do it in the most efficient way possible."

I like the sentiment here, and the switch is cool, and summary/details is occasionally handy. But -- the datalist element is almost never a realistic option for anything more than a toy or prototype.

*The rule of least power*

It's one of the core principles of web development and it means that you should Choose the least powerful language suitable for a given purpose.

On the web this means preferring HTML over CSS, and then CSS over JS.

Ah I totally do this, I never though to put a name to it besides taking the ‘minimal’ approach - if you can do it with just HTML, then by all means, just mark up some content and be done with it.

datalist

I agree with most of these (I haven't played with dialog enough to have an opinion) but datalist is not a valid choice IMHO unless it's an internal tool. It's ugly, limited in what you can do, and not style-able. This is the problem with a lot of the "just use the built-ins" (looking at you date picker), not only are the defaults not great but you can't change them even if you want to. As soon as you hit one of the many brick walls when it comes to styling or changing behavior (Oh you want the week to start on Monday? Too bad) then your only choice often is to reach for a full replacement library that, yes, uses JS.

I'm all for using the lighter-weight options and agree with HTML > CSS > JS hierarchy but sometimes JS is the only answer if you want to make your UI look nice and have the features you want.

Wish I had read this a month ago before I wasted hours fighting against some of these things in tailwind and JS. That color picker trick is awesome, and the styled toggle switch looks extremely slick.

100% agree that everything doesn't have to be JavaScript. You can do a lot with just HTML and CSS.

My company's website is all HTML/CSS - https://neuml.com

The thing that this article is missing is that we use JavaScript in these places because compatibility is better. We can even use new JavaScript by transpiling, but polyfilling missing CSS and HTML is a lot harder to do and impossible in some cases (not to mention your polyfill will use JavaScript).

`appearance` has a lot of caveats on MDN about testing it thoroughly if you're going to use it—even `appearance: none`. This may matter less if you only have to support new browsers, but keep in mind that old versions of Safari stay in circulation longer than you might think.

`datalist` does nothing on Firefox Android. It just shows to me as an input box with no functionality at all (not even the suggestions over the keyboard that others report in Chrome Android).

The color picker is neat, but extremely nonstandard, which is a dealbreaker for most businesses not just because the designers will complain but because customer support will find it harder to help people. Chromium provides the functionality to pick on a page and pick literally any color, but Firefox Android only gives me the rainbow, a gray, and black and white.

The article itself acknowledges the inconsistencies with `details` and `dialog`.

I hope we eventually get to a place where browsers that don't support these features (and support them consistently with each other) are no longer used, but in the meantime these elements will only find their way into my side projects, where I have full control of which browsers I support.

The answer is always: of course you don't. But weaving in clever HTML like this is a pain in the ass to maintain, when you can drop in a reusable, extensible widget for your framework that has already been debugged and is one line of code that everyone understands.

Actually, for accordion (i.e., details and summary), as I understand it, is not accessible out of the box. It's odd that the spec for that control / UI element / tags isn't accessible. But you can use JS to fix that.

A colleague once shared a blog post with me on this but I can't find it atm.

Good spirit, I was just recently seeking reference materials about how to execute an accordion style fold in pure html or CSS and discovered the approach you describe - so simple, we should be seeing it more often.

know that [outline: none] not a good idea

Why recommend a style on summary:focus but not input:focus?

Shouldn't we style :focus-visible for both or neither?

I bet you could use the <details> element to implement the show/hide comment behavior on hn

I wonder how inefficient web apps contribute to carbon emissions

Incredible. Now I wonder why this site, news.ycombinator.com "hacker" news, needs disgusting javascript to do what the 'accordion' example does?