
Material Design Guidelines for Dark Mode - keyle
https://material.io/design/color/dark-theme.html
======
del_operator
Working on a dark theme UI, currently. I appreciate our design team developing
rules around this, many similarities, and creating easy to use components and
types to rapidly develop new dark theme features. They also iteratively
extract and standardize more reused and mature UI components into a design
lib. It’s nice to be able see those in isolation with various states and
config.

------
duxup
That little circle plus menu button always seems out of place to me, just
really disconnected.

------
Kiro
I hate Material Design but this looks great. Where can I find a Bootstrap
version?

------
lowdose
Is it my perception or is the purple colour off?

It's almost as if Apple beat Google with their Mojave dark theme with shades
of green. Now the material design spec cannot be associated with the same dark
/ green... except for the plus thumb button on the bottom left.

------
thorgilbjornson
Does this mean that Google's disappointing lack of dark mode support will
change? It's pretty disappointing, given that they themselves have admitted
that their omnipresent white drains device battery life faster.

~~~
gipp
They announced coming dark mode support like 6 months ago. Android Q has it
system-wide.

------
dugluak
In the System Icons section they have this tagline "Simplify icons for greater
clarity and legibility." below an abstract icon of a so called ship -
[[https://material.io/design/iconography/system-
icons.html?ima...](https://material.io/design/iconography/system-
icons.html?image=https%3A%2F%2Fstorage.googleapis.com%2Fspec-host-
backup%2Fmio-
design%252Fassets%252F1-B6ynw_4lfpDkAmZ__Bn7FMXNUO5qMOx%252Fsystem-icons-best-
practices-07.png#system-icon-metrics)]

Which I think is ironic.

Because if you see just that icon it's really hard to recognize what it is, I
bet many won't see a ship it (at least I didn't). Only because of a realistic
ship icon shown next to it that one realizes that it is in fact a ship.

------
gnicholas
> _Caution: On OLED screens, turning pixels on and off can cause a delay when
> the screen is scrolled, making the pixels blur._

Never knew this, but I do recall seeing the blur when scrolling iPhone Xs in-
store.

~~~
theodorton
This goes both ways, so we should avoid completely black text. I might be
wrong, but scrolling on HN on iPhone X seems to produce some weird effect as
well.

------
komali2
This makes me think of my favorite vscode theme: Default High Contrast.
[https://code.visualstudio.com/docs/editor/accessibility](https://code.visualstudio.com/docs/editor/accessibility)
You can see it there if you scroll down.

It reminds me of old vector graphic games like Tempest. I don't know much
about design, but I feel like it's "harder" to contrast with black than white,
and so the bright lines of color against the black background actually give me
happy feelings. Weird, but I genuinely think it improves my coding experience.

I like it so much I've been slowly porting the theme to Emacs:
[https://github.com/komali2/Emacs-VSCode-Default-High-
Contras...](https://github.com/komali2/Emacs-VSCode-Default-High-Contrast)

When I have some spare time I'd like to sit down and actually learn more about
design concepts around these kinds of dark high contrast visualizations, and
old vector graphics. Ideally I'd like to learn how to incorporate them into my
own web and game design... one day!

~~~
tozeur
That’s also my favorite theme! I love the simplicity. If only they had a
slightly less contrasty version of it, I’d use it 100% of the time.

------
simplesleeper
Reds should be used instead of neon colours, to preserve night vision

------
chvid
Page is white and empty except for a top bar in Safari / Mac ... there is an
error in the js console ...

------
huxflux
Ping @MicrosoftOutlookAndroid/IOS - Make this happen!

------
pcl
Doesn't load for me in Safari, but works in Chrome. From the JS console:

    
    
        ReferenceError: Can't find variable: IntersectionObserver

~~~
jhoh
That's just Apple not implementing modern web standards. Just wait a couple
months or years and they might implement the IntersectionObserver. Until then
you'll have to use polyfills to support Safari which Google obviously didn't
do here.

~~~
fells
Or travel back in time a month. It was added in Safari 12.1.

[https://webkit.org/blog/8718/new-webkit-features-in-
safari-1...](https://webkit.org/blog/8718/new-webkit-features-in-safari-12-1/)

~~~
jhoh
Wow, just two years after Chrome, Firefox, Opera and even Edge added it!

[https://caniuse.com/#feat=intersectionobserver](https://caniuse.com/#feat=intersectionobserver)

------
Uptrenda
Is there anything like a web standard for theming? I.e. you have a browser
that makes a query to some standard interface for supported themes on a
website and it would automatically choose the type that you prefer. Values
could be things like high contrast mode, dark mode, or even minimal (that was
largely text-only.) Then there would be auto-magic dark mode on all major
websites.

~~~
scotchio
@media (prefers-color-scheme: dark) {}

Mixed with root variables

~~~
guessmyname
Safari Release 81 renamed “supported-color-schemes” to “color-scheme” [1].

But it seems that “prefers-color-scheme” is still, well, preferred [2].

[1] [https://developer.apple.com/safari/technology-
preview/releas...](https://developer.apple.com/safari/technology-
preview/release-notes/)

[2] [https://caniuse.com/#search=color-
scheme](https://caniuse.com/#search=color-scheme)

~~~
tambre
_supported-color-schemes_ is a HTML tag indicating if the website supports
dark mode (useful for auto-darkening support) and the media query is for
actually implementing it.

------
saagarjha
> The higher a surface’s elevation (raising it closer to an implied light
> source), the lighter that surface becomes. That lightness is expressed
> through the application of a semi-transparent white overlay.

This is a strange choice, considering that the guide has a very strong
discouragement against emulating shadows…

~~~
Kamshak
What do you mean by discouragement against emulating shadows? As I read it the
shadows stay the same as on the light theme. Are you referring to what they
call "glows"?

> In a dark theme, components retain the same default elevation levels and
> shadows as components in lighter themes

It looks pretty good in the examples they give IMO. Considering that the
default makes such heavy use of elevation it makes sense to keep that concept
in the UI.

> Default themes use shadows to express elevation, while a dark theme also
> expresses elevation by adjusting the surface

~~~
saagarjha
I can't find it anymore, but the Material Design Guidelines had a thing at
some point which warned against emulating shadows in place of actually
changing elevation.

~~~
soulofmischief
Well, all CSS shadows are emulated. CSS doesn't have a lighting engine. The
docs you are thinking of [0] suggest that elevation is suggested by shadow
morphology. Actual elevation in CSS (3D translations along the Z-axis) is
useful for scaling effects to create a sense of perspective, but Material
guidelines dictate you should just keep it simple and emulate a light source
from which you derive a set of emulated shadows.

What works for me in this case is a Sass mixin which accepts a layer as an
integer in the range 1-N and casts a shadow based on that layer and the total
depth N. Consistency is key.

[0] [https://material.io/design/environment/light-
shadows.html#sh...](https://material.io/design/environment/light-
shadows.html#shadows)

[1]
[https://material.io/design/environment/elevation.html#depict...](https://material.io/design/environment/elevation.html#depicting-
elevation)

------
glup
Dark mode comment: in the last week of traveling, I have been asked twice by
strangers in airports what programming language I am using. In both cases I
was writing an email in OS X mail in dark mode.

~~~
benatkin
Are you a developer? If so, you may have unintentionally provided subtle hints
to them that you're a developer. Everyone seems to be able to guess that I'm a
developer regardless of what I'm doing and whether or not I'm wearing a tech-
related t-shirt. If they think you're a developer, it's not surprising they
would be quick to leap to the conclusion that you're writing code.

~~~
komali2
My off the cuff guess: Someone saw a young person in casual clothing in an
environment that made it obvious they were non-local (i.e. a white dude in a
Chinese airport or something) in an off-season for tourism, and thought "well
they're either here for business or pleasure, and one of the few people that
can afford a pleasure trip in the middle of the year like this (money + time
off) is a developer."

Kinda fun to think about all the subtle clues we're giving off without even
realizing it. Of course any of these observations could lead to a totally
wrong conclusion, which makes me start to think of all the fun ways you could
"disguise" yourself in modern society.

~~~
filoleg
It might be even simpler than that. Add to the mix a Macbook with some
conference or software-related stickers and glasses, and there you got it.

------
mattdeboard
> Dark themes reduce the luminance emitted by device screens, while still
> meeting minimum color contrast ratios. They help improve visual ergonomics
> by reducing eye strain, adjusting brightness to current lighting conditions,
> and facilitating screen use in dark environments – all while conserving
> battery power. Devices with OLED screens benefit from the ability to turn
> off black pixels at any time of day.

Why is light UI the default if dark theme confers so many advantages?

~~~
otterley
I'm no UX expert, but my guess from experience is that most people use their
computers in bright environments; and dark backgrounds combined with glossy
screens have much more glare in bright environments than light backgrounds on
such screens.

~~~
bondolo
The brightness of the UI should match the ambient light in the environment.
Light UI in daylight, Dark UI at night. Brightness adjustments applied to both
based on the ambient light. Some people may also prefer hue adjustments (blue
reduction) for low ambient light along the lines of f.lux, Night Shift, Night
Light, etc.

------
gnicholas
The author suggests using dark gray instead of black, but then also says that
when pixels are completely deactivated on OLED, it saves energy. These seem to
be contradictory pieces of advice. What am I missing?

~~~
owenwil
In the accessibility section[1] they discuss the problem of using true black:
OLED Smudge. If you turn off OLED pixels and the display suddenly needs to
turn them back on, they usually are too slow to do so, and cause a visual
artefact that appears to the user as smudging up the screen—which can feel
like the display itself is broken. This occurs on most OLED displays,
including high end ones in devices like iPhone XS and Pixel 3, and is largely
why true black interfaces should not be used.

> "On OLED screens, turning pixels on and off can cause a delay when the
> screen is scrolled, making the pixels blur."

[1] [https://material.io/design/color/dark-
theme.html#properties](https://material.io/design/color/dark-
theme.html#properties)

~~~
ganzuul
People also dim their displays to save battery, making it look like the
backlight is broken.

Win some, lose some.

------
julienreszka
Probalem with dark themes are reflection on the screen

~~~
Zak
That can be an issue. I think dark themes are primarily intended for
environments with lower ambient light and fewer sources of glare, though matte
displays make them more usable in other conditions.

What this means is there should be an easily accessible, systemwide toggle
e.g. Android's quicksettings that asks apps and websites for the theme the
user wants at that moment. This is something I've wanted for years, and I'm
surprised I haven't seen more people calling for it.

~~~
julienreszka
GPS automatically changes theme when you go under tunnel why can't we do this
by detecting luminosity of the room?

~~~
Zak
We can, unless you're an app developer on iOS - Apple won't let you use the
light sensor.

------
spectramax
I have a deep rooted issue with design and designers.

In 90’s, skeuomorphic trend was picking up steam reaching a climax in
mid-2000’s. Web 2.0 design elements were springing up, taking advantage of
css; while UI elements sought transparency and blur (Windows Vista). That
trend passed and then we had the whole Material design boom in 2012-2015, the
entire web was sabotaged by Bootstrap. Color themes and palettes were very
popular. Cookie-cut banners, slideshows, carousels, headers, etc. Post
bootstrap world saw some radical shift in small circles: monospaced fonts,
brutalism, vintage homage and low-res shenanigans whilst the mainstream design
kept on drinking the material koolaid up until 2016.

Boom comes in Stripe with sleek blue-purple gradients, smooth animations,
Bumla-lizing the entire fucking internet. It is 2019 and every new Saas
service looks like Stripe, following trends like a mindless herd. The rest
unfortunate (or unskilled to match Stripe standards) are still catching up
with single page scrolling websites with full-width banners, stupid jumbotrons
and loud obnoxious typography.

Traditional graphic design has largely been “solved” by the 1960’s - aka, the
International style or the Swiss style for majority of needs. Of course you’re
not gonna have Univers on a grunge band poster. For the curious, google some
posters by Josef Muller-Brockmann from the 50’s - they still appear to be
designed in 2019. That’s timelessness (or cynically put, blandness). He
exemplified great understanding of contrast, scale and hierarchy in design to
convey information. I recently watched Dieter Rams’ documentary and he is just
completely disappointed by majority of design in the world. I am not a
designer but I feel the same way. Rams’ design will never be “outdated”
because his principles of design weren’t based on trends.

Let’s go Dark Themes! Also, next year is the death of jumbotrons. Mark my
words.

~~~
hbosch
I have a deep rooted issue with development and developers.

In 90’s, ActionScript trend was picking up steam reaching a climax in
mid-2000’s. Flash websites were springing up, taking advantage of animations
and sound; while UI elements sought transparency and blur (Windows Vista).
That trend passed and then we had the whole ES6 boom in 2012-2015, the entire
web was sabotaged by JavaScript frameworks. Frontend libraries were very
popular. Cookie-cut DOM abstraction, one-page apps, launchpad dependencies,
etc. Post JavaScript world saw some radical shift in small circles: Elm,
Crystal, demos and hacked shenanigans whilst the mainstream development kept
on drinking the JavaScript koolaid up until forever.

Traditional development has largely been “solved” by the 1960’s - aka, BASIC
or C for majority of needs. Of course you’re not gonna have FORTRAN on a
modern website. For the curious, google some books by Brian W Kernighan - they
still appear to be relevant in 2019. That’s timelessness.

__

In all seriousness, it's a mistake to say that 1 style -- The
International/Swiss Style -- can solve all of design's needs. You are
purposely forgetting that design relies heavily on taste. Not the designer's
taste, but the customer's taste. When I go shopping for organic shampoo, I
have an idea of what "organic shampoo packaging" looks like. It's beige,
probably has a plant on it, etc. Tastes change, and they change constantly and
organically. Changing tastes are a moving target for designers to hit, or if
they're lucky they can arrive there early. Also, it's a sign of "freshness" to
update your design from time to time. People expect things to update and "get
better", both visually and functionally. Similar to fashion, design does not
always have to be rationale and objectively beautiful -- it just has to suit
it's customer's tastes.

~~~
spectramax
I have to admit, this made me laugh more than I’m willing to admit.

It is a mistake to equate software development with graphic design. To compare
C with International Style sounds promising on the surface, rings all kinds of
bells but your analogy breaks down as follows.

Machine code > ASM > C > Java > Python > Django framework > Web apps > Saas.
This is a hierarchical abstraction. So comparing C to JavaScript is comparing
different abstraction layers. Writing C is not suitable for web apps so much
as designing a font from scratch to put a webpage together is not a productive
use of your time.

International Style is not a lower abstraction or “building” block for design.
It is a framework of principles.

~~~
magduf
The other factor is that the human brain has not substantially changed in 50
years, and design with the goal of conveying information efficiently is going
to rest on principles based on the way our brains work, and that isn't
changing.

