Discuss how to customize appearance

[tkent-google]

CSS Shadow Parts or CSS custom properties?

[scottaohara]

Related: designers and developers often include the words "on" and "off" coupled with the switch.

While there's an argument that such a decision could be left up to authors, I think it'd be good if there was an out of the box option to print the current state.

Since the control itself should announce its state as "on" and "off", it'd be good to mitigate developers having to add in separate text reflecting the appropriate state, resulting in screen readers then potentially announcing "name of control, on, switch, on". The control should only need to announce its state once.

Personally, I prefer Microsoft's approach, where the state is printed outside of the control as it is far more suitable for different languages. Developers could then use CSS to position the text, provided by the control, as they need to.

Thanks

[gregwhitworth]

Again, thanks for prompting this discussion.

I've been digging into controls and components quite a bit lately and I think we have to standardize on the guts in order for these to be successful (I've spun up a repo to begin collating controls we plan to standardize here.

This can be done in a myriad of ways but we already see issues across the web where developers either want to add one additional thing or add a style that isn't reachable within the component. So I think shadow parts are the way to go. That said, style is only one aspect of appearance so I think that each piece should also be a slot itself. For example, here is a more extreme version of a switch control that I feel should be possible using this control if provided slots & parts.

I prefer Microsoft's approach, where the state is printed outside of the control

I think if we polled people we would get numerous different opinions and why I think we should make everything adjustable and where possible extensible. Although, for this one - let's not scope creep on the extensibility.

One final question @tkent-google, I was under the impression that UA based web components could have their shadow roots interacted with (is this incorrect)? Or are you bypassing this by utilizing this as module include?

[aardrian]

+1 on external text. I am wary of localization factors (including automated translation) and poor contrast decisions by developers.

[gregwhitworth]

To clarify my above statements, I agree that the solution that we have out of the box should be the best accessible option - so +1 to the external text. That said, I ultimately want authors to have free reign over the control so that they keep the majority of the good while not feeling like they're trapped to where they resort to creating their own (our current state of the web) which usually results in some type of accessibility issue (be it keyboard, name computation, color contrast, or all of the above).

[scottaohara]

completely agree @gregwhitworth and thanks.

I definitely don't want to go nuts with feature creep here / anything too flashy out of the box. But give authors a good base of the options we commonly see (a track, grip/knob, optional text, and maybe the allowance for ::before and ::after pseudo elements for each). That'd likely let people be well on their way to creating something like that extreme version you shared.

[jimmyfrasche]

Shadow parts and custom properties. A few custom properties if you just need to tweak the colors to fit your site and shadow parts for when you need more control.

When the label/color occupies the space where the thumb would be if it were in the opposite state, my first thought is always that I need to slide the thumb there to put the control into that state—I have to stop and remind myself that, no, it's like a light switch rotated clockwise so that's an indication of the current state.

It's worse than no label/color as it short circuits my intuition.

The MS approach of putting the label next to the control is much clearer to me.

[tkent-google]

We made a prototype and a demo page. https://tkent-google.github.io/std-switch/demo.html

The prototype supports some custom properties ---std-switch-*, and doesn't apply CSS Shadow Parts. I'm afraid exposing elements via Shadow Parts would make internal implementation change difficult.

As for text labels, I think <std-switch> doesn't need to support them, and web developers can make another custom element extending/wrapping <std-switch> to add text labels.

One final question @tkent-google, I was under the impression that UA based web components could have their shadow roots interacted with (is this incorrect)? Or are you bypassing this by utilizing this as module include?

I don't understand the intention of this question. Anyway, any built-in modules including <std-switch> should be built with public APIs.

[aardrian]

• There is no attribute aria-role. I think you meant role to get role="switch".
• Suggest adding a lang attribute to the <html> element. Not being nitpicky, but need it to be there to properly evaluate this with AT.
• The disabled attribute should be adjusted to aria-disabled to have its state properly conveyed to screen readers by the browser (it is not currently).

BTW, thanks for the demo.

[scottaohara]

As for text labels, I think doesn't need to support them...

Hi @tkent-google, just looking for clarification here. Do you mean text labels as in providing the switches with their accessible names? (i see in the demo the switches have been wrapped in a label which would be ideal if they were true HTML controls).

Or when you say text labels are you referring to my request to allow for the state to be displayed in a text format?

If the latter would you mind explaining why you don't think they are necessary to be supported?

Thanks

[domenic]

Note that proper accessibility support is blocked on whatwg/html#4658, although we can certainly add patches to make it easier to evaluate in the meantime, even if it won't be full fidelity like a native control yet.

