Pré-spécification · Phase de concept Ouvert à la discussion

Écrivez la sémantique CSS une fois.
Exécutez sur n'importe quel framework.

as-cssdo est un standard d'abstraction CSS proposé. Un contrat de données indépendant du framework qui mappe les classes de composants sémantiques à n'importe quel framework CSS — Bootstrap, Tailwind, Bulma, Foundation et au-delà. Changez de framework. Gardez les templates.

Cette page documente le concept tel qu'il a été conçu. C'est une pré-spécification — un point de départ pour la discussion, pas un produit fini. Les idées ici sont intentionnellement ouvertes.

L'idée centrale
{ "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" } }

Un objet de données. Tout framework le parle.

Le problème

Vendor lock-in du framework

Les templates qui utilisent des classes de framework directement sont fortement couplés. Passer de Bootstrap à Tailwind signifie réécrire chaque template, chaque composant, chaque page.

Pas de vocabulaire partagé

Chaque framework a sa propre nomenclature pour le même concept. Un « primary button » est btn btn-primary en Bootstrap, btn-primary en Bulma, une composition d'utilitaires en Tailwind. Il n'y a pas de standard.

Travail de migration répété

Chaque projet qui change de framework CSS recommence la migration à zéro. Les mêmes problèmes de mapping sont résolus encore et encore, par des équipes différentes, de façons différentes.


Le concept

Un contrat de données sémantique

as-cssdo définit un ensemble standard d'identifiants sémantiques de composants — button.primary, card.base, alert.warning — et un objet de données structuré qui mappe chaque identifiant à son implémentation dans n'importe quel framework CSS.

Le contrat est le standard. Les implémentations sont des adaptateurs. Les frameworks fournissent leur propre adaptateur — ou la communauté le fait.

Adaptateurs de framework

Chaque framework a un fichier adaptateur qui implémente le contrat. Changer de framework signifie échanger un adaptateur contre un autre. Les templates utilisent s-btn-primary — jamais la classe de framework directement.

Bootstrap Tailwind Bulma Foundation Materialize UIkit

Comment ça marche — pas à pas

1
Définir

Le contrat définit des identifiants sémantiques. button.primary signifie « le bouton principal d'appel à l'action » — indépendant du framework.

2
Mapper

Chaque adaptateur mappe chaque identifiant à ses classes spécifiques au framework ou à une composition d'utilitaires.

3
Compiler

Un compilateur lit contrat + adaptateur et génère la sortie CSS — une feuille de style de classes sémantiques prête à l'emploi.

4
Utiliser

Les templates utilisent uniquement les classes sémantiques. Pour changer de framework : échangez l'adaptateur, recompilez. Templates intacts.


Ajustement dans l'écosystème

as-starter

AS Starter est une démonstration en direct de as-cssdo en action. Sa couche sémantique (classes s-*) suit le contrat as-cssdo, actuellement mappé sur Bootstrap. Elle prouve que le concept fonctionne dans une application en production.

assist-series

as-cssdo vit sous l'écosystème assist-series — indépendant, ouvert aux contributions, mais soutenu par une implémentation qui fonctionne. assist-series fournit l'infrastructure et la crédibilité.

Auteurs de frameworks

La vision à long terme : les auteurs de frameworks contribuent et maintiennent leur propre adaptateur. Faire partie du standard as-cssdo signifie que leur framework est accessible à chaque projet qui utilise le contrat.


Roadmap — du concept au standard

Phase 1
Preuve de concept
  • Définir l'ensemble des identifiants sémantiques
  • Adaptateur Bootstrap — mapping complet
  • Prototype de compilateur
  • Démo en direct via as-starter
Phase 2
Multi-framework
  • Adaptateur Tailwind
  • Adaptateur Bulma
  • Guide de contribution d'adaptateurs
  • Site de documentation
Phase 3
Communauté
  • Release open source
  • Paquet npm
  • Prise de contact avec les auteurs de frameworks
  • Spécification versionnée du standard
Phase 4
Standard
  • Les auteurs de frameworks maintiennent les adaptateurs
  • Tooling IDE
  • Intégrations avec les build tools
  • Spécification as-cssdo v1.0

Questions ouvertes

C'est une pré-spécification. Les questions suivantes sont délibérément laissées ouvertes — elles définissent la discussion, pas la réponse.

Quel est le bon format de sortie ?
Des classes CSS ? Des mixins SCSS ? Des custom properties CSS ? Les trois ?
Quelle granularité pour le contrat ?
Juste des composants (bouton, carte, alerte) ou aussi layout, typographie, utilitaires ?
Comment gère-t-on les versions de frameworks ?
Bootstrap 5 vs 6 peuvent avoir besoin d'adaptateurs différents. Comment gère-t-on le versioning ?
Qu'en est-il des fonctionnalités spécifiques au framework ?
Certains composants existent dans un framework mais pas dans un autre. Comment gère-t-on les manques ?

Intéressé par cette idée ?

Ce concept est à son stade le plus précoce. Si vous travaillez sur un framework CSS, construisez des outils pour développeurs, ou trouvez simplement cette idée digne d'être poursuivie — contactez-nous. Le standard sera façonné par les personnes qui l'utilisent.