Checkboxes also happen to be one of the possible interactive components that suit our purpose anyway. The only reasonable choice is the :checked pseudo-class selector which allows styling a checkbox (or radio button) based on it’s checked state. Enabling the dark mode would only last as long as no other link that opens in the same window is used. However, this feature observes only interactions related to page navigation with URLs containing fragment identifiers. A more permanent way of reacting to a user interaction with CSS is the :target selector. However, a dark mode would not be very useful if it was only active for the duration a user hovers over a certain element. For example, the :hover pseudo-class selector is triggered when an element is hovered.
REDDIT CSS DARK MODE SWITCH SERIES
There is a series of CSS pseudo-class selectors allowing you to react to a user interaction. For a pure CSS implementation, however, it’s necessary to observe a user interacting with the page from within a stylesheet. I assume Mu-An chose a checkbox for one reason: Both switches and toggles require JavaScript to work thus, it would not be possible to provide a dark mode to users who have JavaScript disabled. 🔗 Jump to headingDesign objectives & constraints They were also responsible for the choice of link text in the previous section 👍. Does one have to confirm a changed setting by hitting a “Save” button or are things saved automatically?Ī quick rundown on when the three controls we discussed save their state was provided recently by Zoë Bijl. In particular, since the choice of enabling the dark mode should be saved, we have to ask when exactly such an interaction is saved. In a different context where many controls are part of a more complex widget like a settings page, it must also be considered what users expect when interacting with these controls. Of course, any mode that is lighter than the dark mode would fit the bill as well. It is implied that if the control was not interacted with, the dark mode is disabled hence, the current mode must be a light mode. Note how none of the controls deal with a notion of a light mode. More information on the topic of toggle buttons and switches can be found in Heydon Pickering’s fantastic resource about inclusive components. role="switch" or aria-pressed) will announce the type of control accordingly. Screen readers that support the relevant features (e.g. More precisely, for a checkbox or switch, the initial state is “dark mode, unchecked”, and for a toggle button it is “dark mode, unpressed”. All three allow the correct form of interaction where the initial state is “dark mode, not enabled”, and by interacting with the control, the state is changed to “dark mode, enabled”. The available components that are suitable for such a task are checkboxes, switches, and toggles. Optionally, that state is saved across sessions. The objective is to switch between two states, dark mode disabled and dark mode enabled. 🔗 Jump to headingInterface designĬonsider the choice of the interactive element from an interface design perspective. The CSS-only dark mode we’re building in this article is available on CodePen. That’s just a form of progressive enhancement and is not required for the functionality of switching to dark mode.
In essence, it swaps around some colors so that after enabling dark mode, light text sits on a dark background where before the body text was dark and the background light.Ī bit of JavaScript is used to store the user’s choice via the localStorage API.
From there, we will implement our own dark mode step by step.Ī checkbox at the top of her site enables a dark mode. Let’s have a look at it and by that I mean a detailed analysis. But first, I did a bit of view-sourcing of her neat no-JavaScript dark mode implementation. Recently, I stumbled over Mu-An Chiou’s cool little website and was inspired to redo my own. CSS-only dark mode – Enable dark theme Enable light theme ← Home April 8th, 2019 CSS-only dark mode
0 kommentar(er)
