Replies: 10 comments
-
|
Framework-agnostic CSS-in-JS libraries (see JSS) can help us to load CSS dynamically and address some of the concerns you've mentioned above. imho. for theming configuration, I'd suggest sticking to JS "world" practices and allowing defining themes in *.js, rather than in yaml. JSS should already address that as well. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the suggestion. Yeah, sticking with best practices as much as possible is definitely a good principle we should try to stick with. From your comment, I also realized that my proposal wasn't well explained on my part. I'm not suggesting that we add the style rules and all in the yaml itself but use the yaml to provide pyscript the metadata to access the theme somewhere (so it can also load its related assets), with a name/location/url. |
Beta Was this translation helpful? Give feedback.
-
|
i would like to support simple pure css themes. i do also like the idea of supporting CSS-in-JS like JSS. so i would like both. many beginners will want to dig into learning python and web tech, and making or modifying a theme is a good starting point for a ton of folks. JSS is too complex for some who are just starting out in their learning. for them, i want to be able to point to a simple pure css theme as a starting point. and then they can move on to JSS |
Beta Was this translation helpful? Give feedback.
-
|
@verhulstm agree. For that, we could provide a user-friendly API to do theming. We can still leverage JSS-like frameworks and wrap it with a simple API. Here is a simple example of what it might look like. We introduce a provider component that would wrap the other components and propagate styles/themes to other components used in the Pyscript. We expose the configuration that is easy to reason about for novice users, as well as support more complex configurations for more advanced users. Define theme: const customTheme = extendTheme({
semanticTokens: {
colors: {
error: 'red.500',
success: 'green.500',
primary: {
default: 'red.500',
_dark: 'red.400',
},
secondary: {
default: 'red.800',
_dark: 'red.700',
},
},
components: {
'py-button': {
backgroundColor: 'black.500',
color: 'white.200'
},
'py-title': {
color: 'yellow.500',
fontSize: '14px',
},
'py-input-box': {
color: 'black.200',
fontSize: '14px'
},
},
},
})Theme usage: <py-provider theme={customTheme}>
....
<py-title></py-title>
<py-inputbox><py-inputbox>
<py-button></py-button>
<py-provider/> |
Beta Was this translation helpful? Give feedback.
-
|
can we support all the above in a css file? |
Beta Was this translation helpful? Give feedback.
-
|
+1 for pure CSS as an option. Peter quite rightly bangs the drum about entry, that Frankly, I hope PyScript splits and doesn't mandate any CSS, as you won't choose what I want (Bulma). Something built atop should be opinionated. My two cents. |
Beta Was this translation helpful? Give feedback.
-
|
This is a great discussion. I get the point about not mandating CSS and keeping PyScript as lean as possible, otoh, if we really want to target non-technical users to empower them with easy to build UI capabilities, we do need to have an opinonated options for them to just drop new components on a page "that just works". With that said, I think this can be optional. Either by loading the theme (CSS) as an option or vice versa (basically opt-in vs opt-out). Or even splitting theming from PyScript core and let it be a separate load (this would mean that users need to do extra work though, that is harder for non-technical users). |
Beta Was this translation helpful? Give feedback.
-
|
I'm working on a video that talks about a core/app split, FWIW. Most people would consume the app. But if someone wanted to make a new pluggable app -- e.g. Minecraft -- they could make their own decisions on CSS, CSS/JS framework, etc. I realize it's just my opinion, but I should speak with a demo, rather than ticket comments. 😀 |
Beta Was this translation helpful? Give feedback.
-
|
That sounds great. Yeah, demos are more effective than words, for sure! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I guess this is very related to this issue: #78 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
PyScript currently "requires" users to load the CSS explicitly and separately from the JS. This has a few limitations:
If we switch to lading CSS dynamically within the scope of pyscript.js we can:
In terms of implementation, we could allow users to specify a theme for the app in the AppConfig yaml that can be loaded in runtime.
Would love to hear opinions about the good and bad of the different approaches and possible alternative solutions. :)
Beta Was this translation helpful? Give feedback.
All reactions