3 ms·
The inclusive components approach is rather beautiful. No frameworks (so it works in all frameworks that are standards compliant), and it is accessible and sema
by Blahah 5y ago
The inclusive components approach is rather beautiful. No frameworks (so it works in all frameworks that are standards compliant), and it is accessible and semantic:
- https://inclusive-components.design/collapsible-sections/ https://inclusive-components.design/collapsible-sections/.
Github's elements collection (custom elements/web components) includes several beautifully implemented `details` based approaches to UI problem:
- https://github.com/github/github-elements https://github.com/github/github-elements
Doing this stuff in React is really quite over-complicating it (and making it practically less accessible/reusable). React is uniquely bad for the web among the most popular frameworks:
- https://custom-elements-everywhere.com/ https://custom-elements-everywhere.com/
- nawgz 5y ago> Doing this stuff in React is really quite over-complicating it (and making it practically less accessible/reusable) I find it hard to understand how implementing components within a framework your entire company presumably uses would "[make] it practically less accessible/reusable". I especially take issue with the word "practically", as I can see from some theoretical point of view that an HTML-only component would "enable reuse across all frameworks", but practically speaking I never see people mix frameworks, because that of course would be horrible for performance and real-world reuse.
- Blahah 5y agoGood points, I was specifically thinking about open source components. I use Web components in various frameworks all the time. The crucial thing is that they aren't a framework - they are just a Web standard.