Nice work! I like that you have included support for prefers-color-scheme, which is one of the more highly-requested features for these kinds of frameworks.
I've added Lissom to the big list of minimal CSS frameworks [0] which aims to collect all of these types of projects (more or less) in one place for ease of discoverability and comparison. You can preview the CSS on some HTML5 boilerplate here [1].
For those wondering why anyone would want to send ecards instead of using $X, I posted some background about the motivation for the project here[0].
TLDR: nostalgia, experimenting with something new, technical challenge of adding functionality without necessitating servers or third parties, and the element of pleasant surprise.
Since the last time this was posted, I found this other project[1] which uses HTML5 Canvas to create cards. This lets you rearrange elements on the card more freely, though the end result needs to be saved on the server or downloaded as an image. Definitely some interesting tradeoffs either way!
I do! I missed the "web command-line" functionality so much I made a self-hosted replacement for it that can be run from a local file[0].
If you add it as your default search provider you can use it directly from the address bar, and at that point it works very similarly to DDG bang syntax (although it does a few other things apart from bookmarks as well).
> 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.
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.
Given the terminals you listed above, I assume you are referring to something very specific when you say "show images properly". However, there is a lot more flexibility to use the terminal of your choice (not to mention compatibility with other programs like tmux) if you don't need pixel-perfect reproduction.
For example, I made an image browser for the terminal [0] based on Terminal Image Viewer [1] (for most image formats) and catimg [2] (for animated GIFs) that doesn't require installing a new terminal. It works great with tmux and SSH and I use it all the time for this purpose (though I didn't initially expect to find it so useful).
YMMV, but I have found that the image quality provided by TIV for example is more than sufficient for the kinds of use cases I tend to have when in a console session and needing to quickly view one or more images. Mostly that involves quickly identifying a particular image file among others in a directory, but it's so much easier to not have to leave the terminal and change contexts that it's often more convenient to reach for it for more general tasks too. Any tradeoff in quality is more than made up for in my view by the convenience of being able to use my regular terminal.
Not sure if anyone remembers the height of ecards as a medium, sometime in the early 2000s in the hazy period after broad popularization of the Internet but before the rise of social media -- or if anyone who remembers them does so with any fondness, given what seemed like their overall jankiness and unreliability even at the best of times.
There was always something spammy-feeling about ecards, and receiving one generally involved visiting a page filled with advertising and pop-ups and all kinds of animations and auto-playing audio. Then, if you wanted to go back and look at them later (perhaps after finding a link in an old email), you would inevitably discover that the card content had long since expired. Given that these were obviously not the sort of links that the Internet Archive would ever get the chance to crawl, the content of these cards was therefore permanently unrecoverable. Perhaps, for some, this ephemerality was part of their charm.
Looking back at the concept of ecards a few years ago from the post-social media world brought back a surprising amount of nostalgia (granted, perhaps misplaced) for a simpler time when the default option for sending greetings and well-wishes to a single person was not necessarily to broadcast them to the entire world simultaneously. However, even more surprising was how desolate the ecard industry had become -- at some point someone asked me if there was an easy way to send a card via email and I just assumed it would be as simple as it always had been years before: go to some site and fill out a few details, and then send a link. But the selection was now somehow worse and more spam-filled than before[0]. Websites were heavy and slow and sometimes broken, required accounts or registration, were filled with unnecessary options, animations and (still) auto-playing audio. The sort of sites where you needed to wait while they "loaded" before viewing or creating a card.
I looked around to see if there wasn't already some kind of simple DIY tool that you could run on GitHub Pages or your own server, but couldn't find anything similar. Obviously whatever niche ecards had originally filled was currently being served by other tools: social media, instant messaging, and of course email and paper cards (both of which still exist, of course).
Even if nobody seemed to miss ecards, there were a few things that were always frustratingly inefficient about the whole process of sending and receiving them, and it was an interesting technical challenge to see if all of that was by necessity or not. For one thing, it never made sense -- even at the height of their popularity -- why a third party needed to be involved at all in the process of sending ecards. Of course, you had to store the card content somewhere, most likely a server, and that server probably needed to pay its bills, which then brings us naturally to ads and tracking and monetization...
But what if you didn't need to store the content on a server? I wanted to see if it was possible (or practical) to store all of the card content (including information about the design and images) in the URL instead. Of course, it's fairly straightforward to build a URL with a bunch of query strings containing all the content of the card. However, apart from the question of privacy[1], the main issue for most normal uses of ecards is "giving away" the content of the card before the receiver has viewed it. One of the few remaining charms of the medium that is not already covered by IM or normal email is the slight element of surprise -- the process of opening the card before knowing what it says. For that reason, the query strings have been minimally encoded -- which seems to work fairly nicely, though it does produce rather long URLs.[2][3]
The most important feature of this implementation is persistence -- the cards are "non-expiring" in the sense that even if the server goes down any card link can be imported and viewed on any other instance of the site, or even locally (the site can be downloaded and opened directly using any browser's file:// protocol). An upcoming feature will be to take a snapshot of the card so it can be downloaded directly, probably using the same approach as the "Save PNG" function here[4].
Another aspect that is (in my opinion) also an improvement on commercial ecard platforms is that you can supply your own image for the card. From a (site) design perspective this is nice because it makes it possible to have a bare minimum of default open licensed imagery as a starting point while still having the flexibility to use any other image if needed (Open Clipart[5], even in its current reduced state, works quite well for this purpose in many cases, though any image will do -- photos work nicely too). This also means not having to worry too much about finding or somehow creating an entire library of (possibly quite cheesy) card content for every possible occasion. Most existing sites seem to be organized around "themes" such as particular holidays or festivals, but with this simpler (and more flexible) approach there is a bit more room for creativity. Having said that, one feature on the to-do list is to add themes for specific occasions (or just example starter cards) by creating an API for the "create card" page -- similar to the "receive card" page -- that would load a preset series of values for each available field.
Hopefully, the above will help to answer questions people might have about why anyone would be interested in something like this. TLDR: nostalgia, experimenting with something new, technical challenge of adding functionality without necessitating servers or third parties, and the element of pleasant surprise.
[1]: Privacy is sort of an added bonus here, given that there are exactly zero cookies or trackers or even local storage being used on the site. However I would be very interested to hear from any experts out there if my assumption that content of HTTPS URLs after the domain name is secure in this context is incorrect.
Thanks for the feedback! This is exactly what I've found it to be useful for as well. Glad you mentioned the "opinionated" aspect of these types of frameworks too -- I should add something about this to the documentation so people have an idea what to expect.
This started as a small collection of minimal (i.e., classless / boilerplate / ultralight) CSS frameworks like Tacit, Sakura, Tachyons and others. It turns out there are a lot of others -- the list now includes 97 (!) different frameworks.
There is a live demo [0] with all the frameworks combined with some HTML5 boilerplate, and also a bookmarklet [1] that embeds the CSS switcher in any page (including web pages and local HTML files).
Those used to working with larger traditional frameworks may find it hard to see the point of minimal CSS frameworks. Igor Adamenko (of awsm.css) has a great and pithy explanation:
> Why? I have to create simple pages in my daily work. Sometimes it's compiled Markdown and sometimes it's pure HTML. I'd like to make them more beautiful without additional classes, ids, etc. So I did it.
These minimal CSS frameworks have also been surprisingly useful for converting Markdown files directly into PDFs [2]. Not all of them lend themselves to this purpose, obviously -- usually the simpler the theme the better.
Suggestions for any minimal frameworks that were missed are very welcome!
I've added Lissom to the big list of minimal CSS frameworks [0] which aims to collect all of these types of projects (more or less) in one place for ease of discoverability and comparison. You can preview the CSS on some HTML5 boilerplate here [1].
[0]: https://github.com/dohliam/dropin-minimal-css
[1]: https://dohliam.github.io/dropin-minimal-css/?lissom