[wp-trac] [WordPress Trac] #63468: Dark mode support for WordPress embeds

[WordPress Trac]

#63468: Dark mode support for WordPress embeds
-------------------------------------------------+-------------------------
 Reporter:  meszarosrob                          |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  6.9
Component:  Embeds                               |     Version:  4.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback has-          |     Focuses:
  screenshots needs-design                       |
-------------------------------------------------+-------------------------

Comment (by meszarosrob):

 Replying to [comment:6 sabernhardt]:
 > Themes and sites might benefit from a standard dark mode if it is added
 with a new filter, `add_theme_support()`, or a separately enqueued (but
 inline) stylesheet. I do not think dark-mode colors belong in the same
 stylesheet as the rest of the embed styles because they would not fit well
 with **all** sites.
 >
 > Using the `prefers-color-scheme: dark` media query could work if the
 theme sets a dark mode exactly the same way. However, themes can [...]

 I agree that WordPress themes and sites would benefit from a standardized
 dark mode. However, I wouldn't strongly link that to the topic of dark
 mode for embeds.

 The way I see it, while a WordPress site can embed its own posts, it's
 just one of many sites on the internet that might do so.

 To me, the primary use case for embeds isn't for a site to embed its own
 content, but rather to make it easy for others to include it.

 Based on my experience, very few WordPress sites actually customize the
 default appearance of their embeds. As a result, in most cases, there's
 already disconnect between a site's design and how the embeds look. And
 everybody seem to be okay with that.

 In my opinion, whether this makes sense at all comes down to accepting the
 fact that today it's expected for UIs to be presented in either dark or
 light mode based on the user's (system) preference.

 If we subscribe to this idea, then since we don't know in what contexts
 WordPress embeds will be displayed, we should assume they appear in
 contexts that honor the user's (system) preference, regardless of whether
 WordPress offers a standard dark mode for themes or sites.

 However, I'm not sure if it's really the expectation of the world just
 yet. What I do know is that, a few years ago, there were considerably
 fewer sites and applications offering any choice compared to today. When
 it comes to my experience with mobile applications, I rarely see any that
 don't honor my preference.

 In addition to offering dark mode based on `prefers-color-scheme`, or as
 an alternative, having a parameter like `?theme=dark|light` could also
 solve some problems and address certain use cases.

 Let me know what you think :-)

 > Regarding the patch:
 > - Elements in the share dialog—including `dashicons-no`—are already
 light against a dark background, so this would not need to define new
 colors there.
 > - [50025] assigned colors from the
 [https://codepen.io/ryelle/full/WNGVEjw admin color palette], and a dark
 mode could use the same palette.
 > - [...]

 I added another patch that chooses the colors from the palettes you
 mentioned.

 My rationale for choosing the colors from
 https://www.figma.com/community/file/1436359662053949167 was that they
 might (I'm assuming) eventually become the standard colors used throughout
 the platform, not just in the Editor.

 I personally really like this variation too. It was definitely worth
 trying to see how it looks. So, thanks for suggesting it.

 I kept the `dashicons-no` icon and added a hover state to match the
 behavior of the comments and share icons.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63468#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform