Will themes and their rendering be standardized?

[othermaciej]

The demo page illustrates a number of different themes for <std-switch> and has a particular rendering (including animations). Will the available theme names be standardized? Will exact details of the rendering and animation be standardized?

If theme names aren't standardized, and browsers support different sets, there is poor interop. If theme names are standardized but their renderings aren't, they are not useful to authors who want an exact appearance. If names and renderings are standardized, this is without precedent for form controls in the platform, and potentially problematic. Platform renderings change over time. Switches haven't always looked the same in iOS for instance. The standardized versions might not even match any platform, for example the cocoa theme in the demo does not accurately replicate the rendering or appearance of switches in any iOS version. Fully accurate replication in a polyfill may not even be possible without violating intellectual property of platform vendors.

A possible alternate approach: there is a default appearance (possibly platform-specific), and it can be fully overridden to be exactly what the developer wants using normal CSS. <input type=button> and <input type=text> de facto have this behavior (if not per any spec) and it lets browsers have a platform-matching default styling if desired, while also meeting requirements to have controls styled a specific way on all platforms in some site. <input type=checkbox> lacks this, which is why sites use either uncustomized checkboxes or div soup. Sites would likely not be satisfied with a canned set of predefined themes.

[tkent-google]

I don't think it's possible to standardize specific themes like the demo page. Asking WebKit to implement Material Design theme isn't reasonable.

As written in the explainer, we just need a flag to choose interoperable appearance or platform-specific appearance. The latter in Safari might be iOS-like one, and it in Google Chrome might be Material Design one.

[justinfagnani]

@tkent-google how do you imagine that might work? Some kind of web-native design system constraints (like size of certain classes of widgets, positioning of labels and parts)?

[domenic]

I'll also mention that we could treat platform-specific appearance as a post-MVP feature, since it's hard to get right. But, web developers seem to want it.

[othermaciej]

The demo illustrates a bunch of cross-platform platform-specific themes, but also proposes the idea of a "match the platform you are on" theme. I think the former is a bad idea, and the latter is a great idea which should bee the default (but which might be hard to implement accurately in a polyfill). I guess that should be a separate issue.

[tkent-google]

@justinfagnani I'm not sure what you're asking. Do you have a concern like platform-specific appearances might have difference default sizes?

[tkent-google]

I'll update the demo so that it doesn't specify cocoa/fluent/material themes.

[justinfagnani]

@tkent-google yes. I suspect a page author will likely not want the platform theme to change the surrounding layout. This gets tricky if platform themes have different opinions on things like padding and font for content-sized elements.

[tkent-google]

@justinfagnani
I think platform-specific themes may have different default sizes, and web authors should choose the cross-platform theme if they need interoperability.

We have an option that the standard asks browser vendors to make platform-specific themes workable with arbitrary width/height. In this scenario, web authors can have consistent layout by specifying width and height CSS properties to <std-switch> with a platform-specific theme.

[domenic]

I'm curious as to whether @othermaciej thinks it'd be possible to have standardized width/height/margin even while allowing UAs to style the "insides" as appropriate for their platforms. That seems like a reasonable compromise between predictability and the concerns about any neutral theme becoming dated.

[othermaciej]

@domenic I am not sure. I think by filing issue #21 I'm suggesting that it's possible, because a form control with inconsistent metrics in its default appearance would be unusable. I think the best way to find out is to do a survey of natural metrics of switch controls on popular platforms and

We had to figure something this out for form controls in the original macOS Safari, where many macOS controls were bigger than webpages expected, which was largely based on Windows native control sizes. We used smaller variants and padding/margin tricks, and it came out ok. I don't remember the details. But this suggests that (a) consistent sizing is required for a usable form control (at least height); and (b) this is achievable with some creativity.

The fact that the switch does not contain its label in this proposal probably makes that easier. On the flip side it would make it harder to restyle it as a pressed/unpressed looking toggle button; maybe that has to be a different control if it ever gets first class representation.