Skip to content

Conversation

@alexander-heimbuch
Copy link
Contributor

@alexander-heimbuch alexander-heimbuch commented Dec 24, 2025

This is especially useful when creating input groups with buttons.

@alexander-heimbuch
Copy link
Contributor Author

@bendera would appreciate some feedback here :)

@bendera
Copy link
Member

bendera commented Jan 6, 2026

@alexander-heimbuch

Customizability has been a dilemma for me as well from the very beginning. Since this is not a general purpose library but one that mimics the VSCode UI, it shouldn'T allow any customization options. On the other hand we should allow some flexibility, for cases like yours. In the first verison everything was overridable. But this violates the main principle of the web components, the style encapsulation. (And it also causes other kind of issues: #241)

Alright, then let’s allow a few things, for example, corner rounding. But why only that? Why not colors or font styles as well? At the end of the day, we need a design system. That's what I really want to avoid. On the one hand, it would be a huge effort, on the other hand it's already exist, that is the design system of the VSCode UI, with huge amount of theme variables.

What I consider as an acceptable compromise is defining CSS parts. In this case it looks like this on the extension developer's side:

vscode-single-select::part(face) {/* ex.: border-right-radius: 0; */}

(I’m not sure whether the name “face” is good enough. So far I’ve only used it internally, but here it would appear in the public API.)

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.

2 participants