Maintaining open-source is brutal, and feeling obligated to acknowledge, review, and respond to every attempt to contribute is a huge burden to carry.
When I saw this tweet from @dhh the other day I couldn't help but s/email/open source contribution/, but it makes me feel horribly guilty to suggest that anyone should feel anything but grateful for unsolicited free work from contributors.
But the reality is even though folks are generally trying to help by contributing, those contributions still cost the maintainer more than they cost the contributor, in terms of time to review, stress worrying about making time to review, and long term maintenance.
And unlike email where as long as you can convince yourself it's totally fair to not respond to unsolicited email it's okay, on GitHub there's a public counter signaling to the rest of the world that you are a poor steward of your project if you can't keep the number low.
And also unlike email, the only way to ignore something while also dismissing it from your "inbox" is to take an explicit action (closing the issue/PR) that sends a notification to the person, highlighting how rude you are if you don't craft a thoughtful reason for closing.
It's a tough problem because no one really wants to discourage contributions, it's great to have help from talented people who can fix things you haven't had time to fix, but something about it in practice just always feels impossible to keep on top of.
Almost all popular open source projects on GitHub have *hundreds* of open issues/PRs, many even *thousands*. That's way beyond the event horizon, those contributions will *never* be addressed.
All they do is sit there creating guilt.
I don't know what the answer to this whole problem of managing contributions really is but "closed to contributions" unintuitively feels like the only strategy I've seen to actually making open-source maintenance feel sustainable.
You'd think crowd-sourcing maintenance would help, but it actually creates more work than it could ever save. It's a shitty reality because it's really hard psychologically to convince yourself that you're not being an unappreciative asshole by not responding to every issue/PR 😕
• • •
Missing some Tweet in this thread? You can try to
force a refresh
This is a great example of why you need more control when implementing dark mode than just reversing the color scheme or overriding basic variables like "--color-primary" or similar.
Short thread pointing out some of the neat design decisions here 👉
1. The top banner – the background color changes a bit and so does the link, but it doesn't *invert*, it's still light on dark in both versions.
Dark sections shouldn't be inverted to light in dark mode, you'd get a blinding light block — bad in dark environments.
2. The background switches from light to dark, but in the light design it's a solid color, and in the dark design it's a gradient. You can't do this by changing a color variable.
.@bradlc who built the entire website. I absolutely did not expect us to have time for all the insane interactions and animations. He managed to do everything I ever dreamed of plus more, and the APIs he created for it are a delight to work with.
.@malfaitrobin who worked side-by-side with me to develop all of the new features in Tailwind CSS v2.0, and took on the massive job of updating Tailwind UI to take advantage of all the new features. He built an entire automated system that can idempotently update our templates 🤯
❌ Not an alternative to Tailwind UI
❌ Not a predesigned UI kit
❌ Not styled at all
❌ Not in any way tied to Tailwind, there is no CSS or classes or anything of any kind in the library
Instead, it’s a set of low-level completely unstyled primitives that let you build *custom* versions of common components faster, *with your own design you bring yourself*.
This is what a menu button renders by default (that’s the default browser focus ring, not bundled CSS):
If you haven't seen us hinting at it, Headless UI is a set of completely unstyled, fully accessible UI primitives that make it really easy to build custom controls that are super easy to customize and style.
It's the component library I've always dreamed of 😍
Here's a quick demo of the Menu Button component in React:
Learned today that using the box shadow property to create custom focus styles is insufficient because high contrast mode on Windows doesn’t render box shadows at all.
The hoops you have to jump through on the web are unbelievable, it’s no wonder everything is inaccessible :/
Here’s a relevant link, thanks @david_luhr for teaching me about this one 🥴
Take away is if you want a custom focus style that follows an element’s border radius, literally only option is pseudo elements that are absolutely positioned relative to the main element so they aren’t in the document flow. No one does this of course though 😶
Four hours of trying to build an "unprose" feature for the Tailwind typography plugin and I have determined that it is essentially impossible.
The inevitable conclusion is "create a CSS variable for every inheritable property" which is just, no.
Selectors like this get you very close, but the nail in the coffin is anything added to the `prose` class itself that is inheritable:
These styles are inherited to children even if you stick an `unprose` in between and there's literally nothing you can do about it beyond `all: initial` (unset maintains the inheritance), which also overrides reset styles you _do_ want to preserve from elsewhere in your CSS.