[switch]: Naming of the component and it's parts

[gfellerph]

There is a draft pull request for adding a switch explainer: #785.

It contains assumptions for naming the element itself as well as it's inner parts. With this issue, I'd like to get feedback and clarify the naming of these things.

Element:
Proposed: <switch>
Alternatives: <toggle>, <toggleswitch>, <lightswitch>, <togglebutton>, ...

Active state/pseudo class:
Proposed: <switch toggled> and switch:toggled { ... }
Alternatives: <toggle switched>, <switch checked>, ...

Do you toggle a switch or switch a toggle?

Anatomy:
Proposed:

<switch>
  <track>
    <toggled></toggled>
    <untoggled></untoggled>
  </track>
  <thumb></thumb>
</switch>

Alternatives: many

[css-meeting-bot]

The Open UI Community Group just discussed [switch]: Naming of the component and it's parts, and agreed to the following:

• RESOLVED: call the new element `<switch>`, and land that in the explainer. Discuss the sub-parts later.

The full IRC log of that discussion

<hdv> philippgfeller: the proposal is still in draft mode… not sure how ready we are to get a resolution on something… 
<hdv> philippgfeller: editing the draft I made some broad assumptions on naming things, so wanted to throw it out there
<masonf> q?
<masonf> q+
<Luke> q+
<hdv> philippgfeller: to see what you think… starting with the element itself… I named it `<switch>`, but could also be `<toggle>` or anything else… am not a native English speaker so not sure
<hdv> ack mas
<hdv> masonf: one definite proposal that is on the table is to reuse the `<input>` element
<hdv> masonf: it does negate some of the cases you propose because `input`s can't have children
<hdv> philippgfeller: I think greg proposed to have both `input` and `<switch>` , `input` for simple cases and the `<switch>` element with more detailed applications
<hdv> philippgfeller: like if you need animations to reveal something… I did analysis on the most popular design systems, many could be done with just the `input` element, but there are also some that can't, like ones that have text (and pseudo would be a bit hacky)
<hdv> masonf: hacky because of positioning?
<hdv> philippgfeller: not sure
<masonf> q?
<hdv> masonf: I guess I'm curious… what percentage of use cases do you think we could cover with `input` rather than `<switch>`
<scotto_> q+
<hdv> philippgfeller: in HTML it would be easier to do things like translation
<masonf> ack Luke
<hdv> Luke: if we were to go the new element route… `<switch>` is the name I would go for because it would match with the ARIA role… it is the simplest… `<toggleswitch>` is kind of superfluous
<hdv> Luke: as a web developer I would prefer a new element rather than having it on an `input` element… because `input` has a lot of history to it that has issues behaviour wise
<hdv> Luke: this new thing would not have all that history
<hdv> masonf: the proposal of using the `input` has the nice advantage of having a checkbox as a fallback even in browsers that don't know what the new attribute is
<hdv> Luke: personally… I would say no as a polyfill could relatively easily make a fallback
<hdv> Luke: maybe you would want to go for a completely different element anyway in that use case
<masonf> q?
<masonf> ack scott
<jarhar> q+
<hdv> scotto_: I'm on the queue to say not call this a toggle in any way
<hdv> scotto_: the intend of this is to make a switch
<hdv> scotto_: a togglebutton is a very different thing
<hdv> scotto_: a toggle button is like, in a text editor, to make content bold or italic or something… that would be buttons with `aria-pressed`, as opposed to `switch`… pedentically semantically there are differences in meaning, but those differences mean a lot
<hdv> scotto_ they give different aural queues
<hdv> s/scotto_/scotto_:
<hdv> scotto_: I would not want people to come across `switch` and use it to create a `toggle`
<hdv> masonf: are there other use cases for `input` with `switch` attribute that you can think of?
<hdv> scotto_: people keep trying to turn it into something that is not a switch, like by adding extra things to it, like intermediate state etc
<hdv> masonf: proposal has no intermediate state
<masonf> q?
<hdv> scotto_: yes, and that's good
<masonf> ack jarhar
<hdv> jarhar: I just took a look at the explainer… I see there is some videos of switches that currently exist… it seems like most of them put some text or symbol on top of the thumb or one of the slider text
<philippgfeller> +q
<hdv> jarhar: that seems one of the use cases… people want to have an SVG, image, text, things like that
<scotto_> q+
<hdv> jarhar: I wonder if anyone would have anything to say if this would be dramatically worse to put that kind of content in a `content` property of a pseudo element
<hdv> ack phil
<hdv> philippgfeller: the videos are a little bit suggestive… I did an analasis… 70% of design systems I looked at don't use text or image… the others did, that's the ratio we're looking at
<hdv> masonf: so the majority of use cases doesn't need it… but then some of the cool/fancy ones do
<masonf> ack scott
<hdv> scotto_: 'on' and 'off' localised in lots of languages is not going to work for everything
<hdv> scotto_: maybe this is not something that browsers should do by default
<philippgfeller> Ratios of features used https://deploy-preview-785--open-ui.netlify.app/components/switch.explainer/#slots
<hdv> scotto_: in many it looks like an `i` or `o`
<hdv> scotto_: so probably better adjusting it for the different locales
<philippgfeller> q+
<dbaron> Agree that the layout implications of localizing the Choose File button in <input type=file> have caused problems in the past...
<masonf> Note that it looks like a 1 or 0, not an i or o. (At least that's how I remember it.)
<hdv> scotto_: the other thing is… whatever is in there, you don't want that exposed to assistive technologies
<gregwhitworth> q+
<hdv> scotto_: I'm not against this… I just think the initial proposal should make it very clear that if you're going to do it differently, you're on your own
<masonf> ack philip
<hdv> scotto_: not to say that people can't do good things with them, they can and should if they want to
<Luke> q+
<hdv> philippgfeller: the plain switch would just be a switch with no content, so if people want to put text in there they need to localise it
<masonf> ack greg
<hdv> gregwhitworth: I want to make sure we define it will initially be empty … the default should have an expectation that the majority of the use cases have designed aesthetic, we should do it in a way that has, like `aria-hidden=true` on there
<hdv> gregwhitworth: we should concretely that that's how it is implemented
<hdv> gregwhitworth: if people do want to do a localisation scenario where it's on/off, they would need to also do that themselves
<hdv> gregwhitworth: dev tools could even do warnings there to convey that to devs
<masonf> ack Luke
<gregwhitworth> q+
<hdv> Luke: it's possible that Safari would want to have symbols in their switches, as they do on their platforms… triggered by, I think, the 'differentiate not just by colour' setting
<hdv> gregwhitworth: this goes back to last week's discussion re standardisation of mobile selectlist
<hdv> gregwhitworth: we would standardise the entire anatomy
<hdv> gregwhitworth: Apple would ship the same thing everybody else would ship
<hdv> gregwhitworth: if people put in an argument to say there should be in the anatomy what Apple has on platform today, that would be fine and we could standardise on it
<masonf> q?
<masonf> ack greg
<hdv> masonf: what are we looking for in terms of conclusions/resolutions?
<gregwhitworth> +1
<hdv> masonf: I think at Open UI we should be easier on landing… this one is still in draft, hope we can land it soon
<hdv> masonf: would like to request that the explainer mentions the other proposal (input type=checkbox with `switch` attribute), and explain how it is different from that
<hdv> masonf: I worry if they don't come together, neither would land
<hdv> masonf: I'd like to resolve let's land the explainer… and also maybe resolve to add that differentation
<hdv> gregwhitworth: is the goal to land this explainer?
<masonf> Proposed resolution: add a section to the explainer to discuss <input type=checkbox switch>, and then land the explainer.
<hdv> philippgfeller: yes
<jarhar> q+
<hdv> philippgfeller: there is a link to the input[type=checkbox] with `switch` attr, but not a detailed description
<hdv> masonf: would love to see that detailed analysis of which examples, which you have many of, which is great, need which pattern
<hdv> jarhar: based on what we were saying earlier, it sounds like people like `<switch>` as a name, we could do a resolution for that too?
<masonf> Proposed resolution: call the new element `<switch>`
<hdv> masonf: I heard `<switch>` a lot and a lot of others that people didn't like
<hdv> gregwhitworth: we can resolve on the sub parts later
<hdv> masonf: I think we need a resolution that this direction is the right way to go
<hdv> gregwhitworth: agree
<masonf> Proposed resolution: call the new element `<switch>`, and land that in the explainer. Discuss the sub-parts later.
<Luke> +1
<hdv> +1
<philippgfeller> +1
<masonf> RESOLVED: call the new element `<switch>`, and land that in the explainer. Discuss the sub-parts later.