The bare minimum that you can ship is CSS that is require to let the component function like it should (e.g. make a table side-scrollable, while looking ugly as hell).
Minimal CSS is good - I think we can all agree on that. But when exactly do you stop? After all, people will often download components based on screenshots. Your component may be good, and with carefully crafted minimal CSS, but will it receive any attention if it looks ugly? On a similar note, what if I would rather have a component which looks good by default and does not fit in as well, but is easy to just slap into an app? My point here is: I think that (just like "good API design") "minimal CSS" is a lot easier said than done.
The worst CSS experience I've ever had (which just happened to be my first contact with CSS ever) was with a big UI framework I had to deal with (I won't tell the name, it's still alive), which had a really complex SCSS theming going on, poorly documented of course, and to add insult to injury the HTML structure was generated dynamically at runtime, with DOM modifications galore on top. You had to (more or less blindfolded) guess the right selector to match the generated structure, and then pray that it happened to be more specific than any of the extensive theming which was already in place. No hot reloading by the way, a server restart was required for every change. It was a nightmare. I still clearly remember the 4 hours of work it took me just to change the font color of a tabsheet heading. So I'm a little biased when it comes to CSS, but I've also had some positive experiences with it later on.
I remember a similar experience. I learned CSS before the big frameworks existed. But at a certain point it got to work with a rapid development tool (kind of drag and drop). This tool did allow to create your own theme in scss. But it shipped its own scss framework as well, on top or one of the bigger css frameworks. I never apply some much selector nesting and !important to override the styles. This experience made sure I don't want to rely on css frameworks again. If you do, specificity does become a trouble.
Minimal CSS and good API is definitely easier said than done. We can definitely agree on that. I think it is almost human nature that we always try find one solution for our problems. In my previous table example, I have the separate components with minimal CSS, but I also have a fully styles wrapper (one component and one scss file). It's an ideal way to show how it can be styled.
This is a mental model issue for us as developers. We are keen so share our work and for others to use our work. But this is relatively new in front-end land. So we forget sometimes to think of potential use cases of others (styling wise, feature wise we do it quite alright). In back-end development it is already more matured (e.g. REST API design).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the in-depth answer!
Minimal CSS is good - I think we can all agree on that. But when exactly do you stop? After all, people will often download components based on screenshots. Your component may be good, and with carefully crafted minimal CSS, but will it receive any attention if it looks ugly? On a similar note, what if I would rather have a component which looks good by default and does not fit in as well, but is easy to just slap into an app? My point here is: I think that (just like "good API design") "minimal CSS" is a lot easier said than done.
The worst CSS experience I've ever had (which just happened to be my first contact with CSS ever) was with a big UI framework I had to deal with (I won't tell the name, it's still alive), which had a really complex SCSS theming going on, poorly documented of course, and to add insult to injury the HTML structure was generated dynamically at runtime, with DOM modifications galore on top. You had to (more or less blindfolded) guess the right selector to match the generated structure, and then pray that it happened to be more specific than any of the extensive theming which was already in place. No hot reloading by the way, a server restart was required for every change. It was a nightmare. I still clearly remember the 4 hours of work it took me just to change the font color of a tabsheet heading. So I'm a little biased when it comes to CSS, but I've also had some positive experiences with it later on.
I remember a similar experience. I learned CSS before the big frameworks existed. But at a certain point it got to work with a rapid development tool (kind of drag and drop). This tool did allow to create your own theme in scss. But it shipped its own scss framework as well, on top or one of the bigger css frameworks. I never apply some much selector nesting and !important to override the styles. This experience made sure I don't want to rely on css frameworks again. If you do, specificity does become a trouble.
Minimal CSS and good API is definitely easier said than done. We can definitely agree on that. I think it is almost human nature that we always try find one solution for our problems. In my previous table example, I have the separate components with minimal CSS, but I also have a fully styles wrapper (one component and one scss file). It's an ideal way to show how it can be styled.
This is a mental model issue for us as developers. We are keen so share our work and for others to use our work. But this is relatively new in front-end land. So we forget sometimes to think of potential use cases of others (styling wise, feature wise we do it quite alright). In back-end development it is already more matured (e.g. REST API design).