Frameworks like this are nice if a) you want your site to look exactly like every other site which uses this framework (rare) and b) every use of an element is for the exact same purpose (also rare).
I suppose if you're throwing together some hacky admin page that 2 people are going to use in a year, it makes sense. Otherwise I don't see why you don't just design your site.
I don't know what kind of stuff you all work on, but for the kind of things I work on if the interface isn't specifically designed and laid out after doing user research on the problem space, the whole project is a no-go, and is certainly not "getting work done."
To be fair, bootstrap and other classful frameworks look pretty similar to each other too, unless a skillful designer creates their own theme, at which point you might as well do it with frameworks like Pico.
> I suppose if you're throwing together some hacky admin page that 2 people are going to use in a year
I have to build a _lot_ of those across all sorts of contracts that I do.
Libraries like Pico CSS and htmx [0] let me do this incredibly rapidly, with it looking fine and working great, while keeping the maintenance burden low for the future
You do want one site to look like another site. I know if is fun for designers to make up their own UI's, but there are well established patterns that work well, and that's what everyone should use. This is how everything was when people built desktop applications because you used the OS supplied widgets. These widgets were built be experts in HCI. Everything worked the same in every app, and nobody thought about it or wished they were all unique. CSS and the web are the worst things that ever happened to usability.
It's not just "fun," it's necessary to create an optimal user experience for every particular use-case. Have you ever played two video games which have the same UI? I'd be surprised if you have. Each and every one has its own interaction patterns, its own design language, and its own visual hierarchy.
I absolutely want the web to have better builtin widgets with common functionality and accessibility, but the point is not for them to look the same, but rather work the same.
> Frameworks like this are nice if a) you want your site to look exactly like every other site which uses this framework (rare)
I might be an odd duck, but I would love it if most sites looked the same. I'm also one of those that loved interfacing with apps that used windows 98 templates and interface wise functioned the same instead of reinventing everything differently.
90% of times I'm visiting a site or opening an app, it's because I want to interact with its data or functionality. The more it adheres to my assumptions and pattern recognition, the better.
No, I'm not a robot, but I get my creative side tickled elsewhere.
I think you're confusing look with function. Two things need not look the same to "adhere to assumptions and pattern recognition," but rather need to function the same and have the same underlying conceptual language. If the web had better builtin widgets (combo boxes, dialogs, etc.), then you'd get this benefit, but because everybody is reinventing everything with JS, every site feels different.
It’s pretty customizable. I’d argue that changing from default colors, fonts and spacing results in a very different aesthetic. With pico, this is easy to do with a handful of css variables - so you don’t even need a pre/post-processor.
As a user, I happen to like when different sites have familiar UIs. Why do I need to learn completely new controls for every single "web app" from AWS to Gmail to my company's internal systems.
I already know how to use a select element, why style it so I think it's a text field? I already know how to use a button, why style it like a link? I already expect certain features to look and work a certain way, why burden me with learning it all over again?
Bootstrap, Bulma, etc. are CSS frameworks in that you have to use their opinionated HTML markup conventions for forms, grids, etc. They also attempt to cover the entire set of elements you might need in a website, such as jumbotron headers, profile images, news flashes, and more. The assortment is given attention to be a visually consistent design system.
I'm an old timer and I've built many sites. Laughed at bootstrap since day one, especially when it's on job ads.
That said I tried to use pico and bulma in small personal project and it's handy to have a baseline. The problem is that you inevitably spend most of the time later override and fighting the said frameworks that helped you get going quickly. So I wonder, if you know CSS, are you really saving time?
The key difference between tailwind and something like Pico is the semantics. Tailwind (AFAIK) totally divorces semantics and styles, so you as the dev have to apply everything. Pico aims to use as much of the HTML's semantics as possible, so you have to apply less yourself.
Personally, I love the semantic value of a well-structured HTML document, but both approaches definitely have their advantages.
Yeah frameworks are terrible, But tailwind is amazing. once you get your config set up you chern out templates/designs. there is no fighting to override stuff either.
Yes, IMO you're saving time if you designed in your use of the framework and properly leveraged it toward saving time. I built a Skeleton site almost 10 years ago. Do I want to put in a new framework now? No way. Do I feel like using skeleton now? Meh, nope. But do I need to update the site? Also nope! Because of the original plan--do about a month of work and then make future updates meet a minimum bar to qualify site design changes. I didn't feel like it was a maintenance gamble at all.
IMO you can plan for the most likely course of long-term maintenance, choose a framework that matches, and be in a much better position. Especially if your site can quickly leverage the often nasty stuff like accessible form or menu frameworks, or modals.
Plus, it's really not that hard to override most old frameworky parts for changes that work well enough. Details involved, yes. But clever solutions are really abundant at various levels. This is also why "elegance" in frameworks is a thing.
Bootstrap can absolutely grow beyond its clichéd defaults. Use the SCSS version, import after setting SCSS variables to remove border radii/set a custom $primary color/use a custom font, swap out FontAwesome for something like streamlinehq.com, and you suddenly have a modern-feeling website. It's an excellent place to start, even in 2021.
Nobody's forcing (hopefully) you to override bootstrap. Embrace constraints and focus on building the features that are unique to the business. It is unlikely innovating on UI is core to the business.
> Not fond of Pico.css’s weight, though: over 50KB, nowhere near as lightweight as the name suggests (even if it’s above-average compressible, 8KB gzipped—but I wouldn’t count even 8KB uncompressed as pico); in this case, if you flatten the variables and strip unused code, you’re left with under 4KB (~1.4KB gzipped). Lots of bloat from unused light mode support, things like form controls, and a fair bit of frivolous custom properties usage. This is the sort of place where I see the appeal of the likes of Tailwind, because they generate such huge amounts of CSS that you just about have to use an unused style remover. But it is another build step, and contrary to the deliberate intent here.
I agree. That is why I actually just decided to use different css files for different themes in sakura.css (it comes in at 3.8k / ~1.8k gzipped)
This also means that they can easily be used by others as well [1]. Have gotten some folks contribute their own themes over the years.
I also had friends who didn't want to understand CSS, and adding in media queries, variables, and dark mode support would only just confuse them even more.
Back when I was a web developer, I liked CSS pre-processor such as SASS/SCSS or LESS a lot. Popular framework at the times like Bootstrap or Foundation also had top-notch supports for CSS pre-propcessor.
Bootstrap and Bulma are both based on SCSS still - it's as popular as it's ever been (though I still cling to my beloved classic SASS syntax, it's not very popular at all).
They're just not really needed now that their core features are provided by other parts of the stack. Variables are stable in CSS itself now, modularisation is done as part of DOM management with React etc, and composition is either done in code with JS or provided by something like CSS modules 'composes' property.
You can still use a preprocessor like SASS with that stuff, but it's just another layer of complexity for not a whole lot of value outside of familiarity.
I used Zepto once for a weekend project without jQuery and it did what I needed very well. Though these days I would also check in with e.g. plain JS (way better support than when jQuery started) and projects like htmx at the other end of the "well but I need an app, but want to go light" direction.
I should mention, I did want it to be quick and dirty (it's a prototype), but well, it could have been a bit more concise. Double set parentheses come from the templating system I use BTW, if it wasn't clear.
Being HTML oriented is very cool, and you get a lot of things for free, but I keep saying "oh this would have been much easier with react" a bit too much.
For xhr you can use native fetch afaik, the only browser that doesn't have it is good old IE. Basic form validation is baked into html forms. And most of jquery selector stuff is easy to do in vanilla JS.
From the few I know, the classes are mostly shortcuts to css features (container are one of the exception), which are of course defined as custom classes but they don't create a new layer of (name,meaning) unlike what I assume we were all doing.
I’ve been structuring my styles with CUBE.css (https://cube.fyi) for a few months now and a classless approach fits the composition piece very well.
Example: In a particular context (say the <h3> tag in the <header> of each <section>) I almost always want a default style. On changing that style, I don’t want to modify markup. In future, when adding more pages, I don’t want to remember the particular combination of css classes that I’ve used elsewhere. When a particular face out is different (this <article> is a modal) then I can add meaningful class names to convey intentions.
From a practical perspective, I’ve found it to give me 90% of the UI I want at 10% of the cost.
OT: Do you by chance have any pointers on where to stay up-to-date on modern frontend development?
As a dev I've been out of the frontend game for a few years, when BEM was widely used. When I started working more on frontend again a few months ago I tried to look around for developments in terms of methodologies (e.g. "is there a 'next BEM'?"), but didn't really find anything and didn't even know where to look. Even just hearing about newer aproaches like CUBE would be nice, regardless if they end up being fit for production usage.
I'm not sure what other advice to give. A lot of this was collected over time in response to frustrations I felt around the direction front-end has been moving in (css-in-js, atomic css etc.) and looking for people writing criticisms of it.
It keeps the HTML about as clean as it can be, more often than not. Many of these classless CSS frameworks you can substitute arbitrarily without ever changing the markup. Which can be very useful for small static sites with hand-edited HTML like the Old Web people used to bake.
I certainly appreciate that "Old Web" feeling from the time before CSS when Browser default/built-in stylesheets were more opinionated and tried to do nice things without forcing you to do all of your styling by hand. Classless frameworks can feel like a good throwback to that era, and a useful compromise from today's browsers' awful default styles and the sorts of CSS frameworks that include everything and a kitchen sink and are designed much more for "apps" than just a clean document full of information.
That's a good point. I'm by no means a HTML/CSS/JS guru but this seems the wrong way around to me. Maybe components that honour the "base" tags e.g. <p>, <h1> etc that the classless stylesheet has defined could be developed (please accept my lack of awareness of those that already do exist).
So instead of a component assuming, it needs to be pointed to the tag you, as developer/designer, require - perhaps via a config parameter. Interesting comment about using SASS to namespace, but then the elegant simplicity of these stylesheets starts to get chipped away IMHO.
I think the issue there is that there are thousands of available CSS properties. Without assumptions, every single one would have to be specified for every single class. Imagine the same for JS or any other language, you would have to re-write the standard lib if you couldn't rely on it.
The most valuable aspect of these frameworks I have found personally is using it in combination with Marked for blogs/docs. Markdown to blog frameworks usually come with too much restriction and configuration overhead to justify those restrictions in my opinion. These frameworks allow me to write about 20 lines of code using Marked to get a docs site up and running and throw in Pico/other css framework for the entirety of the styles. Clients generally will have at least one request that would leave me battling a full markdown render framework but these stylesheets allow for greenfield changes to both the css via classes (keeping a clear separation) and the functional logic as you don't have to hook into any framework logic.
Both this and Pico are very inspiring. Looking through the gdcss docs was a lesson in itself - I was shown tags that I'd not previously known or thought about. Which is an admission that I tend to rely on (much to) large CSS frameworks to do their thing too much.
This is great! I've added it to this big list[0] of classless/minimal CSS frameworks (100+ frameworks) to make it easier to compare to other similar projects.
For those interested in Pico (which is already on the list), you can preview it on some boilerplate HTML here[1] or use the Javascript bookmarklet[2] to preview how it would look on any arbitrary page, which can be helpful for prototyping a new site.
A lot of the lists (UL) break for many of the libs in the demos, including pico [1]. Also in pico, the cursor remains "default" instead of switching to "text selection" when you hover over text to select it - is that a style choice?
@dohliam do you have some favorites, ones with the least "errors" and non-standard paradigms?
> A lot of the lists (UL) break for many of the libs in the demos, including pico
Unordered lists look okay to me[0], but it's possible that you are referring to the navigation section at the top of the page which technically contains a UL as well. This is just a boilerplate HTML5 template[1] with Pico CSS applied on top, so it seems that Pico doesn't have special handling for this particular usage of ULs nested in NAV elements (some frameworks turn these lists into a navigation bar or even dropdown menus, but it's interesting to compare how each of them works out of the box).
> the cursor remains "default" instead of switching to "text selection" when you hover over text
This is directly from Pico CSS itself -- check out the homepage[2] and you will see that the same thing happens there as well.
I wish more front-end stuff was oriented this way.
This is how I want front-end coding to be:
Rattle off what I need, semantically,
and then by default it will be styled and presented in a sensible way.
Then later, if our company stylist want our apps to
look a particular kind of fancy, he can configure some styling
that will apply to all.
This is also why I hate Windows WPF so much:
If you just add a label, a field, and two OK/Cancel buttons to a form,
it will look horrendous by default.
Only if you manually or deliberately set up some styling for it,
will it start to look sensible.
I want gui frameworks to look sensible out-of-the-box,
without cluttering everything with piles of boilerplate crap.
You might want to look into Qt for the native stuff. It's naturally cross-platform, but it also looks terrific too. It's got bindings for at least C++ and Python, it might have bindings for C# or wherever you're using WPF.
> Only if you manually or deliberately set up some styling for it, will it start to look sensible
I used to love those Javascript/jQuery widgets that attempted to create a whole new bespoke alternative to native form widgets, but I much prefer the OS to style them for me, since the JS (or even CSS) variants can break and look/feel borked on different devices. Inherited system UI FTW
> Rattle off what I need, semantically, and then by default it will be styled and presented in a sensible way. Then later, if our company stylist want our apps to look a particular kind of fancy, he can configure some styling that will apply to all.
You should check out Cascading Style Sheets. They let you write your document semantically in HTML, and then it is styled by a separate document created by the company stylist.
Don’t know if the sarcasm was warranted, but you do make a valid point. The parent commenter does say they want something that “looks good” out of box, which I styled html does not.
This is very, very nice. Because it styles elements, not classes, it seems very similar to the reset.css files that were very popular once. Both those files and this project aim to set the default appearance of elements before they are explicitly styled.
On the surface this looks nice, until you start using 3rd party componentsand the defaults they assumed for the component are overwritten because the default is changed.
It's no coincidence that we use classes to explicitly apply styles, I don't think this library is a good idea.
It's the same issues as changing native prototypes in Javascript, stuff depends on the defaults to be exactly as specified.
Explicit > Implicit
Stuff magically working is great until you need to make an exception.
I like this as a placeholder look and feel? Looks fairly pretty, lets me focus on building the thing, and is easy to throw away when actual themeing takes place later.
I really do not like this design. The text is a really hard to read low contrast blue-gray text on a blue-gray background. The flat design has zero UI affordances. I can't tell the difference between a highlight, a button, and a text field. I would never have guessed that the rectangle with a rectangle in it is a color picker.
It's pretty self explanatory when you click on it. Or are you saying at a visual glance you should know it's a color picker? Do you have an example of how you would do it?
I personally feel like the contrast is fine, but the light mode does fail the lighthouse contrast accessibility check, so you may have a point there.
I disagree with your other complaints though. Buttons are pretty obvious based on context clues and placement, as are highlights. Text fields also rely on context to communicate their function and furthermore more, they are labeled. As is the colour picker…
I’m curious to see examples of an inline color picker you like, as well as how you generally expect forms to be styled. I looked for a few minutes through some UI libraries I like and basically all of them handle the color picker the same way.
The other pickers have icons to indicate what they are (calendar and clock) so why not a color palette to provide a similar hint?
Needing to read the context to figure out if it's a button or a text field does not help when quickly scanning the page. Figuring out the context and reading the labels is totally unnecessary extra work that a better design wouldn't require.
It's ironic it declares itself to be semantic, but then tells you to use a link when you need an inline button. I'm guessing because, by default, their buttons are 100% width, which is a really weird default if you ask me.
Also, there are no button or form element sizes? This is essential IMO for anything other than a simple login form.
109 comments
[ 5.4 ms ] story [ 169 ms ] threadI suppose if you're throwing together some hacky admin page that 2 people are going to use in a year, it makes sense. Otherwise I don't see why you don't just design your site.
Generally that includes looking consistent to some extent.
I have to build a _lot_ of those across all sorts of contracts that I do.
Libraries like Pico CSS and htmx [0] let me do this incredibly rapidly, with it looking fine and working great, while keeping the maintenance burden low for the future
[0] https://htmx.org/
[0] https://picocss.com/docs/#customization
It's not just "fun," it's necessary to create an optimal user experience for every particular use-case. Have you ever played two video games which have the same UI? I'd be surprised if you have. Each and every one has its own interaction patterns, its own design language, and its own visual hierarchy.
I absolutely want the web to have better builtin widgets with common functionality and accessibility, but the point is not for them to look the same, but rather work the same.
I might be an odd duck, but I would love it if most sites looked the same. I'm also one of those that loved interfacing with apps that used windows 98 templates and interface wise functioned the same instead of reinventing everything differently.
90% of times I'm visiting a site or opening an app, it's because I want to interact with its data or functionality. The more it adheres to my assumptions and pattern recognition, the better.
No, I'm not a robot, but I get my creative side tickled elsewhere.
You can customise it https://picocss.com/docs/#customization
b) every use of an element is for the exact same purpose (also rare)
Styling is done by combinations of elements. Consistency between those combinations is good design.
I already know how to use a select element, why style it so I think it's a text field? I already know how to use a button, why style it like a link? I already expect certain features to look and work a certain way, why burden me with learning it all over again?
That said I tried to use pico and bulma in small personal project and it's handy to have a baseline. The problem is that you inevitably spend most of the time later override and fighting the said frameworks that helped you get going quickly. So I wonder, if you know CSS, are you really saving time?
You might be interested in tailwind. I'm unsure how to explain it, but it is a pleasure to use once you get used to it.
Personally, I love the semantic value of a well-structured HTML document, but both approaches definitely have their advantages.
At the price of a verbose class soup everywhere.
I can’t bear to look at the soup so I don’t use it much.
ITCSS makes you think and work with the cascade resulting in almost never reverting anything. Super efficient.
IMO you can plan for the most likely course of long-term maintenance, choose a framework that matches, and be in a much better position. Especially if your site can quickly leverage the often nasty stuff like accessible form or menu frameworks, or modals.
Plus, it's really not that hard to override most old frameworky parts for changes that work well enough. Details involved, yes. But clever solutions are really abundant at various levels. This is also why "elegance" in frameworks is a thing.
It's a complete base CSS framework in just over 1kb of code.
> Not fond of Pico.css’s weight, though: over 50KB, nowhere near as lightweight as the name suggests (even if it’s above-average compressible, 8KB gzipped—but I wouldn’t count even 8KB uncompressed as pico); in this case, if you flatten the variables and strip unused code, you’re left with under 4KB (~1.4KB gzipped). Lots of bloat from unused light mode support, things like form controls, and a fair bit of frivolous custom properties usage. This is the sort of place where I see the appeal of the likes of Tailwind, because they generate such huge amounts of CSS that you just about have to use an unused style remover. But it is another build step, and contrary to the deliberate intent here.
This also means that they can easily be used by others as well [1]. Have gotten some folks contribute their own themes over the years.
I also had friends who didn't want to understand CSS, and adding in media queries, variables, and dark mode support would only just confuse them even more.
[1]: https://github.com/oxalorg/sakura/tree/master/css
I wonder where they went.
You can still use a preprocessor like SASS with that stuff, but it's just another layer of complexity for not a whole lot of value outside of familiarity.
Also, in another comment someone mentioned their own Sakura CSS and it's also SCSS based.
[0] https://picocss.com/docs/#customization
Any recommendation for a lightweight and complementary JavaScript library? Validate forms, XHR wrapper, etc. without the bulk of jQuery.
Seems there are some more ideas here: https://www.technotification.com/2019/06/5-lightweight-jquer...
That does 90% of what I need when sprinkling backend AJAX-y interactivity on a straight HTML page with a backend that sends JSON or HTML back.
https://htmx.org/examples/inline-validation/
For more jquery-esque fine-grained control for building custom elements/components on my pages I turn to:
https://alpinejs.dev/
I love both of these libraries.
https://gist.github.com/egeozcan/cdc90e290271f3ea4b6801dcf1a...
I should mention, I did want it to be quick and dirty (it's a prototype), but well, it could have been a bit more concise. Double set parentheses come from the templating system I use BTW, if it wasn't clear.
Being HTML oriented is very cool, and you get a lot of things for free, but I keep saying "oh this would have been much easier with react" a bit too much.
Since ES6 (2015) Vanilla Javascript has been very good. Form validation is free with HTML5, XHR is already wrapped with a one-line Promise API.
It's just a bunch of code examples and text, so no fancy layout or styling is needed.
I just want a modern look, without much hassle.
I had the impression, if Tailwind has one thing, it's a multitude of classes.
I've tried to keep it really simple so that folks without css knowledge are also able to hack on it while building their sites.
Would be happy to hear your feedback on it :)
Why the demand for "classless"?
Example: In a particular context (say the <h3> tag in the <header> of each <section>) I almost always want a default style. On changing that style, I don’t want to modify markup. In future, when adding more pages, I don’t want to remember the particular combination of css classes that I’ve used elsewhere. When a particular face out is different (this <article> is a modal) then I can add meaningful class names to convey intentions.
From a practical perspective, I’ve found it to give me 90% of the UI I want at 10% of the cost.
As a dev I've been out of the frontend game for a few years, when BEM was widely used. When I started working more on frontend again a few months ago I tried to look around for developments in terms of methodologies (e.g. "is there a 'next BEM'?"), but didn't really find anything and didn't even know where to look. Even just hearing about newer aproaches like CUBE would be nice, regardless if they end up being fit for production usage.
* https://adactio.com * https://piccalil.li/blog/ * https://stephaniewalter.design/ * https://www.baldurbjarnason.com/
This post has some good pointers: https://www.baldurbjarnason.com/2021/what-do-i-need-to-read-...
I'm not sure what other advice to give. A lot of this was collected over time in response to frustrations I felt around the direction front-end has been moving in (css-in-js, atomic css etc.) and looking for people writing criticisms of it.
I certainly appreciate that "Old Web" feeling from the time before CSS when Browser default/built-in stylesheets were more opinionated and tried to do nice things without forcing you to do all of your styling by hand. Classless frameworks can feel like a good throwback to that era, and a useful compromise from today's browsers' awful default styles and the sorts of CSS frameworks that include everything and a kitchen sink and are designed much more for "apps" than just a clean document full of information.
Any third party library or component you use will be affected by "classless". There's a good reason explicitly define classes.
It's the same reason you don't change native prototypes in Javascript. Libraries assume the defaults, both for styling and code.
I only have a handful of HTML pages with a bit text and code. Nothing fancy.
My main goal is to keep all code in the HTML files with as little boilerplate as possible.
So instead of a component assuming, it needs to be pointed to the tag you, as developer/designer, require - perhaps via a config parameter. Interesting comment about using SASS to namespace, but then the elegant simplicity of these stylesheets starts to get chipped away IMHO.
https://gdcss.netlify.app/
Same idea and Pico (classless, simple, small etc).
For those interested in Pico (which is already on the list), you can preview it on some boilerplate HTML here[1] or use the Javascript bookmarklet[2] to preview how it would look on any arbitrary page, which can be helpful for prototyping a new site.
[0]: https://github.com/dohliam/dropin-minimal-css [1]: https://dohliam.github.io/dropin-minimal-css/?pico [2]: https://github.com/dohliam/dropin-minimal-css#bookmarklet
- Have some popularity measure (github stars or otherwise) either in your list or hosted somewhere
- Have screenshot previews of anything, hosted somewhere (would be a bit quicker to browse through the list).
@dohliam do you have some favorites, ones with the least "errors" and non-standard paradigms?
[1] https://dohliam.github.io/dropin-minimal-css/?pico
Unordered lists look okay to me[0], but it's possible that you are referring to the navigation section at the top of the page which technically contains a UL as well. This is just a boilerplate HTML5 template[1] with Pico CSS applied on top, so it seems that Pico doesn't have special handling for this particular usage of ULs nested in NAV elements (some frameworks turn these lists into a navigation bar or even dropdown menus, but it's interesting to compare how each of them works out of the box).
> the cursor remains "default" instead of switching to "text selection" when you hover over text
This is directly from Pico CSS itself -- check out the homepage[2] and you will see that the same thing happens there as well.
[0]: https://dohliam.github.io/dropin-minimal-css/?pico#text__lis...
[1]: https://github.com/cbracco/html5-test-page
[2]: https://picocss.com/
https://design-system.service.gov.uk/
https://frontend.design-system.service.gov.uk/
This is also why I hate Windows WPF so much: If you just add a label, a field, and two OK/Cancel buttons to a form, it will look horrendous by default. Only if you manually or deliberately set up some styling for it, will it start to look sensible.
I want gui frameworks to look sensible out-of-the-box, without cluttering everything with piles of boilerplate crap.
I used to love those Javascript/jQuery widgets that attempted to create a whole new bespoke alternative to native form widgets, but I much prefer the OS to style them for me, since the JS (or even CSS) variants can break and look/feel borked on different devices. Inherited system UI FTW
You should check out Cascading Style Sheets. They let you write your document semantically in HTML, and then it is styled by a separate document created by the company stylist.
Also, the demo does a great job of highlighting exactly how it works.
It's no coincidence that we use classes to explicitly apply styles, I don't think this library is a good idea.
It's the same issues as changing native prototypes in Javascript, stuff depends on the defaults to be exactly as specified.
Explicit > Implicit Stuff magically working is great until you need to make an exception.
I disagree with your other complaints though. Buttons are pretty obvious based on context clues and placement, as are highlights. Text fields also rely on context to communicate their function and furthermore more, they are labeled. As is the colour picker…
I’m curious to see examples of an inline color picker you like, as well as how you generally expect forms to be styled. I looked for a few minutes through some UI libraries I like and basically all of them handle the color picker the same way.
The other pickers have icons to indicate what they are (calendar and clock) so why not a color palette to provide a similar hint?
Needing to read the context to figure out if it's a button or a text field does not help when quickly scanning the page. Figuring out the context and reading the labels is totally unnecessary extra work that a better design wouldn't require.
https://dohliam.github.io/dropin-minimal-css/
It's ironic it declares itself to be semantic, but then tells you to use a link when you need an inline button. I'm guessing because, by default, their buttons are 100% width, which is a really weird default if you ask me.
Also, there are no button or form element sizes? This is essential IMO for anything other than a simple login form.