There should be an indicator for "auto" state also; this is when the theme follows the operating system settings. (For example, where the OS switches to dark mode during night and light mode during day.)

Hi Alfie. Nice work, really like this package and been using it for a long time.

Today I was implementing a navbar, with mobile and desktop variants, and I created a ThemeToggle.jsx component and imported it into both variants, and noticed a bug with the animation.

I recreated it in a simple codepen. https://codesandbox.io/s/hopeful-wave-srvgy9?file=/src/App.js

I think it might have something to do with the CSS selectors? not too sure. I fixed it on my end currently by only rendering one variant of the navbar at a time (previously I was using CSS to hide). Would love it if you have the time to take a look :)

Not an issue per se; just a question. If I want to implement a toggle within a website that uses dark mode as its default, how can I reverse the toggle to assure that the dark mode SVG is the one presented initially? I'm using the HTML checkbox wrapper for the Within toggle.

It is great that the animations don't work when the user has indicated that they prefer no motion. However the even better practice is to only have animations when the user has indicated that they have no preference with respect to motion.

Great:

@media (prefers-reduced-motion: reduce) {
  /* Disable all the animations */
} 

Better:

@media (prefers-reduced-motion: no-preference) {
  /* All the animation code */
}

This is a safer default as users that are affected by motion and are on a system on which they cannot indicate this preference, will not have the motion applied and thus will not experience any ill effects.

It is also arguably a simpler approach, as all the animation code will be sequestered into the media query, as opposed to the animation code having to be disabled.

v5

Introduction

Version 5 is close to complete and so any community feedback will be greatly welcomed.

Checkout the current toggles https://63c6ef3f3a92fe99f4ff4386-gjfzipvoqj.chromatic.com

Main Changes

Everything

• - package renaming: theme-toggles now becomes @theme-toggles/core
• - Refactored build pipelines
• - Moving doc/website into this mono repo
• - Rewriting docs with nextra
• - Added storybook for toggle development
• - Redesigning all toggles to be clearer in smaller sizes
• - Redesigning 'unclear' toggles e.g. eclipse
• - Finish docs
• - Create a release pipeline
• - #19

@theme-toggles/core

• - Ability to toggle the toggles via .dark classes (makes integration with tailwind very simple) The current method still works and overrides this behaviour
• - Improved accessibility (more feedback is greatly welcomed)
• - Added outlines to checkbox/button
• - Checkbox keyboard interactions are working

@theme-toggles/react

• - Removed internal state handling
• - The toggle will respond to the global .dark class
• - The toggle accepts a toggled boolean which overrides the .dark behaviour

I used this as markup and called it classic CSS. but seems it's not working it works if I use the checkbox wah. Do I need to do anything else?

In the CSS for the checkbox solution, the checkbox is set to display:none;. This makes it impossible to reach and interact with using the keyboard. Using the screen reader only class on the checkbox in the HTML instead solves that issue.

Then there is a further issue that there is no focus indicator. This can be solved by adding an outline to the SVG when the checkbox is focused. You could use :focus-visible if you don't want the outline when people use a mouse.

your babel/svgr plugin for dynamic IDs overwrites hex colour values. I don't have time to do a full PR so here's the fix:

const t = require("@babel/core").types;
const template = require("@babel/core").template;

const getValueWithProps = (value, { prefix, suffix }) =>
  `${prefix ? "${props.idPrefix || ''}" : ""}${value}${
    suffix ? "${props.idSuffix || ''}" : ""
  }`;

const isHexValue = (possibleHexValue) => {
  return (
    possibleHexValue[0] === "#" &&
    !isNaN(parseInt(possibleHexValue.slice(1), 16))
  );
};

const getAttributeValue = (value, opts) => {
  let id = "";
  let prefix = "";
  let suffix = "";
  if (value && !isHexValue(value) && value.charAt(0) === "#") {
    id = value.slice(1);
    prefix = "#";
  } else if (value && value.match(/^url\(#/)) {
    id = value.slice(5, -1);
    prefix = "url(#";
    suffix = ")";
  }
  if (id) {
    return t.jsxExpressionContainer(
      template.ast(`\`${prefix}${getValueWithProps(id, opts)}${suffix}\``)
        .expression,
    );
  }
};

const getIdValue = (value, opts) =>
  t.jsxExpressionContainer(
    template.ast(`\`${getValueWithProps(value, opts)}\``).expression,
  );

const plugin = (api, opts) => ({
  visitor: {
    JSXAttribute(path) {
      if (!opts.prefix && !opts.suffix) return;

      const valuePath = path.get("value");
      const namePath = path.get("name");

      const value = valuePath?.container?.value?.value;
      const name = namePath?.container?.name?.name;

      if (name === "id") {
        valuePath.replaceWith(getIdValue(value, opts));
      } else {
        const attr = getAttributeValue(value, opts);
        if (attr) {
          valuePath.replaceWith(attr);
        }
      }
    },
  },
});

module.exports = plugin;

Hi,

the sentence "Our goal is to ensure the toggles remain as accessible as possible. This includes proper screen reader support." on your about page suggests that the examples on your website are accessible. Unfortunately, that's not the case. All of the examples are either inaccessible with the keyboard, a screen reader or both.
Since it took me only 5 seconds to learn that, I have to assume that accessibility or, at least, accessibility testing in fact isn't your top priority. That's fine, given that this is a OS project you maintain in your spare time, but claiming that accessibility is "your goal" is misleading, especially for people who don't know how to test for accessibility and trust authors like you.

Please consider removing the misleading statements about accessibility until you or someone else fixes the issues. If you need help with that, feel free to get in touch.

Thank you.

Hi, first of all, thanks for your work in this library, the toggles are great!

I'm using the react toggles and I've noticed that typescript complains about missing properties placeholder, onPointerEnterCapture and onPointerLeaveCapture.

Is this an issue with the types? Except if I'm missing something, I wouldn't expect those in here.

Hey and thanks for these toggles! Great work!

When implementing I came across the issue, that if you only provide two states you’re locking the user in the decision he/she has made on the site. As pointed out in a blog article I came across, theme toggles need a third option which lets you go back to the state where the system settings decides which theme to take.

I was wondering if this could be considered in one of your animations. My idea would be to have either a cog icon or a state of the icon that shows both at once, like sun and moon at the same time.

If that is too far out for you, it’s fine with me 😊.

Have a nice day!