With the separate theme app dependency methodology, it would be nice if we could exclude the standard .css files so they do not interfere with theme styles.
I’m seeing the following css files being included in a “Custom HTML” app.
- runner-v3.min.css (largest offender of styling issues)
- daterangepicker.min.css
- font-awesome.min.css
Removing the runner-v3 stylesheet causes issues with “made with Anvil” elements. So, it would also be great if we had the option to exclude:
<div id="anvil-header"><div id="anvil-badge">
Not sure what to do about:
<div id="loadingSpinner"><div id="error-indicator">
Perhaps this is something that user’s would be required to include in their theme.
Playing around with TailwindCSS and Headless UI and having separation between the component and the style makes a lot of sense for Anvil. It would be really cool for all of the standard Anvil components to just have the functionality, like Headless UI, that then any theme could adapt without having to change anything in the app besides importing a new theme.
1 Like
What sort of conflicts are you seeing?
If you start from a new m3 theme and remove m3 as a dependency all anvil css should be namespaced (prefixed with anvil-). This is to avoid conflicts with new themes.
(Note you can also start from a blank app and migrate to layouts and then remove the legacy features in settings → python versions → advanced).
Yeah, I’ve been going the blank and changing legacy features. Sounds like M3 is a better blank canvas starting point. I’ll give that a try in the future.
What I’ve been playing around with is creating pages using tailwind and placing slots where I would like to include anvil components. So, an Anvil Link component would then be styled by tailwind. However, the link has styling provided by .anvil-link-text .anvil-label.
So, without overriding the link style it looks like this:
If I unset the link styles it looks correct like this:
Perhaps I’m just thinking of this all wrong. But, it would be nice to have a clear separation between the functionality of a component and it’s style. Thinking about the M3 themed app for instance, updating an app to a new theme would be significant work since the components used to build the app are tied to the theme.
In a bigger picture, Anvil + TailwindCSS seems like a beautiful match.
- Anvil Components would be like Headless UI, pure function - no style
- Themes would be the class list added to each component
- Debug mode uses the full tailwind stylesheet to avoid unnecessary overhead
- Updates to published trigger the tailwind stylesheet generation
1 Like
Oh I see, you’re trying to use existing anvil components with your new theme. But struggling because anvil components already come with some default styling that isn’t easily overridden.
Noted. This sort of thing is certainly on our list.
3 Likes
Oh man, you would love the internal demo I gave to the team the other week. Stay tuned, we might have something helpful for your use case!
3 Likes
Awesome! I can’t wait to see what you’ve come up with.