Title Styling with utility classes
Aviator draws inspiration from Tailwind CSS, the massively-popular CSS framework, in that it encourages (but does not require) you to combine single-purpose utility classes to style elements in your HTML.
Instead of only writing CSS the ‘traditional, semantic’ way, which requires you to manage code in two separate contexts:
<p class="myclass">Hello, World!</p>
.myclass{
color:red;
}
...you have the option of including special utility classes directly in the markup itself.
<p class="color:red">Hello, World!</p>
Tailwind CSS does a great job of extolling the virtues of the utility CSS approach, but Tailwind has a few shortcomings (in our opinion) that inspired Aviator’s unique syntax.
Why not use Tailwind CSS?
While Tailwind CSS is an industry standard for modern front-end development, there are several reasons why Aviator uses a proprietary syntax instead:
-
Tailwind CSS wasn’t designed for WordPress. Tailwind CSS requires a build process, something that most WordPress sites don’t employ, especially during live development in a builder. It’s tailored to scan HTML files and JavaScript components for their utility classes as you save your files, writing the output to a static CSS file.
Because WordPress content takes a different path to the database, incorporating Tailwind CSS (and getting instant visual feedback as you author your styles) isn’t feasible in a WordPress page-building environment.
Note: a plugin for supporting Tailwind CSS utilities is on the roadmap for Aviator, as Tailwind Plus provides some of the web’s most elegant and well-designed componentry.
-
Tailwind CSS class names, though sensible, are opinionated and require ‘mental parsing’ as you scan them. Any CSS framework is going to have a learning curve (Aviator is no different, and it has its own opinionated utilities as well). However, most Tailwind CSS utilities sacrifice clarity for brevity, which can introduce a kind of ‘parsing friction’ that traditional, semantic CSS does not.
For example, take a glance at this short snippet of Tailwind CSS markup:
<div class="flex flex-col"> <p class="text-sm text-gray-800 tracking-tight opacity-75">Hello, World!</p> </div>
If you’re new to Tailwind CSS, it might not be immediately apparent what’s being styled here:
-
flex is setting display:flex, though ‘flex’ itself is a CSS property name, and flex-col is an abbreviation for flex-direction:column.
- p-4 actually translates to padding:1rem, so you’re doing ‘divide by four’ math every time you encounter a numeric spacing value if you stick with the defaults (quick, what’s 56 / 4?).
- text-sm and text-gray-800 use the same prefix (‘text’) to define font-size and color, respectively. There is no ‘text’ property in CSS, and the values don’t correspond to real CSS values.
- Same with tracking-tight, this is a shorthand for letter-spacing:-0.025em, which isn’t always easy to remember (is it kerning?).
- opacity-75 equates to opacity:.75, but you need to use opacity-100 to get opacity:1.
These are minor nits, and they haven’t really threatened the success of Tailwind CSS in the slightest: if you’re using Tailwind, you just learn them, just like you committed CSS properties and values to memory in your journey to becoming a web developer.
But it does
Aviator’s explicit approach
In contrast, Aviator offers a clearer, albeit slightly more verbose alternative:
<div class="display:flex flex-direction:column"> <p class="font-size:14px color:#1f2937 letter-spacing:-.025em opacity:.75">Hello, World!</p> </div>
As you scan the classes, there’s no mental parsing required. Actual CSS properties and values are separated by a colon, just like in traditional CSS.
-