A U T O C S S
::::====== ::::: ===== :::::====== ::::======
::::: ===== ::::: ===== :::::====== ::::: =====
============ ===== ===== ===== ===== =====
===== ===== ===== ===== ===== ===== =====
===== ===== ========== ===== ========
::::==== ::::=== ::::===
::::: ::::: :::::
===== ======= =======
===== ===== =====
======== ======= =======
C E L E B R A T I N G
250 Y E A R S O F
A M E R I C A N
I N D E P E N D E N C E
An enterprise-grade, mission-ready web architecture engineered to deliver secure, 508 accessibility compliant, resilient, interoperable, and high-performing digital services at scale—reducing operational risk, technical debt, maintenance costs, and vendor dependency while accelerating modernization and measurable mission outcomes.
- Standards-first: Built directly on semantic HTML, modern CSS, and native web APIs.
- Separation of concerns: HTML defines meaning, CSS controls presentation and interface state, JavaScript handles data and business logic.
- Compliance by design: Accessibility, security, performance, and governance are architectural requirements—not retrofits.
- Controlled implementation: Approved standards and patterns prevent unnecessary complexity and inconsistency.
- Modular delivery: Reusable, independently maintainable components accelerate development across systems.
- Interoperability: Works with current, equally standards-compliant frameworks through native web interfaces.
- Reduced dependency: Minimizes proprietary abstractions, third-party code, vendor lock-in, and attack surface.
- Data-driven operation: Runtime data remains authoritative; presentation adapts without hardcoded application state.
- Lifecycle efficiency: Less code, duplication, technical debt, testing burden, and long-term maintenance.
- Measurable outcomes: Faster delivery, stronger reliability, lower risk, and consistent mission performance.
AutoCSS Architecture - zero-dependency, browser-native SPA + PWA starter. One UI, driven almost entirely by modern HTML and CSS.
JavaScript - thin CRUD transport layer to external APIs — never for UI state, behavior, or presentation - minimizes script attack surfaces.
- HTML = structure — semantic elements only (no
div/span/class/id/data-*). - CSS = all UI styles, heuristics, and behavior — state, color-scheme, visibility, loading, themes — via
:has(),:empty/:not(:empty), container & style queries,@layer, etc. - JS = API transport only — fetch/CRUD, fired through
oninputon state-machine<input>s. No event listeners, no UI logic, one API base. - Zero dependencies — native evergreen-browser features only; no frameworks, no bundler, no build step.
- Single
index.html— full-bleed Holy Grail layout via CSS Grid, SPA, PWA. - Air-gapped layers — complete Separation of Concerns (SOC): no shared hooks and no agreed-upon
vocabulary between HTML, CSS, and JS (which is why
class/id/data-*are banned). No relationship between presentation and data layers via modern CSS. Any layer can be edited and even replaced without touching the others.
The canonical, non-negotiable rules live in CLAUDE.md; the live backlog and
project state live in PROGRESS.json.
Banning inline scripts, event-handler attributes, and innerHTML removes the usual XSS
vectors by construction — so a strict Content Security Policy works from day one,
with no unsafe-inline or unsafe-eval.
Because only semantic elements and real form controls are allowed — never div/span
stand-ins — inaccessibility is effectively unreachable. Real buttons, inputs, and
landmarks deliver WCAG / Section 508 conformance as a property of the markup, not a
retrofit.
AutoCSS is proven by serving one shared UI — hosted at https://autocss.com — remotely to
several independent front-ends, each supplying its own data. The diversity is the proof: one
declarative-first UI approach adapting to anything. Adding a project adds 0 new codebases, 0 build
pipelines, 0 dependencies — one UI serves one product or ten thousand identically.
Current phase (iterative) — 4 demos, each its own repo in the autocss-com org:
| Repo | Demo | Notes |
|---|---|---|
autocss-com/vanilla |
international.dance (ballet studio) | the current AutoCSS architecture as-is |
autocss-com/react |
React reference demo | idiomatic React data-layer; not tied to a product yet |
autocss-com/vue |
Vue reference demo | idiomatic Vue data-layer; not tied to a product yet |
autocss-com/angular |
Angular reference demo | idiomatic Angular data-layer; not tied to a product yet |
The three framework demos are standard/idiomatic instances of each framework — they show how it exposes data and how to call AutoCSS remotely, and are not yet tied to a product (real products are a later iteration). Each builds to static assets and deploys to GitHub Pages via GitHub Actions; the remote AutoCSS UI is attached only after the back-end renders on Pages.
Deferred to a later iteration: the real products (a psychiatrist practice, a Pokémon app, a
Fairfax County / Virginia crime-statistics app, a Bible-study app) and their back-end mappings, plus
WordPress and Joomla — which need more than static GitHub Pages can host (PHP + database +
server runtime). See Autocss-com/ai/.agents/REMOTE-RENDERING-DEMO-BUILD-PROMPT.md for the authoritative plan.
Each demo self-hosts its static front-end on GitHub Pages (custom domains supported). The three framework demos build to static assets (via GitHub Actions) which Pages then serves; the vanilla demo is 100% static and needs no build step.
GitHub Pages is static-only — no server, no database, no secrets — so dynamic features (user accounts/login, saved favorites + notes, payments + store) run against an external hosted backend that the static front-end reaches through its CRUD JS transport. This is the AutoCSS model by design: the front-end never holds data or secrets.
Cross-cutting capabilities — authentication, account, favorites, notes, cart, checkout, store — are built once as generic, single-concern, drop-in modules, so a feature built for one demo drops into another with no rework.