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.
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.
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.
> 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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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."
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?
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.
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.
> 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.
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.
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 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?
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.
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.
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.
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).
> 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.
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'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?
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.
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.
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.
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.
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.
https://gdcss.netlify.app/
Same idea and Pico (classless, simple, small etc).