[switch] Should a switch proposal graduate to the web platform?

[gregwhitworth]

While investigating the checkbox we found some sites had a toggle or switch state for their checkbox. This is not necessarily surprising as it can be seen here as well in the [switch](research concepts page).

I think to fully answer this question however there will need to be a bit more research as I'm truly asking from a graduation perspective. I do feel that based on the amount of systems that have a toggle or switch that a spec for a good switch component should be within Open UI. I do feel that that is a good argument for having on in the platform but there are certain push backs on this given how close the semantics of a checkbox & switch are.

I'm creating this to get others to weigh in and hopefully provide further research PRs into site to help inform the direction.

[una]

Toggles are very popular. They are often a component that a design system provides because there is no 1-to-1 styled mapping to existing HTML, so +1 I do think they're a good candidate for HTML 👍🏼

How should we track this between here and whatwg?

[chrisdholt]

Agree with @una - name can be discussed at a later date; my bent is to go with "switch" per the respective ARIA role and the fact that "toggle buttons" are also a concept but fundamentally different. Either way, I'm in agreement on moving this forward from a process standpoint.

[gregwhitworth]

I tend to agree as well. As it relates to graduation, @blittle and myself have worked out a game plan around checkbox and this seems like one that can piggy back on that one given how much overlap exists from a behavior perspective.

[gregwhitworth]

This was discussed in today's telecon with the following resolution:

RESOLUTION: Open-UI should have a separate Switch blueprint proposal

Minutes are here

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[css-meeting-bot]

The Open UI Community Group just discussed [switch] Should a switch proposal graduate to the web platform?.

The full IRC log of that discussion

<brecht_dr> masonf: There are a ton of issues related to this
<brecht_dr> masonf: There is some research, but the reason that this is on is that a PR has been made with a switch attribute for checkbox
<brecht_dr> lilyspiniolas: The proposal contains a new switch attribute only on the checkbox state
<masonf> q?
<masonf> ack brecht_dr
<brecht_dr> lilyspiniolas: We want a native looking switch, or what browsers decide to do. I shouldn't match the indetermittend select either
<masonf> q?
<jarhar> q+
<una> q+
<masonf> q+
<brecht_dr> lilyspiniolas: The good part is that it could fallback because there is still a type even when a browser doesn't know the switch attribute
<brecht_dr> jarhar: This proposal doesn't introduce any affordances, is that right?
<brecht_dr> lilyspiniolas: yes, but we ideally want to add pseudo classes. one for the thumb and one for the track
<Philipp_Gfeller> q+
<brecht_dr> jarhar: sounds Interesting, It would be good to collect more usecases to decide the styling for this. Maybe a pseudo would be enough. I think we need to collect some more use cases as well
<masonf> ack jarhar
<scotto> q+
<brecht_dr> una: I see the need for a switch for the platform. There is a lot of history on this. Is there any additional background on what happened since the start or older html issue
<brecht_dr> masonf: not really
<masonf> q?
<masonf> ack una
<brecht_dr> una: It could be useful to gather use cases, for example air b&b there is a special use case. So there are many use cases
<flackr> q+
<brecht_dr> una: would love to see the customisation options for this
<ntim> q+
<masonf> nice explainer PR: https://github.com//pull/785
<brecht_dr> masonf: I agree there is a strong demand. We do need something with stylability and not just user agent styled. Appearance: none is not stylable as you just reset everything completly and are just styling a div
<brecht_dr> masonf: Should a toggle button be a form control is a question that is still open
<brecht_dr> una: It can also be used for filtering, so used as both a direct action or a form control
<masonf> ?
<masonf> ?
<masonf> q?
<masonf> ack masonf
<masonf> ack Philipp_Gfeller
<masonf> See, e.g. https://freefrontend.com/css-toggle-switches/
<brecht_dr> Philipp_Gfeller: I like the idea for the backwards compatibility, but when it comes to more sophisticate styling for example moons turning into suns for dark mode toggles, i feel some limitations
<brecht_dr> Philipp_Gfeller: especially be only using psueo classes. Personally, I think a <switch> element would be good to have
<masonf> ack scotto
<brecht_dr> Philipp_Gfeller: but one doesn't have toe exclude the other
<brecht_dr> scotto: The backwards compatibility is a win. progressive enhancement is nice.
<brecht_dr> scotto: What i wonder about: How out of the box do we want these heavy animations, for example nested elements inside of a switch. Nested elements inside of a switch element could be problematic
<Philipp_Gfeller> +q
<masonf> ack flackr
<brecht_dr> masonf: To clarify: common styling should be easy, that's the important part for me at the moment
<brecht_dr> flackr: Often switches can be swiped for example, but not with checkboxes. There are way more customisable points when it would be an element instead of an attribute
<masonf> ack ntim
<brecht_dr> ntim: The only reason that you want a new element would be slotting other items inside the switch, right?
<brecht_dr> masonf: If there is an explainer with the pseudo elements, that would be super helpful
<masonf> ack Philipp_Gfeller
<brecht_dr> Philipp_Gfeller: I've seen a lot of child elements inside the switch, for example with labels that are hidden behind the thumb
<brecht_dr> scotto: I was looking at that, but how do you do this without adding paragraphes in that
<masonf> q?
<brecht_dr> scotto: Is it important that it is a child of a swicht, or is it enought that it could be pseudo or sibling content. When you need to localise text for a switch, it could be an akward kind of control when the width gets handled by the browser
<brecht_dr> masonf: Switch doesn't have any text on it, unless provided by the developer
<brecht_dr> lilyspiniolas: This was helpful feedback
<brecht_dr> masonf: There is a draftpr, an issue etc. Let's try to bring these concepts together into a simple explainer
<masonf> topic
<brecht_dr> brecht_dr: that could be the resolution right?
<masonf> topic foo

[tabatkins]

I shouldn't match the indetermittend select either

Indeterminate switches aren't too uncommon. With a light/dark theme switcher, for example, the default "system's choice" is sometimes represented with the switch in the middle, and that does match the "indeterminate" state reasonably well. However, it's currently impossible to revert a checkbox to indeterminate via user action, so that's awkward.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.