[crazygringo]

I love dark mode as a user, but as a developer it terrifies me how much complexity is involved in programming in 2019. At a stroke, it doubles the number of possible combinations of:

- 2 device sizes: desktop vs mobile (e.g. responsive)

- 3 platforms: web vs iOS vs Android, or web vs Windows vs macOS vs Linux (not even counting cross-browser or OS version quirks), or god forbid all of the above

- 2 input methods: hover/click/drag vs tap/hold/swipe

- 2 modes for accessibility: full visual+audio vs screenreader/captioned

- And now 2 visual modes: light vs dark

That's 48 combinations to design and test for. I'm probably forgetting some too. But as a developer it makes just the baseline cost of any basic app so damned high.

Again, as a user I love it. But the entrance cost for entrepreneurs, or even hobbyists? Man oh man.

[laughinghan]

Conversely, that's what's amazing about the Web, right?

Whenever people introduce any of those things, like when iOS was introduced, they had to decide how to port all the existing content and interactions and widgets to mobile and touch interfaces. As a result, if an entrepreneur or hobbyist makes an app on one platform and wants it to be at least minimally usable on another platform, the Web way, way lowers the barrier to make that jump.

[ken]

The particular methods for making CSS backwards compatible are specific to the web, but the general problems faced by having user display preferences are not. Adding these features to native apps blows up your testing matrix there, too.

In many ways, it's even worse. I've got OS settings here for "increase contrast", "reduce transparency", "use grayscale", "invert colors", and (because areas of native windows can be translucent) even the desktop wallpaper comes into play.

I turned on dark-mode for testing my own app, and I had to turn it off because there's parts of Xcode where the contrast ratio is less than 1.1:1.0. The text is downright invisible. Obviously nobody at Apple would ever intentionally make software like that. They must have simply never thought to test with the same settings as I have.

https://pbs.twimg.com/media/D1kfN6SUcAEwWxq?format=png&name=...

[laughinghan]

And yet Xcode is very successful and well-liked, or at least if it's hated, it's not for the flaw you found.

Doubtless many, many other apps have also made that same mistake, yet I highly doubt it has made the difference between success and failure for even a single one of them.

All of those OS features were introduced to help people, because people wanted them, some even needed them. I don't think we live in a worse world for having them, and I believe that dealing with features like those would actually be even harder in a world without the Web.

[shantly]

Imagine: the original idea used to be you'd just supply a reasonably-marked-up document and maybe some formatting suggestions and the browser/user would pick the colors and fonts and such.

[baroffoos]

And those browser set styles were disgusting so people decided to just style everything themselves

[shantly]

To be fair, the styles they chose were almost never any better than the defaults until the early 2000s or so (and even then it was hit-or-miss) by which time the dream of the web as hyperlinked documents the user could view as they pleased was falling out of fashion in favor of making it flashy brochureware and, soon after, a tightly specified app distribution platform.

[Darkphibre]

I still remember how amazing Pepsi.com was in the mid-90s. They were doing tricks with images and tables even back then.

[kerkeslager]

Okay, but they only did that because browsers put tools like CSS/JS in their hands to let them.

I think it was a bad choice on the browsers' part. It's a totally abdication of the browser's responsibility to render things nicely and configurably for the user. Worse, javascript is bundled malware: you're letting websites execute arbitrary code on the user's machine.

Tracking, terrible website accessibility, and various dark patterns are a direct result of this. Instead of forcing websites to conform to a document format and giving users control over how that document behaves and is rendered, browsers given those powers to websites, and unsurprisingly, this has resulted in user-hostile behaviors. And it's not all peachy for websites either: websites can do a lot more with CSS/JS, but websites also have to do a lot more.

One of my side projects is a web browser which accepts various document types (i.e. image, slide show, article, login form) and renders them. Style/behavior is configurable by the user when possible, but the site serving the document has no control over styling/behavior--they only get to serve up documents which conform to the semantics of the document type. I doubt this will ever take off, but it's been an interesting and fun project so far.

[z3t4]

The trick is to make the base as simple as possible. A static page, no items hidden behind mouse clicks or hovers. Good contrast between text and background, make sure text is resize-able. No fancy div's or nested table's for layout - so the text can flow freely and adapt to any screen size.

Only problem - that is not what the market wants. Client: "why did you not implement the scrollbar-hijack/moving-blinking-text!?!?"

[vorpalhex]

Is it even a website if the videos don't autoplay and follow you, there aren't at least two modals urging you to subscribe to a newsletter, and at least one Amazon referral link?

[nattaylor]

As developers, can't we use progressive enhancement to support as many scenarios as we want?

[etaioinshrdlu]

You don't have to do any of those things. In fact the a good strategy is to use as little CSS and JS as possible and things will mostly just work, now and in the future, for all users.

[reaperducer]

That's 48 combinations to design and test for.

And then imagine if your web site is multilingual...

[jetako]

No need for dark mode if the canonical design is dark. I wish this was more prevalent.

[baddox]

Shouldn’t the color scheme be orthogonal to input methods, platforms, and device sizes? I can’t think of any times I have changed colors specifically for any of those things.

[crazygringo]

I can design the same dark color scheme for iOS and Android, but I've still got to code it twice.

Or use the same dark colors for mobile-size and desktop-size in responsive, but still need to test it to make sure I got all the <div>s that appear in mobile-size but get hidden and/or replaced by other <div>s in desktop-size and vice-versa.

Or discover we thought we'd covered everything, but when you use the normally-touch interface with a trackpad on Chromebooks, the default hover state is still light-mode.

Etc.

[suyash]

That's a nice way of breaking down the various designs one has to support, 48 is actually quite a lot.

[petemill]

Some teams will start with 'visual' design at the beginning of the process and, in that case, will do the ~48 mockups before any code is written (it's more because there aren't just 2 different screen sizes). It's a more satisfying (and perhaps cheaper) process to develop in stages:

- content hierarchy (what's important on one platform will rarely change between other platforms, despite the developer guessing otherwise)

- interactivity (the platform can most of the time cater to the differences in input if you lean on the platform capabilities)

- style

- Iterate and Perfect on the 48 versions

[cerberusss]

I don't think it's a problem; the Wordpress people fix it once in their most popular themes, which then immediately fixes it for 30% of the web.