Toggle switch

[heruan]

What about including a toggle switch theme for vaadin-checkbox?

This is for example a CSS-only theme:

Fiddle: https://jsfiddle.net/heruan/g0tx9f29/

[jouni]

Sounds alright – thanks for the example! This has been on the “bucket list” from the beginning, with the name of “toggle-button” (corresponding to <paper-toggle-button>).

I’ll probably want to go through the visual design before actually merging, though ;)

I’m also wondering about accessibility – is there something extra that we should do for keyboard users, like support arrow keys for toggling it? And does anyone care about dragging the toggle or is tapping always enough? Though, these are aspects that we can be solved later – we can start with smaller increments.

[heruan]

This has been on the “bucket list” from the beginning, with the name of “toggle-button” (corresponding to <paper-toggle-button>).

So this shouldn't be a <vaadin-checkbox theme="switch"> but a brand new <vaadin-toggle-button>? But isn't button a wrong term for this kind of element? I mean, a button is something that you press but doesn't change its state (e.g. when you release it pops back at its initial position); this is more like a switch, i.e. something you can toggle on/off.

I’ll probably want to go through the visual design before actually merging, though ;)

Of course, mine was just a fiddle not a proper PR 😃 Before issuing a PR I wished to know:

1. should this be a theme for vaadin-checkbox or a new element?
2. if this should be a new element, should it have its own repository or live in this one instead?

is there something extra that we should do for keyboard users, like support arrow keys for toggling it?

In my example it's just CSS so you can still focus it with TAB and toggle it with SPACE or ENTER.

And does anyone care about dragging the toggle or is tapping always enough?

Good question! Never tried to "drag" a switch element, sincerely. What do you have in mind? Something like a "dimmer", to set a fractional value?

[jouni]

Here’s my take on the visual design:

The sizing is so that the width is --lumo-size-l (44px) and height is --lumo-size-xs (26px)

What do you think, should we adjust the label position to be before the toggle/switch? And if the user sets the width of the host the toggle/switch would always be at the end (making the label part flex)? I think that’s perhaps a more common layout for a toggle/switch, rather than having the label follow the

What about two-line label? Should we align the toggle/swith on the baseline of the first line, or center it with the whole label? See the same question for radio-button: https://github.com/vaadin/vaadin-radio-button/pull/61#issuecomment-388143243

[heruan]

I've updated the fiddle with your design: https://jsfiddle.net/heruan/g0tx9f29/

But again, that's just a theme for the plain vaadin-checkbox and currently it does not support a label (I'm using the part="label" to as the sliding circle).

I'm attempting to answer my questions in the previous comment:

