[EPIC] Better Visual Components Proposal

[fpliger]

This is an umbrella issue to collect the tasks needed to re-design a more solid and flexible presentation design for all the visual components:

• Replace Tailwind with a pure CSS solution
• Propose a design that allows dynamic theming of the visual elements. Ideally, this could/should be a non PyScript specific design that can play well in supporting translation between PyScript and other frameworks that generate UI (i.e., Toga?). This discussion can eventually be part of the discussions in [DISCUSSION] Dynamic loading style (CSS) and theming support #340 or we can open a new issue for the actual implementation task
• Implement dynamic CSS and theming support : One important aspect of this (that probably should be explicit in the design work proposed in the item above, is that dynamic CSS/theming should still allow users to define local small style changes to components (i.e., changing background color, font color, etc...). Basically allowing a baseline theme for PyScript (that can be reused by many apps) and additional style to be used by the app itself.

Related Issues:

• Make CSS Loading a one liner (Make it one liner #94 )

[freakboy3742]

There isn't really an opportunity to "share themes" with Toga - but the reason why may be illustrative for PyScript's theming approach.

Toga deliberately does not support themes - the core look and feel of an app is entirely determined by the platform. On iOS, buttons don't have borders, and match the background color; on macOS, they're gray, and have a slightly rounded borders; and so on. This is very deliberately not opened to the end user to control; if you don't like the look and feel of the widgets on your platform, take that up with your operating system vendor, or pick a different platform :-)

Toga does have the ability to modify the appearance of some widgets for "functional" purposes - e.g., you can say "I want this button to be red, because it's an Emergency stop" button. The mechanism it uses to do that is effectively CSS (technically, it's a CSS-like language subset called Pack, but the long game is to use an actual CSS implementation). This means you end up writing code like:

 toga.Button("Emergency Stop", style=Pack(background_color='red'))

You can't change the fundamental appearance of a button/selection/table though. The only stylistic elements that are exposed are relatively simple color/background/font styles, and are very explicitly exposed on a per-widget basis; just because you define a color style on a widget, doesn't mean the color will change - either because the widget or the platform defines that the color isn't user-modifiable.

IMHO, there is a analog to what PyScript could/should aim for. The web doesn't have a consistent look and feel for apps - but PyScript is in a position to provide a single stylesheet that defines the "PyScript look and feel". That appearance won't be to everyone's taste, but you can stake out what a PyScript looks like by default.

There are then 2 distinct modes of extension:

1. Specific style elements can be exposed on specific widgets, such as the background color of a button. This could be in the down with specific widget attributes (e.g., <py-button background-color='red'>), or by using CSS styles (i.e., <py-button style="background-color: red">) and defining how the CSS styles will be mapped to the DOM elements that actually render the button. Not all CSS styles would be automatically recognised on widgets.
2. The overall requirements of a PyScript "theme" can be documented, so others could replace (or augment) the default PyScript theme with a custom theme. This would effectively mean documenting the internals of how each widget is rendered (and maybe providing a testbed) so that theme writers can easily apply whatever stylistic approach they want.

(1) is what Toga provides on a per-widget basis. To my mind, this part isn't "theming" - its defining functional requirements of a specific widget in the context of an app.

Implementing (2) in Toga isn't possible, because it would mean overriding the default platform look and feel; but PyScript doesn't have that constraint because of the lack of a "default" look and feel for the web.

Another, partially related area where there is potential overlap with Toga is in establishing consistent terminology. If we agree that a "thing you click on to make an action happen" is called a "Button", it has an "on_press" handler that is triggered when it is pressed, and exposes the background color as something that can be customised, then the APIs exposed by Toga and PyScript will be very similar, and the cognitive overhead of turning a GUI written in PyScript into a native app with Toga will be lower.

[MarcSkovMadsen]

One thing to consider is also how the css will if integrated in other environments. I'm a contributor to Panel and for Panel using something like Bootstrap is not a great idea because it has a tendency to interfer with the css in jupyter. For my use cases I'm also thinking how things work inside VS Code in an interactive environment.

For that reason I've always be looking to web components like fast.design, shoelace or wiredjs as they don't have problems being integrated with other design systems/ css frameworks.

When I saw you used tailwindcss for PyScript I thought "oh no" as I believe you are developing something general and users would like to be able to select their own design system. I don't think you should be building something opinionated. Let others rebuild Streamlit, Panel or what ever on top of PyScript using their preferred design system.

Thumbs up for PyScript. Great work.

[fpliger]

@MarcSkovMadsen thanks. Great point.

Tailwind was an experiment to have something "quick and dirty"... but yeah, PyScript should be less invasive.