A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

System UI for HTML

OpenLocationServices
2018-06-15

Right now, while developing PWA’s we use a library called Framework7 (https://framework7.io/) for giving native OS like UI. However this has a huge performance penalty due to huge complexity of animations, especially on low end devices. On Windows we use a library called WinJS (http://try.buildwinjs.com/)

A way to use system ui for buttons, and everything that a system UI provides in JS would solve this problem.

Right now we serve different libraries are served depending on user agent.

What do you guys think? Providing a native ui would have much higher performance.

Garbee
2018-06-15

True native styling for everything, makes styling things consistently harder. I don’t see why the web needs to have this type of stuff built in. It’s like saying browsers should be library maintainers and handle every component need internally just to provide a system interface. In return if you don’t want that system interface, it is harder to style it out of the app across platforms.

I think there is room for a component library to come around that is built in a performance oriented way and provides the native styles automatically based on the browser info. But, it isn’t something that UA’s should be involved in. It is too much overhead and complexity for not enough gain for the web as a whole.

simevidas
2018-06-17

CSS animations should be able to run fairly well even on low-end devices (assuming that they are done correctly). I suspect, your performance issues are due to JavaScript, instead.

mkay581
2018-06-17

Yeah, I agree that an open-source component library may be good for this purpose. Although my usage of unstyled html elements generally are performant and do look fine these days, with the exception of making small tweaks to positioning and alignment, which I think you’d have to do even if a component library existed.

Tigt
2018-06-23

If you have <button> without any CSS applied (including things like Normalize.css or CSS resets) should look like a native OS-specific button already, right?

Garbee
2018-06-23

Not necessarily. This is not specified behavior. Especially on Linux platforms, “native” is widely varying depending on your desktop theme. User Agents should not be responsible for needing to figure out native type styling and making it work in a web page. This kind of thing is buggy and error-prone. It is best that if developers are targeting a platform specifically and want native styling, they handle that in their application. Web standards also don’t provide all the UX components covered in these component libraries, so what should be done there? We invent new specs to cover every component possible?

The Extensible Web Manifesto guides us into thinking more about low-level capability to enable new functionality in the web that currently isn’t possible or is extremely difficult to get done on the web. Native-like styling doesn’t fit this bill. It is entirely possible. The difficult part is adapting on-the-fly to various OS types, but it’s completely possible as well someone just needs to put the effort into making a component library aimed at doing that seamlessly.

I don’t feel this request meets the bar as something that the web community should be pushing for in User Agents/standards. We have much more interesting targets that unlock new capabilities that should be looked into and pushed. Rather than pushing for something that is rehashing a debate from the dawn of the web which doesn’t have a good solution for UA’s. It’s a big time sink for them to maintain and fix bugs. Maintainer time is best spent elsewhere from my point of view.