My Design System
Why I Created a Design System
I was using Material UI for a project, and the bundle size, combined with the css-in-js approach to styling, resulted in an application that was difficult to render on the server and that had a pretty poor initial load time. I wanted to create a design system that was similar to Material UI / Flutter but that emphasized semantic HTML and a small bundle size.
Also, when creating a Rich Text Editor with Lexical, I found that it was best to not use highly abstracted components, so I tried to create a library of simple components that can be easily rendered on the server and that doesn't use too much CSS and JavaScript.
In summary, the goal of the design system is to create a look that is comparable to other popular design libraries used today while minimizing load time, bundle size, and complexity.
Assumptions
NOTE: This design system uses CSS and JavaScript that are tied together - i.e., some classes are required for components' JavaScript to work correctly. The design system bundles and transpiles client-side JavaScript using webpack, which is why you might want to download the JavaScript and CSS files from the resources section and tweak them / re-transpile them for your own use. If you make changes to the CSS, I recommend you use PostCSS so your changes will appear the same across all browsers.
- you want to use HTMX to create a SPA (Single Page Application),
- you want to use semantic html, but that you want to style components primarily with CSS classes and inline styling,
- your Content Security Policy allows for inline styling,
- you want to use Floating UI for tooltips, menus, dropdowns, and the like,
- you want to have slightly different layouts for desktop and mobile,
- you want to prioritize mobile devices (you want the application that you show the user to always be similar to the mobile device view),
- you do not want to listen to resize events on mobile
Explore the Design System
If you are looking for information about specific components or utility classes, use the links in the list below to find more information about those aspects of the system. Each aspect of the design system should describe the styling, accessability, and JavaScript concerns that go along with it.
If you are looking to learn more about the design system and the decisions made, continue reading below or navigate to the 'General' page for the design system.
If you want the code, navigate to the resources section.
Note that I am still working on documenting the design system. I got tired of writing the documentation and wanted to move onto other things. I will come back and finish / improve the documentation eventually.
Fixed Content
NOTE: Most fixed content can be customized in the desktop.css and bole.css style files rather than in the shared.css files.
About Fixed Content
There are 3 main types of fixed content:- Navbar
- Sidebars
- Floating Action Buttons / Speed Dial
The Navbar is always kept at top: 0, left: 0 with a width of 100vw. There are three sections of the navbar. The sections of the navbar mostly stay the same width as their sidebar sections except for the notifications aside that collapses on smaller screen sizes. The right sidebar should become a drawer at smaller screen sizes.
The Sidebars have a width that varies according to screen size. The sidebars should be drawers on mobile devices and on small screen size on desktop.
Floating Action Buttons / Speed Dials should be styled individually. An example of a floating action button / Speed Dial can be seen in the bottom right hand corner of the screen.
About Drawers
For an element to be a drawer, it should have the .drawer class along with
a .left or .right class with a .sm or .md or .lg class.
The left and right classes control which direction the drawer comes in from, and the sm, md, and lg classes control the width of the drawer - 25vw, 50vw, and 75vw respectively.
The drawer component is opened and closed according to its aria-hidden attribute.
Buttons that should open drawers should have the data-drawer-button attribute with a
data-drawer-el attribute that is equal to a querySelector string that can be used to find the drawer element.
Buttons that should close drawers when clicked should have the data-close-drawer attribute. When clicked, these buttons will find the closest .drawer element and change its aria-hidden
attribute to false.
When drawers are opened a listener is added to the <body> so that the drawer closes whenever a part of the page not covered by the drawer is clicked. For this reason,
the drawer should have the data-click-capture boolean attribute.
Search Icons
About Icon Search
Resources
Click on the individual buttons to download separate files, or click on the All Files button to download a ZIP file of all the code. The code is sent pre-transpiled
for readability.
Click on the VSCode Snippet button to download a copy of the html.json file that will make implementing this design system simpler.