1. this should not be a theme for vaadin-checkbox, since it does not permit representation of the indeterminate state (at least it shouldn't, IMHO);
2. it could share a lot of vaadin-checkbox, maybe really being just a theme for it encapsulated in a new element which does not expose the indeterminate property.

[jouni]

Good question! Never tried to "drag" a switch element, sincerely. What do you have in mind? Something like a "dimmer", to set a fractional value?

No, no fractional values, always “on” or “off”. But the original iOS switch allows you to “swipe” the toggle, and some web implementations allow that as well. So you can grab the sliding part and slide it over to the other side. If you leave it somewhere in the middle, it snaps to the closest state. Or it doesn’t necessarily have to even move before you cross the threshold with the mouse/finger and only then snap to the other state.

currently it does not support a label (I'm using the part="label" to as the sliding circle).

It’s possible to implement it so that we can still have a label (which you probably know as well).

The indeterminate state is one reason to not have this as a theme variant. Though, not a blocking issue IMO. We could just have that as “unsupported” at first. If someone has problems with that, we can extract a separate element.

A dedicated <vaadin-switch> element would make more sense, though, as it would make it clearly visible in the component listing on vaadin.com and webcomponents.org

I noticed you added a little box-shadow to the circle. It looks nice, but I’m not sure we want that, as none of the other similar components have any shadows defined. Though this is what I wondered in iOS 7 as well, that everything else is flat but the switch has a shadow 😄 Since Lumo is anyways somewhat close to iOS, we could follow the same styling here.

It also makes for a little added visual differentiation for the disabled state:

[jouni]

Nitpick: the off state bg color should be contrast-40pct (not 30pct).

Also, Material Design calls these “switches” nowadays. That’s why I propose we use that as well, and not “toggle button”.

[abdonrd]

@jouni in fact... https://github.com/PolymerElements/paper-toggle-button/issues/71

About the dragging, the paper-toggle-button also supports dragging.

[heruan]

But the original iOS switch allows you to “swipe” the toggle, and some web implementations allow that as well.

If we rely on the checkbox state, then somehow the checkbox itself should change state on swiping (with particular attention to the swipe direction, too); no idea how to do this, though 😄

I noticed you added a little box-shadow to the circle. It looks nice, but I’m not sure we want that, as none of the other similar components have any shadows defined.

Gone!

It also makes for a little added visual differentiation for the disabled state:

Which color should I use? I tried --lumo-contrast-20pct for the off state and it looks quite the same as the mockup; for the on state, --lumo-primary-color-50pct nor --lumo-primary-color-10pct seem right so maybe we need to add more variants in the lumo-color module.

[jouni]

The swiping is something we can add in a later version – no need to worry about that in the first version. Let’s see if we/users really even need it :)

---

I was implying we could leave the small shadow for the circle, but remove it when it’s disabled. That’s how it is in the latest mockup I added.

The colors I used for the background:

• Enabled:
  • Off: Contrast 40%
  • On: Primary color 100%
• Disabled:
  • Off: Contrast 20%
  • On: Primary 30% – this one we don’t have as a variable. I was wondering if we could use a pseudo element and opacity here?

[heruan]

I've rewritten the fiddle starting from the Lumo checkbox (not the unstyled one), so that it can be simply included as a custom theme and applied to <vaadin-checkbox>.

Plus, it inherits Lumo common styles and effects from the original checkbox like hovering and glowing when activating.

I've also added a label-left theme to align the label to the left.

Here's the updated fiddle: https://jsfiddle.net/heruan/g0tx9f29/4

[Juchar]

Are there any plans for a <checkbox-group> theme that looks like a button group? Example: Bootstrap Button Group

[web-padawan]

@Juchar thanks for the suggestion. That's something worth considering.

One concern is that I'm not sure how well does it fit Material guidelines. There is a Toggle button concept but it seems to be more like a radio group (only one option can be selected at a time).

[jouni]

See https://github.com/vaadin/vaadin-button/issues/86 for button groups.

[Juchar]

@jouni This seems to be related to just create a group of buttons, but would not fulfill the use case of a "toggle" button group where one can switch true/false states, right?

[jouni]

@Juchar, I think that’s up for discussion/design if buttons should have a toggle state as well.

I’m mostly concerned about trying to make checkboxes look like buttons. To get rid of the normal checkbox styles (so that we don’t need to override them) I think we’d need to extend Vaadin.CheckboxElement and apply the lumo-button style module instead. Not sure how well that would work, as the HTML templates for buttons and checkboxes are not the same.

Not sure if that’s the easier approach or would it be easier to add a toggle state for <vaadin-button>…

[Juchar]

@jouni I completely understand what you mean. As you said, that's an architectural design decision that vaadin would have to make.

Not sure what would be better tough.

[rolfsmeds]

Article about toggle button groups and a11y, probably also relevant here: https://lea.verou.me/2022/07/button-group/

[rolfsmeds]

Note that a theme variant (of Checkbox) is insufficient for this since switches needs a different ARIA role for WCAG conformance: role="switch" (see https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/switch_role)

[rolfsmeds]

Adrian Roselli article about switch implementation: https://adrianroselli.com/2021/10/switch-role-support.html TL;DR: We should base it on <button> rather than <input type="checkbox">.