Pre-specification · Concept stage Open for discussion

Write CSS semantics once.
Run on any framework.

as-cssdo is a proposed CSS abstraction standard. A framework-agnostic data contract that maps semantic component classes to any CSS framework — Bootstrap, Tailwind, Bulma, Foundation and beyond. Change the framework. Keep the templates.

This page documents the concept as it was conceived. It is a pre-specification — a starting point for discussion, not a finished product. The ideas here are intentionally open.

The core idea
{ "button.primary": { "bootstrap": "btn btn-secondary", "tailwind": "bg-gray-600 text-white px-4 py-2 rounded", "bulma": "button is-primary" }, "alert.warning": { "bootstrap": "alert alert-warning", "tailwind": "bg-yellow-100 border border-yellow-400 text-yellow-800 p-4 rounded", "bulma": "notification is-warning" } }

One data object. Every framework speaks it.

The problem

Framework lock-in

Templates that use framework classes directly are tightly coupled. Switching from Bootstrap to Tailwind means rewriting every template, every component, every page.

No shared vocabulary

Every framework has its own naming for the same concept. A "primary button" is btn btn-primary in Bootstrap, btn-primary in Bulma, a utility composition in Tailwind. There is no standard.

Repeated migration work

Every project that changes its CSS framework starts the migration from zero. The same mapping problems are solved over and over, by different teams, in different ways.


The concept

A semantic data contract

as-cssdo defines a standard set of semantic component identifiers — button.primary, card.base, alert.warning — and a structured data object that maps each identifier to its implementation in any CSS framework.

The contract is the standard. The implementations are adapters. Frameworks provide their own adapter — or the community does.

Framework adapters

Each framework has an adapter file that implements the contract. Switching frameworks means swapping one adapter for another. Templates use s-btn-primary — never the framework class directly.

Bootstrap Tailwind Bulma Foundation Materialize UIkit

How it works — step by step

1
Define

The contract defines semantic identifiers. button.primary means "the main call-to-action button" — framework agnostic.

2
Map

Each adapter maps every identifier to its framework-specific classes or utility composition.

3
Compile

A compiler reads the contract + adapter and generates the CSS output — a stylesheet of semantic classes ready to use.

4
Use

Templates use only semantic classes. To switch frameworks: swap the adapter, recompile. Templates untouched.


Ecosystem fit

as-starter

The AS Starter is a live demonstration of as-cssdo in action. Its semantic layer (s-* classes) follows the as-cssdo contract, currently mapped to Bootstrap. It proves the concept works in a production application.

assist-series

as-cssdo lives under the assist-series ecosystem — independent, open to contribution, but backed by a working implementation. assist-series provides the infrastructure and the credibility.

Framework authors

The long-term vision: framework authors contribute and maintain their own adapter. Being part of the as-cssdo standard means their framework is accessible to every project that uses the contract.


Roadmap — concept to standard

Phase 1
Proof of concept
  • Define the semantic identifier set
  • Bootstrap adapter — complete mapping
  • Compiler prototype
  • Live demo via as-starter
Phase 2
Multi-framework
  • Tailwind adapter
  • Bulma adapter
  • Adapter contribution guide
  • Documentation site
Phase 3
Community
  • Open source release
  • npm package
  • Framework author outreach
  • Versioned standard spec
Phase 4
Standard
  • Framework authors maintain adapters
  • IDE tooling
  • Build tool integrations
  • as-cssdo spec v1.0

Open questions

This is a pre-specification. The following questions are deliberately left open — they define the discussion, not the answer.

What is the right output format?
CSS classes? SCSS mixins? CSS custom properties? All three?
How granular should the contract be?
Just components (button, card, alert) or also layout, typography, utilities?
How are framework versions handled?
Bootstrap 5 vs 6 may need different adapters. How is versioning managed?
What about framework-specific features?
Some components exist in one framework but not another. How are gaps handled?

Interested in this idea?

This concept is in its earliest stage. If you work on a CSS framework, build developer tools, or simply find this idea worth pursuing — reach out. The standard will be shaped by the people who use it.