Why Skirbi?

Skirbi exists because of pain inflicted by Tailwind utility classes in Livewire projects and subsequently three days of coding trying to get a girl back.
The three day binge was a portal into a way of thinking that is what you now see as Skirbi: A wish to write semantic HTML and to be able to style things without having to resort to the class based horror that governs the web these days.

Skirbi is designed to be used in a fully offline, 0 build enviroment.

Core principles

The core principles of Skirbi are:

  • YAGNI: 80/20% rule
  • Stay in the light DOM
  • Components are one-shot compilers
  • Attributes are the API
  • Components are resistant to morphing
  • No build phase is needed
  • Seperation of concerns are (strictly) enforced

YAGNI

This is the foundational principle of Skirbi.
Skirbi tries to solve the common problems first and leaves the edge cases open. This is by design. If it works for the 80% it is good enough. Especially if the remaining 20% is hard to solve and introduces too much complexity.

Stay in the light DOM

There is no reason for us to move to the shadow DOM. CSS style leaking is a feature not a bug in the Skirbi world. Cascading stylesheets sorta wants that to happen: it’s in the word. Semantically speaking the shadow DOM solves a problem that is created by working against the cascade.

The light DOM also allows us to just see the source code when we need it the most:

  • inspectable in DevTools
  • styleable with plain CSS

And it plays nice with frameworks such as Livewire because these stay in the light DOM as well.

Shadow DOM solves other problems, encapsulation, and things we don’t have to deal with: React, VueJS and other frameworks exist today.

Attributes are the API

There are no utility classes. No class="px-4 py-2 text-sm font-medium".

Structure is controlled with attributes:

html 
<semtic-grid triptych>

Styling is controlled with attributes:

html 
<button lead>
<button support>
<button antagonist>

The attribute describe a role, a function. They tell you what the element’s role is.

The attributes are stable. They are the public API. Skirbi tries very hard not to introduce utilities unless they are needed.

CSS does the work

Pinta ships no JavaScript for styling. No runtime, no style injection, no style attributes written by JS.

Everything is CSS custom properties and cascade layers. That means:

  • it works without JS
  • it’s overridable at every level
  • it doesn’t fight your existing stylesheets

The layer order is fixed and predictable:

css 
@layer skirbi-base, skirbi-theme, skirbi-components, skirbi-transform,
  skirb-app;

Most people will want to hook into skirbi via: skirbi-base, -theme, -components and the ultimate knock out punch: skirbi-app.

Your overrides always come last. You always win.

Components are one-shot compilers

A Skirbi component runs once when it connects to the DOM. It reads its attributes, renders semantic HTML inside itself, and then gets out of the way. It does not re-render. It does not manage state. It does not run on every frame.

The custom element tag stays in the DOM as a stable CSS hook. The semantic HTML lives inside it.

Components are resistant to morphing

This may come as a surprise when the previous principle says they are one-shot compilers. For Skirbi to work with Livewire it needed to adapt to this reality. Components can opt for more advanced behaviour by using withConnectedSucu.

However, the logic lives inside the component and component authors can opt in to this behaviour and decide for themselves if they need morphing support or not. If you need Livewire support, your choice is essentially to buy into this feature or not use Skirbi and do it yourself.

No build phase

You write some HTML, fire up Caddy or whatever, and you have a working product. No build phase required. Then we went used a personal blog as a test bed: Some SEO tools don’t execute the little bit of JavaScript Skirbi uses. WAVE doesn’t pick it up either, although we still scored 10/10. So.. a screenreader can do work, but it misses some things. Workable.
Smart TVs are the worst: a semtic-site shows its content, but not much actually happens. Quite dumb, honestly. Search engines are like smart TVs, they don’t like custom elements, even when all the content is already there and ready to parse.

No build.. We violated that principle. We now have build tooling. It’s called bolbe. It essentially is an SSR for Skirbi and it’s still experimental.

It also violates the one-shot compiler rule. We are no longer strictly one-shot once you use bolbe.
The build phase, however, is opt-in, and we will try our very hardest, bestest, and mosted to keep it that way. Yes, that is not proper English. We are serious anyway.

Separation of concerns, strictly

  • Structure is not styling
  • Styling is not composition
  • Composition is not integration

Semtic doesn’t know what color anything is. Pinta doesn’t know what an article is. Dibuho doesn’t know it needs to be build or not. Bolbe doesn’t know how your site is deployed. Each package has one job and stays in its lane.

This means you can swap layers. Use semtic without pinta. Use pinta tokens without semtic components. Build your own composition layer on top of semtic. The contracts are stable.

The only violation is in the component library dibuho. This is a more specialised package that deals with both providing components and styling them too.

PS.

She didn’t. But Skirbi is. Booyaa!!