In general the idea is that this should be like a built-in HTML control in all ways possible, including accessibility, label-ability, or how the presence of shadow stuff is unobservable (e.g. you can't notice that select or details or input type=date are implemented using shadow DOM in Chrome; same for std-switch).

I'm hopeful that we can still expose shadow parts (track and thumb). I think the predefined set of variables is a bit too limiting, for cases such as @gregwhitworth's demo. Exposing them would definitely constrain future evolution, but I think in practice it's more important that this be flexibly style-able, than that it be forever changeable. This is something to explore further, probably.

[aardrian]

Following up on @scottaohara's note, the <label> does not provide a larger hit area for the control, as it would for a native control, so some consideration would need to be made there as well.

[domenic]

Should we rename this thread to be broader and close all the other accessibility threads? It seems all the accessibility review is happening here, instead of talking about appearance customization.

[aardrian]

No. Appearance has an accessibility aspect. Closing the other threads does not resolve any concerns in those threads.

All parts of this control potentially have an accessibility aspect. If we try to move all accessibility concerns into one thread then as another discussion of appearance happens you can expect accessibility concerns will be raised in that discussion. I would rather not see the accessibility concerns relegated to a corner (like Baby for "Dirty Dancing" fans).

For example, using <label> has both an appearance aspect and an accessibility aspect. They are inextricably linked.

[scottaohara]

@domenic my comment is related to accessibility / UX of the control, but allowing for text of the visible state is also related to the customization of the visual appearance.

[tkent-google]

Or when you say text labels are you referring to my request to allow for the state to be displayed in a text format?

Yes, I meant text on the control like the image in your first post in this thread.
The reason is that such text is not used widely. Apple's design guide discourages it, and UISwitch on iOS doesn't support it. Switch in Material Design also doesn't expect such text.

If a web developer really needs to add such text, he/she can specify background images containing text to the control even with the current prototype, or can place text outside of the control on the control by position:absolute or relative.

However, I have an idea to make it easier. I updated the demo and the prototype so that we can add text by child nodes of <std-switch>.

[scottaohara]

Thank you for the response @tkent-google

A bit of a clarification regarding the state text though. You said "Apple's design guide discourages it", which is true, but that's because there's a built in option to display, and Apple is trying to discourage duplicate state announcements:

I appreciate you adding the slot to allow for authors to add this text equivalent of state, if desired. I've submitted another PR so as to ensure this optional text is not included in the accessible name for the control, thus not producing duplicate announcements of state.

[justinfagnani]

@tkent-google

The prototype supports some custom properties ---std-switch-*

I saw this and I'm curious how this is intended to work in production. I'm assuming that we wouldn't spec fluent and material values for --std-control-theme, yet CSS variables can't be selected against, so even with some shadow parts exposed I don't think it'd be possible to extend the set of values with just CSS.

and doesn't apply CSS Shadow Parts. I'm afraid exposing elements via Shadow Parts would make internal implementation change difficult.

Shadow parts are intended for this exact use case, so I hope we can find the right balance between customizability and encapsulation here. Otherwise, we have a lot of work to do still on styling primitives. Given that shadow parts only expose elements specifically marked, and not their children or context, I'm hopeful that the current ::part() implementation (outside of the obvious need for ::theme() here) is sufficient.

We did talk about property white- and black-lists at the last web components face-to-face, but there was nothing conclusive. Currently some protection of critical properties should be possible by have rules in the shadow root that select by part attributes.

[tkent-google]

Now I think preserving CSS custom property names by 'standard' elements would be harmful.
If standard elements refers to --std-* properties, it's difficult for web developers to use them for other purpose. 'CSS Custom Properties for Cascading Variables Module Level 1' specification doesn't define such UA-preserved property names, and web developers should be able to use any names starting with --.

[tkent-google]

In the latest Chrome Canary, <std-switch> has the following parts.

• track and thumb are siblings
• track-fill is a child of track

I think this structure is enough. We can customize std-switch appearance like the following image only with author's stylesheet.

(The source CSS is here)

[domenic]

Agreed, that seems to work pretty well. I think documenting it in the readme and closing this issue makes sense.

[gregwhitworth]

@tkent-google I'm not seeing this in canary, did the name change or was it reverted?

[tkent-google]

@tkent-google I'm not seeing this in canary, did the name change or was it reverted?

Chrome Canary has the implementation with the part names in my previous comment. It's still behind the experimental feature flag chrome://flags/#enable-experimental-web-platform-features and need import 'std:elements/switch'.