Kendo CSS Utilities Cheat Sheet

My company decided to use Kendo CSS Utilities

Writing custom CSS classes is tedious and time consuming. It also requires a decent understanding of CSS to do well. Even then, it's easy to make mistakes or overlook edge cases. So we decided to use the predefined Kendo CSS Utilities to speed up development and ensure consistency across our codebase.

But the Kendo CSS Utilities do not have very good documentation. Try going to their documentation site and searching for "display: flex". At the time of writing this there are no results. Even when you do happen to find what you're looking for, site performance is poor and navigation is clunky.

So I gave myself a week to build a cheat sheet that would make it easy to look up Kendo CSS Utility classes and copy them to my clipboard. I also wanted to make it visually appealing and fun to use.

I also wanted to be able to share this with other developers who might find it useful. So if you find yourself using Kendo CSS Utilities, I hope this cheat sheet helps you out!

Why not Tailwind?

Why not just use Tailwind CSS, so you can look up utility classes easily on their excellent documentation site or even right in VSCode? Tailwind also automatically removes all unused CSS when building for production.

Developers don't always get to choose their tools and that's okay. While bad decisions might have been made in the past, there is no reason to rewrite every line of HTML in your codebase when there are more important things to do.

Challenges

I only gave myself a week to build this, so I chose the simplest tools I knew well: Next.js, Tailwind, shadcn/ui, and Vercel.

But that doesn't mean there weren't challenges. The biggest was getting the actual data. I wanted groups, sub-groups, class names and their CSS properties. So I wrote a script to scrape their documentation.

Since the data is fairly static, I scrape the data at build time so that users don't have to wait for this every time they load the page.

Another challenge was making all the data searchable. I used a lightweight library called Fuse.js to do this. It allows for fuzzy searching and is easy to use. The data needing to be searched through is nested, with categories, sub-categories, and classes with names and CSS properties. So I had to flatten the data structure before passing it to Fuse.js.

Server Side Generation (SSG)

Since the data is fairly static, Next.js's Server Side Rendering (SSR) would be overkill, rerendering the same page for every user on every request. Instead, I used Static Site Generation (SSG) to generate the page at build time. This makes the site very fast since the HTML is pre-rendered and can be served from a CDN.