Skip to main content

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.

On this page