Matching the platform look should be the default

[othermaciej]

The explainer lists the following goal:

Identical appearance on all platforms and all supported browsers by default

but provides no justification for it. Existing form controls have either a platform-specific or a browser-specific look by default. Some also de facto have the ability to remove that look via custom styling (e.g. <input type=text> or <input type=button>), while others can't be freely custom styled in a cross-browser way (e.g. <input type=checkbox>). The ones that do allow free styling tend to still be used in contexts that demand full custom looks, while the latter are replaced with div soup.

I think a default platform/browser/etc specific look that is unspecified, plus full styling with CSS that can entirely replace the look, is the best target. That's the most successful kind of form control so far, and it looks good both in mildly styled websites that don't care to override all form controls, and in heavily styled sites that want a total custom look.

It's not clear why a default cross-browser cross-platform look (but which might still not be fully specified per issue #20 ) would be better. Even if it looks good on lots of platforms and websites today, it will eventually look dated if frozen. And if not frozen, it can't achieve the goal of looking exactly the same on all browsers and platforms. On the other hand, a platform/browser specific default look can be updated over time.

[andrewwatterson]

I think this can be questioned in the other direction: what's the justification for platform-specific themes?

I imagine one rationale (that sounds good) is "consistency with the platform," but in practice that breaks down in both directions: web apps are rarely styled to look like any host platform, and the constraints on HTML elements (sizing form elements to match text when positioned inline, for example) are such that the platform default HTML elements often don't match what's done in native platform UIs.

I'd use iOS as an example (not to pick on Apple, just because I'm most familiar with it) - Safari's default input fields/checkboxes/buttons bear no resemblance to anything used elsewhere in iOS. They're also comically small compared to both their native system counterparts and the zeitgeist of modern web UI (this is also true on macOS and to a lesser extent on Windows).

What this creates isn't a platform-consistent experience, but just a separate default theme that's doesn't match any of the other platforms' default themes. As pointed out here and in #20, different base assumptions (box size and margin/padding) make "multiple default themes" vastly less preferable to "one default web theme," even if figuring out what that theme should be is substantial work with an unknown result.

The staleness-over-time argument seems pretty reasonable, but it's also unclear how that fares in practice: Googling for old screenshots reveals that iOS hasn't changed its form elements since before iOS 6, despite the fact that they have arguably undergone the most dramatic visual change of any platform since then.

There's no obvious existing alternative here: specifying platform UI is one approach to default-styling browser elements (since the web has no established visual language and platforms do), but it's not clear it has any real benefits.

[chrishtr]

I think a default platform/browser/etc specific look that is unspecified, plus full styling with CSS that can entirely replace the look, is the best target. That's the most successful kind of form control so far, and it looks good both in mildly styled websites that don't care to override all form controls, and in heavily styled sites that want a total custom look.

By this, do you mean that you think the developer experience for <input type=checkbox> is better than <input type=button>? Isn't it better for a developer to be able to style some of the form control rather than having to re-implement it completely?

[justinfagnani]

I think this can be questioned in the other direction: what's the justification for platform-specific themes?

I think that in better defining what a platform theme means via new elements, we can make it much more useful. There are two main uses cases in my mind:

1. Make an app, especially an installed PWA, feel as native to its host platform as possible. This developer cares about fidelity, and not detecting the platform or shipping a large stylesheet are huge benefits. Evolution comes into play here, as a developer might want your app to keep up with changes in the native L&F, or might want to lock it down to the L&F they actually tested against. To avoid staleness we could imagine a meta tag that opts into the latest L&F at the risk of layout/style incongruities.
2. Provide a "good" look and feel, where "good" is judged by the developer to probably be the most familiar to the platform users. This developer might not care as much as in the first case about exactly matching the host platform, but they do want a good enough L&F, want to delegate as much of the responsibility as they can, and trust the host platform to do a decent job. They would be more likely than the first to choose the web L&F as well. The difference is probably a matter of degrees.

Another reason could be to unlock the idea of a web base theme in the first place. I wonder how easy it would be to get everyone to agree on one without being very adamant that the particular native platform they care about most does things "better". Being able to say "if you want the best experience on X, use the platform theme" could allow for agreement that the web base theme just needs meet minimal base styling and full accessibility requirements.