JB

CSS Framework

I cracked it at Bootstrap finally and wrote my own CSS framework. Well, currently writing. And rewriting. And rewriting.

I hadn’t heard of tailwind. Don’t @ me.

I stand by my convention for general web pages though. Check my sites source. It’s nice isn’t it?

This is pure, 100% undiluted ADD.

I might have slightly lost my mind while creating some Wordpress websites for a friend.

Some Backstory

I recently started doing up some Wordpress websites for a friend. They have had some lazy development done for them in the past, and have resorted to handling most of their website themselves.

Their website is heavily dependent on Elementor and Thrive, and heavily utilizes caching plugins to achieve reasonable page load times. Unfortunately, their website has some two decades of content and probably about the same amount of years of modifications to the base Wordpress files.

This website is so cooked that I just flatout cannot get it to run under a different domain. I can barely get it to run on my best server. It’s not a performance thing; there’s something going on the core Wordpress code that’s breaking something, and I just can’t put my finger on it with the amount of plugins he’s had make changes.

Adding insult to injury, when I do get things working random things will break. Post images, post layouts, permalinks. You name it, doesn’t matter what I do, doesn’t matter how much I Google for info or prompt AI, I run into massive roadblocks that just stop me in my tracks.

Oh and that’s not the best part!

The best part is that the sheer amount of content, being themed by Elementor and cached by plugins means that database utilization gets smashed to the point that it chokes up constantly. Each page load is >7s, with caching. This project is the first time I’ve ever had to be concerned about inode usage because their caching completely consumed their available blocks!

I decided to strip their content out of their existing site, and import it into a fresh Wordpress installation. Elementor was to be dropped for a theme. Things like recaptcha and Mailchimp forms were to be provided by in-theme plugins, same for the contact form.

This significantly reduces computational cost per page load however it did present a frustrating complication: Wordpress is extremely opinionated.

Fortunately, Understrap exists as a base for Bootstrap-based theming. It does add some complications that might confuse my friend later, however provided that he doesn’t change the wrong settings in Customizer, all should be well.

The side effect is that Understrap - while very feature rich - is rather ‘unclean’. To achieve the desired effect of having Wordpress compile HTML that is compliant with Bootstraps theming, the contributers have had to add a sleuth of runners and various other components to just get things rendering correctly.

I am not throwing shade on Understrap, but I just don’t really want to do more than one or two themes using it.

This whole experience has burned me on Wordpress theming and Bootstrap in general.

Why Create a Framework

I started making websites in Notepad. My original “framework” was Meyer Webs CSS reset with a 12-column responsive grid system.

The only reason that I switched to Bootstrap is because it provided a few handy utilities for me:

I’ve done about 20 websites in Bootstrap now and I’m just kind-of burned on how the HTML has evolved over time. If you look at the source of this page (bootstrap at the time of writing), you’ll see that the HTML is relatively simplistic. But if you were to see a recent business services website that I created, you would have seen a mess of HTML that looked something like this:

<div class='wrapper bg-cover' style='background-image:url(...);'>
    <div class='container'>
        <div class='row'>
            <div class='col-6 mb-md-3'>
                <div class='bg-cover h-100 w-100' style='min-height: 10em; background-image:url(...)'>
                    <div class='p-4'>
                        &nbsp;
                    </div>
                </div>
            </div>
            <div class='col-6 mb-md-3'>
                <div class='p-4'>
                    <h2 class='fs-5 p-0 m-0 pb-1'>Some Header</h2>
                    <p class='p-0 m-0 py-1'>
                        Some paragraph.
                    </p>
                </div>
            </div>
        </div>
    </div>
</div>

This is absolutely insane. All of the styling data is straight there in the HTML. The only purpose this serves is to reduce the style attribute, but it doesn’t negate it like class was meant to.

It also flies in the face of semantic HTML elements. We have so many different elements to choose from and we stick primarily to divs. We also seem to have decided that Navs should be wrapped in unordered lists because that’s what we did in 2006. Hell, the only reason that we use h2 and p is because Google forces us to.

Okay, I looked it up.

<ul> is used for assistive tech to help people navigate websites, not because of web 2.0 trends.

While I was writing this, my intention with navs was to have the following structure to provide a two-tier drop down menu:

<nav>
    <span>
        <a href='/'>Parent Link</a>
        <span>
            <div>Whatever custom layout you choose to put here, it wouldn't have
            mattered.</div>
        </span>
    </span>
</nav>

Compare this against:

<nav>
    <ul>
        <li>
            <a href='/'>Parent Links</a>
            <ul>
                <li>
                    <a href='/'>Child Link</a>
                    <div>
                        Or whatever content you wanted to put here.
                    </div>
                </li>
            </ul>
        </li>
    </ul>
</nav>

Honestly, which would you prefer?

Some ChatGPT prompting seems to indicate that <div> could sit in the place of span. While this is against my preference to avoid the overuse of div, it could be a solution to unordered lists.

Sadly, the whatwg nav element section specifically states that the primary navigation block (<nav>) of the page should contain an unordered list of links.

So I guess for this I’m forced to use unordered lists and put up with it.

For the case of mega menus, it seems that we’re advised to use ul li div to achieve this. Joy.

So I sat back and really thought about this. What do I need?

So I’m creating the CSSFW on these principles.

CSSFW Intentions

The idea of CSSFW is to leverage semantic HTML elements to allow developers to set sane, readable and maintainable HTML structures for their website.

Think:

<body>
    <header class='main-menu'>
        <a href='/'>Brand</a>
        <nav>
            <ul>
                <li>
                    <a href='/'>Parent Item</a>
                    <div>
                        <div class='col-6'>
                            Some content
                        </div>
                    </div>
                </li>
            </ul>
        </nav>
    </header>

This example is to show a couple of things;

  1. The cleaniness of using child inheritance for styling over individually defined element classes.
  2. Usage of structural selects to apply styling over setting classes per element.

Yes, this is fragile, however it can be worked around. The idea of the framework is not to take the wheel for you but to provide some sane defaults to get you started. It’s less of an autopilot and more of a starter motor.

Caveats and Issues

Structural Selectors are Fragile

By applying styling based on structure selectors - such as nav ul li div:first, you’re introduce a scenario where the entire framework breaks when a developer attempts to introduce fancier styling.

I actually can’t think of a good example but let’s just roll with the following:

You might want nav elements to have a background image, but apply specific padding as required. Applying padding and margins to the nav ul li might break the layout of the navbar (for whatever reason), so you might be required to wrap it in a div. This is best explained with an example:

<nav>
    <li style='background-image: url(...);'>
        <div style='background-color: rgba(0, 0, 0, 0.7); padding: 0.25em;'>
            <a href='/'>Link</a>
        </div>
    </li>
</nav>

This could technically be addressed with

nav li 
{
    background-image: url(...);
}

nav li a 
{
    background-color: rgba(0,0,0,0.7);
    padding:          0.25em
}

Actually a more realistic scenario would be applying a semi opac gradient over the top of an image (as I recently encountered) however it’s stick with the background color.

In either case we can apply this with semantic HTML and structural CSS selectors. However in a scenario where that’s not possible, the developer would have to recompile the Sass for their use case.

Generally speaking, I don’t imagine a lot of people want to maintain a separate Sass project to the project that they’re theming up for. I don’t even do that for myself and I have Sass complition built into Jekyll. Most people want to include a CSS file and use its elements.

So in my head, I think the trade off is that the framework will be opinionated that you need to use the specific HTML structure if you want to use it, but you’re welcome to roll your own solution as needed.

Additionally, it could interfere with other HTML structures. Consider:

```