Skip to content

Apply Basecoat to Quasar with basecoat.quasar.css#130

Open
evnchn wants to merge 4 commits intohunvreus:developmentfrom
evnchn:feature/apply-to-quasar
Open

Apply Basecoat to Quasar with basecoat.quasar.css#130
evnchn wants to merge 4 commits intohunvreus:developmentfrom
evnchn:feature/apply-to-quasar

Conversation

@evnchn
Copy link
Copy Markdown

@evnchn evnchn commented Jan 1, 2026

This PR applies Basecoat to Quasar with basecoat.quasar.css

  • Utilities are extracted to basecoat.shared.css and the original basecoat.css as well as the new basecoat.quasar.css will import from it.
  • basecoat.quasar.css targets Quasar and applies Basecoat
  • Build pipeline updated accordingly (Hack is needed because otherwise dark mode won't work)
  • The built basecoat.cdn.css remains functionallly unchanged (very small diff, just moved around) for backwards compatibility (the intended goal)

End user just has to do this to enjoy Basecoat styles in a Quasar application (using NiceGUI as an example, because that is what I made this for)

app.add_static_file(local_file=Path(__file__).parent / 'basecoat.quasar.css', url_path='/basecoat.quasar.css')
ui.add_head_html('''<link rel="stylesheet" href="/basecoat.quasar.css">
<style>
@layer theme {
    body {
        --primary: var(--q-primary);
    }
}
</style>''', shared=True)

ui.input.default_props('borderless dense input-class="input-text"')
ui.number.default_props('borderless dense input-class="input-text"')
ui.textarea.default_props('borderless dense input-class="textarea"')
ui.color_input.default_props('borderless dense input-class="input-text"')
ui.date_input.default_props('borderless dense input-class="input-text"')
ui.time_input.default_props('borderless dense input-class="input-text"')
ui.select.default_props('borderless dense').default_classes('input-text *:-mt-1.5') # HACK but works

I am not sure whether to merge or to maintain this in a separate library. I am fine with either approach 😄

@evnchn
Copy link
Copy Markdown
Author

evnchn commented Jan 1, 2026

By the way: This came from zauberzeug/nicegui#5608

@hunvreus
Copy link
Copy Markdown
Owner

hunvreus commented Jan 3, 2026

That's a pretty radical set of changes. I'm not opposed to it, but trying to understand if there's a common pattern with what others may need.

Why do you need to move to using @utility for the components?

@evnchn
Copy link
Copy Markdown
Author

evnchn commented Jan 3, 2026

From how I see it, the value of Basecoat lies in 3:

  1. A genuinely awesome set of CSS styles
  2. Said CSS styles applied semantically to HTML elements
  3. Some of said HTML elements become interactive with a little bit of JS

While the combo works in its own right as a UI framework, the goal of this PR is to take (1) standalone, and apply it to other frameworks which may not use semantic HTML elements.

For example, in Quasar, checkboxes / inputs are not visually achieved with an <input>* but a bunch of <div>. The default basecoat.cdn.css is ineffective in styling Quasar as a direct result.

By using @utility, the goal is to refactor and extract the CSS styles into utilities to be applied elsewhere where one see fit, while keeping the Basecoat CSS functionally unchanged since @utility can be considered macros, essentially.

On the diff, yes it is big, but mostly it is moving stuff around. You can fact-check with Ctrl-F. If you need me to prove the equivalence do tell me.

Note that some styles are not copied over because they are not generic (h-9 for example), and for fitting Quasar layout, I made the padding smaller for badge.

And moving forward I see the Basecoat @utility sets will be a powerful toolset to make any website look good no matter the underlying UI framework in use, if there even is one. It will be a part of the public API.

*: There is a <input> somewhere but it is hidden and likely used for screen reader / accessibility purposes.

@evnchn
Copy link
Copy Markdown
Author

evnchn commented Jan 5, 2026

To supplement some points.

some styles are not copied over because they are not generic

We may want to hammer down which ones are considered "not generic" to move forward. I see padding, margin, width, height, and gap to be my preliminary candidate list, based on my current use case. However the list could forseeably grow and/or shrink.

will be a part of the public API

While declaring them as public API is in my opinion best way to move forward, in case the developmental burden worries you, I also see no issues with prefixing them with either _ or - to mark them private and subject-to-change. Just that users of those @utility sets have to pin exact version to avoid breaking changes that way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants