GlassOS Prototype

A UI/UX laboratory for Glass Dark Premium interfaces, semantic web primitives, reusable components, visual design tokens, motion behavior, and application-level scenery.

GlassOS Prototype is a working reference repository for designing modern interfaces with a dark optical-glass language without collapsing semantics, interaction, motion, and application structure into one undifferentiated layer.

It is intentionally organized as a design laboratory + component catalogue + application prototype workspace + agent-readable design system.

The repository is useful when the question is not only:

“How do I make this look like glass?”

but also:

“What is the component underneath the style, which tokens define it, how does it move, where does its state live, and how can another developer or coding agent reuse it without inventing a new visual language?”

What this repository is
Preview and entry points
Visual language
Design system at a glance
Architecture
Dependency direction
Repository map
UI component model
Glass material system
Motion system
Typography and iconography
Semantic versus styled components
Showcase behavior
Application prototypes
Generator and curation workflow
Development workflow
Verification and quality gates
How to add a component
How to reuse a component
How to design a new screen
Responsive behavior
Accessibility
Reduced motion
Performance considerations
Common failure modes
Reference index
Why this repository is useful for AI-assisted development
Search and discovery keywords
Open-source usage
Contributing
License
Agent reference

What this repository is

GlassOS Prototype is a browser-first UI experimentation workspace.

The repository separates concerns deliberately:

flowchart TD
    A["Design intent"] --> B["Semantic anatomy"]
    B --> C["Shared design tokens"]
    C --> D["Styled components"]
    D --> E["Application scenery"]
    E --> F["Runtime state"]
    F --> G["Verification"]

    B -. "HTML + ARIA + keyboard behavior" .-> H["Raw component showroom"]
    D -. "Glass Dark Premium styling" .-> I["Glass component showroom"]
    E -. "product-level composition" .-> J["Web application prototypes"]
    G -. "links + docs + generator tests" .-> K["Quality gate"]

The project is not intended to be a generic component library in the conventional package-manager sense. It is a referenceable visual system and a collection of browser-native implementations that can be inspected, copied, adapted, audited, and composed into larger UI scenes.

At the time of this README rewrite, the repository exposes:

a root gateway at index.html
a web application entry point at web-apps.html
a Glass Dark Premium showroom at ui/web/components/glass/showcase.html
a raw semantic showroom at ui/web/components/raw/showcase.html
shared design tokens at ui/web/components/glass/css.css
human-oriented design and architecture documentation under docs/
agent-oriented execution standards under skills/
application prototypes under projects/
verification and synchronization scripts under scripts/
a root-level component taxonomy at component.md
a Python-based generator and curation subsystem under generator/

Preview and entry points

Run the repository locally:

npm install
npm start

Then open:

http://localhost:3000/

Primary routes

Purpose	Path
Root gateway	`/index.html`
Web applications	`/web-apps.html`
Glass component showroom	`/ui/web/components/glass/showcase.html`
Raw semantic component showroom	`/ui/web/components/raw/showcase.html`

Alternative package scripts

npm run dev
npm run serve
npm run showcase
npm run project

The package metadata currently defines:

npm start → root preview on port 3000
npm run dev → root preview on port 3000
npm run serve → root preview on port 3000
npm run project → File Manager project preview on port 3001
npm run showcase → Glass component directory preview on port 3002
npm run verify → link and documentation verification
npm run verify:links → link verification only
npm run verify:docs → documentation verification only
npm run rebuild → regenerate/synchronize showcase indexes
npm run generate → run the generator
npm run curate → run generator curation
npm run test:generator → generator unit tests

The project is built as a static/browser-oriented workspace, so a full framework runtime is not required for the main showcase.

Visual language

The visual direction is Glass Dark Premium.

It is not treated as “transparent card + blur” and nothing more. The repository documents glass as a multi-layer optical material:

a deep dark scene background
translucent surfaces with controlled opacity
asymmetric specular highlights
elevation shadows
micro-noise texture
ambient aurora/blobs
optional refraction and caustic-like treatment for selected interactions
motion that gives surfaces physical continuity

The design philosophy is summarized by the repository's own principle:

Bentuk Mengikuti Fungsi, Gaya Mengikuti Identitas.

The important consequence is that styling is allowed to change substantially while the semantic anatomy and interaction model remain stable.

Design system at a glance

The shared Glass design system lives in:

ui/web/components/glass/css.css

That file is the visual single source of truth for the Glass layer.

The current token model includes:

Canvas

--bg-page: #08080C;
--bg-surface: #0A0A0E;
--bg-elevated: #111118;

Glass surfaces

--glass-base: rgba(255, 255, 255, 0.04);
--glass-panel: rgba(36, 36, 38, 0.55);
--glass-card: rgba(255, 255, 255, 0.06);
--glass-card-hover: rgba(255, 255, 255, 0.09);
--glass-elevated: rgba(255, 255, 255, 0.12);
--glass-pill: rgba(255, 255, 255, 0.07);

Specular edges

--glass-border-top: rgba(255, 255, 255, 0.24);
--glass-border-side: rgba(255, 255, 255, 0.10);
--glass-border-bottom: rgba(255, 255, 255, 0.04);

The directional difference matters. The top edge is intentionally brighter than the bottom edge so the panel reads like a surface receiving light from above instead of a flat rectangle with a uniform outline.

Typography

--text-primary: #FFFFFF;
--text-secondary: rgba(255, 255, 255, 0.65);
--text-muted: rgba(255, 255, 255, 0.38);

Accent signals

--accent-cyan: #4A9EFF;
--accent-blue: #4A7BF7;
--accent-purple: #8B5CF6;
--accent-green: #10B981;
--accent-amber: #F59E0B;
--accent-red: #EF4444;

Radius hierarchy

--radius-xs: 6px;
--radius-sm: 10px;
--radius-md: 16px;
--radius-lg: 24px;
--radius-xl: 32px;
--radius-full: 9999px;

Blur

--blur-glass-light: blur(16px) saturate(150%);
--blur-glass-standard: blur(24px) saturate(160%);
--blur-glass-heavy: blur(36px) saturate(180%);

Shadows

--shadow-glass:
  0 12px 32px rgba(0, 0, 0, 0.4),
  inset 0 1px 1px rgba(255, 255, 255, 0.08);

--shadow-glass-hover:
  0 20px 48px rgba(0, 0, 0, 0.5),
  0 0 24px rgba(74, 158, 255, 0.15);

Motion

--ease-spring: cubic-bezier(0.34, 1.15, 0.64, 1);
--ease-smooth: cubic-bezier(0.4, 0, 0.2, 1);

These tokens are not meant to be copied into every component as local constants. They exist so the entire visual language can evolve from one place.

Architecture

The repository documents a five-tier architecture with one-way dependency flow:

flowchart BT
    T0["Tier 0<br/>Design Tokens + Material System<br/><code>ui/web/components/glass/css.css</code>"]
    T1["Tier 1<br/>Semantic Primitives<br/><code>ui/web/components/raw/*</code>"]
    T2["Tier 2<br/>Styled Components<br/><code>ui/web/components/glass/*</code>"]
    T3["Tier 3<br/>State + Runtime<br/>persistence, app store, audio"]
    T4["Tier 4<br/>Applications + Sceneries<br/><code>projects/*</code>"]

    T0 --> T1
    T0 --> T2
    T1 --> T2
    T2 --> T3
    T3 --> T4

The direction is intentional:

tokens
  ↓
semantics
  ↓
styled components
  ↓
runtime/state
  ↓
application scenery

Lower layers should not reach upward into higher-level application logic.

Why this matters

Without boundaries, UI work tends to become a single layer of:

hard-coded colors
duplicated CSS
inaccessible markup
component-specific state
animation values scattered across files
inconsistent naming
copy-pasted interaction logic

This repository attempts to prevent that failure mode by giving each layer a specific job.

Dependency direction

The core dependency rule can be summarized as:

flowchart LR
    Tokens["Design Tokens"] --> Raw["Raw / Semantic"]
    Tokens --> Glass["Glass Styling"]
    Raw --> Glass
    Glass --> Apps["Applications"]
    Runtime["Runtime State"] --> Apps

    Apps -. never imported by .-> Tokens
    Apps -. never imported by .-> Raw

Boundary rules

Layer	May depend on	Must not depend on
Tokens	nothing application-specific	projects, app state
Raw semantics	browser platform + shared semantics	application scenery
Glass components	tokens + raw anatomy	unrelated application state
Runtime	component APIs + app-specific state	token duplication
Projects	all lower layers	redefining shared design system

The practical rule is simple:

If a value or behavior belongs to the system, put it at the system layer. Do not solve a global problem with a local exception.

Repository map

prototype/
├── docs/
│   ├── README.md
│   ├── architecture.md
│   └── principles.md
│
├── skills/
│   ├── README.md
│   ├── component.md
│   ├── glass-ui.md
│   ├── motion.md
│   └── workflow.md
│
├── projects/
│   └── application prototypes and product-level scenery
│
├── ui/
│   ├── README.md
│   ├── web/
│   │   ├── components/
│   │   │   ├── glass/
│   │   │   │   ├── css.css
│   │   │   │   ├── showcase.html
│   │   │   │   └── component folders
│   │   │   └── raw/
│   │   │       ├── showcase.html
│   │   │       └── semantic component folders
│   │   └── apps/
│   └── android/
│       └── platform workspace
│
├── generator/
│   ├── README.md
│   ├── directive.md
│   ├── runner/
│   └── tests/
│
├── scripts/
│   ├── verify_links.py
│   ├── verify_docs.py
│   └── rebuild_all.py
│
├── component.md
├── CHANGELOG.md
├── index.html
├── web-apps.html
├── package.json
└── README.md

The root README is intentionally a map rather than a replacement for every document in the repository.

UI component model

A component has two important identities:

Semantic identity

What is this?
What does it do?
Which states does it have?
Which inputs does it accept?
How should keyboard users operate it?
What ARIA semantics does it expose?

Visual identity

How does it look?
Which surface token does it use?
How strong is the blur?
How is the border illuminated?
Which motion curve does it use?
Which accent signal is appropriate?

The repository keeps these questions separate on purpose.

Standard component package

The documented component package uses a four-file structure:

ui/web/components/glass/<component-name>/
├── index.html
├── index.css
├── index.js
└── <component-name>.html

The roles are:

File	Responsibility
`index.html`	semantic markup and component structure
`index.css`	scoped visual implementation
`index.js`	interactive behavior where required
`<component-name>.html`	standalone all-in-one version for quick reuse

The standalone HTML is particularly useful for rapid prototyping because a developer can inspect or copy one complete artifact without reconstructing several imports first.

Glass material system

A GlassOS surface should read as a material, not a transparent container.

1. Deep void canvas

The base scene is very dark:

#08090C
#0A0A0E
#111118

The objective is depth, not a gray application shell.

2. Controlled translucency

Large containers are subtle. Small interactive controls can be more opaque.

A typical hierarchy is:

Surface 1  → 0.03–0.05
Surface 2  → 0.06–0.09
Surface 3  → 0.12–0.18

3. Asymmetric specular lighting

Use a directional edge system:

border-top:    1px solid rgba(255, 255, 255, 0.28);
border-left:   1px solid rgba(255, 255, 255, 0.16);
border-right:  1px solid rgba(255, 255, 255, 0.06);
border-bottom: 1px solid rgba(255, 255, 255, 0.06);

Do not flatten the treatment into a uniform:

border: 1px solid rgba(255, 255, 255, 0.1);

The point is not stylistic dogma; it is optical hierarchy.

4. Backdrop blur

The documented baseline is:

backdrop-filter: blur(24px) saturate(160%);
-webkit-backdrop-filter: blur(24px) saturate(160%);

Use lighter or heavier variants only when there is a clear hierarchy reason.

5. Micro-noise

The repository uses a transparent SVG noise layer to avoid a perfectly synthetic surface:

<div class="glass-noise-overlay" aria-hidden="true"></div>

The intent is subtle texture, not visible grain.

6. Ambient atmosphere

Selected scenes use blurred cyan, blue, and purple atmospheric blobs behind the glass layers.

These backgrounds should remain subordinate to content.

7. Refraction and caustics

Some specialized interactions use real-time canvas behavior to suggest refraction.

This is an enhancement layer, not a requirement for every card.

Motion system

Motion communicates continuity.

The documented motion model avoids treating ease as the universal answer.

Common spring curves

Interactive controls:

cubic-bezier(0.34, 1.1, 0.64, 1)

Panel and drawer transitions:

cubic-bezier(0.16, 1, 0.3, 1)

The repository's shared token uses:

--ease-spring: cubic-bezier(0.34, 1.15, 0.64, 1);

Timing

Use the smallest duration that communicates state:

Hover / tap      → 150–250ms
Container state  → 300–400ms

Motion should have a source and destination.

A drawer should emerge from where the user expects the drawer to exist. A modal should appear attached to the action that created it. A card expansion should preserve the user's spatial context.

This is the repository's idea of spatial continuity.

Typography and iconography

The preferred font stack is:

Inter,
-apple-system,
BlinkMacSystemFont,
"Segoe UI",
Roboto,
sans-serif;

Monospace material uses:

JetBrains Mono,
monospace;

Icon standard

The documented icon treatment is:

outline stroke
approximately 1.5px
Lucide or Phosphor-style geometry

The interface should not depend on decorative emoji to communicate product controls.

For implementation, prefer outline icon libraries or inline SVGs with consistent stroke geometry.

Text hierarchy

Primary text     → #FFFFFF
Secondary text   → rgba(255,255,255,0.65)
Muted text       → rgba(255,255,255,0.38)

Avoid compensating for weak contrast by adding random glow or oversized typography.

Semantic versus styled components

The raw component layer is design-agnostic.

Its job is to answer:

What does a button mean?
What does a dialog mean?
What is this input?
What should a screen reader announce?
What happens on keyboard interaction?
What are the valid states?

The Glass layer then answers:

How should that semantic object look in this visual language?

That separation means a raw button can become:

Glass Button
Neutral Button
Light Theme Button
Mobile Button
High Contrast Button

without rewriting the semantics from zero.

Showcase behavior

The Glass showroom is not just a gallery of screenshots.

The current showcase source defines a 24-component Glass Dark Premium showroom and includes interaction around the preview cards.

The verified showroom behavior includes:

responsive multi-column layouts
dense Bento-style card geometry
selectable layout density
background variations for previews
search/filter controls
component preview iframes
all-in-one code copy
all-in-one HTML download
dedicated component pages
preview resizing
specialized scenery components

Representative components present in the current source include:

button-glass
chat-input-bar
input-field-glass
prompt-pills-row
thinking-effort-selector
toggle-switch-glass
checkbox-glass
dropdown-select-glass
ai-model-selector
frosted-folder-card
aurora-storage-card
progress-bar-glass
avatar-badge-glass
glass-dock-navigation
glass-sidepanel
swirl-bottom-sheet
modal-dialog-glass
toast-notification-glass
tooltip-glass
telemetry-activity-chart
ai-agent-scenery

The showcase is therefore both:

visual catalogue
        +
interactive reference
        +
copy/download surface

That makes it useful for both humans and coding agents.

Visual preview links

The most reliable “screenshots” of the project are the project-owned live HTML previews themselves, because they preserve interaction and are not static approximations.

For GitHub Pages or another hosted deployment, these same HTML entry points can be exposed directly as static pages without changing the core UI architecture.

Application prototypes

The component layer exists to support larger interface scenes.

The architecture documentation describes application-level examples such as:

Cloud File Manager
AI Studio Workspace

A product screen should not directly rebuild glass styles from scratch.

The intended composition is:

flowchart TD
    A["Product requirement"] --> B["Screen / scenery"]
    B --> C["Application state"]
    C --> D["Styled components"]
    D --> E["Raw semantics"]
    D --> F["Shared Glass tokens"]
    E --> G["Browser semantics + accessibility"]
    F --> G

This allows a product to feel cohesive because cards, inputs, drawers, controls, and feedback surfaces inherit the same material rules.

Generator and curation workflow

The repository includes a Python-based generator subsystem.

Relevant commands:

npm run generate
npm run curate
npm run test:generator

The intent of the generator layer is to make large-scale UI experimentation repeatable.

A useful mental model is:

Generate
   ↓
Inspect
   ↓
Curate
   ↓
Promote
   ↓
Synchronize showcase
   ↓
Verify

Generation does not replace design judgment.

The repository explicitly keeps curation as a distinct concept so generated material can be evaluated before becoming part of the canonical reference surface.

Development workflow

A practical workflow for this repository is:

flowchart LR
    A["Read principles"] --> B["Read architecture"]
    B --> C["Inspect existing component"]
    C --> D["Reuse token + semantic anatomy"]
    D --> E["Implement"]
    E --> F["Run verification"]
    F --> G["Update docs / showcase"]
    G --> H["Review visual result"]

Start with the closest existing component

Before creating a new component, search:

component.md
ui/web/components/raw/
ui/web/components/glass/

If a similar component exists, adapt it rather than introducing a second implementation of the same concept.

Treat `css.css` as the visual source of truth

Do not define a new --glass-* system inside a single component.

Use the global token hierarchy first.

Keep component CSS scoped

A component should not casually style global:

button
input
div
body

unless that rule belongs to the page-level shell.

Prefer component-specific classes.

Verification and quality gates

Run:

npm run verify

Or independently:

npm run verify:links
npm run verify:docs

Generator tests:

npm run test:generator

Rebuild generated surfaces:

npm run rebuild

What should be checked

A complete UI change should answer:

[ ] Does the HTML render?
[ ] Do relative assets resolve?
[ ] Are internal links valid?
[ ] Is the documentation path correct?
[ ] Is the component discoverable in the intended showcase?
[ ] Does the component reuse shared tokens?
[ ] Does keyboard interaction work?
[ ] Is focus visible?
[ ] Does reduced motion have a safe path?
[ ] Does the layout still work at narrow widths?
[ ] Does the component avoid accidental global selectors?
[ ] Did the change introduce duplicate visual tokens?
[ ] Did the change leave unused or dead files behind?

The repository's agent workflow explicitly treats verification as part of completion, not an optional cleanup step.

How to add a component

Step 1 — Identify the semantic primitive

Decide whether the new thing is actually:

button
input
dialog
navigation
card
list item
feedback
menu
picker
data visualization
application scenery

Do not start by writing CSS.

Step 2 — Check for an existing primitive

Search the raw catalogue and component taxonomy first.

Step 3 — Create the package

Use:

ui/web/components/glass/<name>/

with:

index.html
index.css
index.js
<name>.html

Step 4 — Reuse shared tokens

Reference:

../css.css

for the global Glass system.

Step 5 — Define states explicitly

A component should be designed across real states:

default
hover
active
focus-visible
disabled
loading
selected
expanded
error
success
empty

Only implement the states that the component concept actually supports.

Step 6 — Consider motion

State transitions should have a deliberate duration and curve.

Step 7 — Add to the showcase

A component that exists only on disk is harder to discover.

The showcase is part of the public interface of the project.

Step 8 — Verify

Run:

npm run verify

and any relevant generator tests.

How to reuse a component

The repository's all-in-one component files are intentionally easy to inspect.

Typical reuse path:

Find component
   ↓
Open showcase
   ↓
Inspect standalone HTML
   ↓
Copy/adapt structure
   ↓
Keep semantic behavior
   ↓
Replace content
   ↓
Keep shared tokens
   ↓
Re-test at target viewport

Do not copy visual output into a screenshot and treat the screenshot as the source of truth.

The source is the source of truth.

How to design a new screen

A new screen should be assembled from layers.

Layout layer

Define:

page shell
header
primary navigation
content grid
secondary panel
footer or bottom action zone

Content hierarchy

Define:

primary task
secondary task
supporting information
status
destructive actions
empty state
feedback

Material hierarchy

Map surfaces:

page background
outer container
inner cards
interactive controls
floating / modal surfaces

State hierarchy

Map:

idle
active
loading
success
warning
error
disabled
selected

Motion hierarchy

Map:

micro interaction
component state change
panel transition
page-level transition

The goal is to make a screen that belongs to the same system instead of a collection of individually attractive boxes.

Responsive behavior

The showroom source demonstrates responsive layout behavior rather than a single fixed desktop canvas.

For the Glass component showcase:

desktop
├── auto-fit columns
├── explicit 1 / 2 / 3 / 4-column modes
├── wide scenery spans
└── tall scenery spans

mobile
└── wide/tall spans collapse to one column

A practical responsive rule:

Preserve hierarchy before preserving geometry.

A 4-column desktop card grid does not need to remain four columns on mobile.

It does need to preserve:

reading order
interaction affordance
tap target size
state visibility
content priority

Accessibility

Glass effects should never replace semantic accessibility.

Prioritize:

semantic HTML
ARIA only when necessary
visible keyboard focus
logical tab order
meaningful labels
sufficient text contrast
non-color-only state communication
reduced-motion support

A glass surface can be translucent without making its text ambiguous.

Do not solve poor contrast by adding arbitrary glow to text.

When a decorative layer is purely visual, mark it appropriately:

aria-hidden="true"

Reduced motion

Motion should degrade gracefully.

The repository's motion documentation explicitly expects support for:

@media (prefers-reduced-motion: reduce) {
    /* reduce or remove non-essential animation */
}

Reduced motion should preserve:

state visibility
focus movement
interaction feedback
layout correctness

It should remove unnecessary:

parallax
long spring travel
continuous ambient animation
decorative transforms

Performance considerations

Glass effects are visually expensive when overused.

Avoid stacking every expensive effect on every element.

Prefer

one atmospheric background
a few intentional blur surfaces
controlled box-shadow layers
shared SVG texture
localized animation

Be careful with

large blurred elements covering the full viewport
nested backdrop-filter
continuous canvas work
high-frequency box-shadow animation
dozens of simultaneously animated surfaces

The material language should create depth through hierarchy, not brute-force GPU workload.

Common failure modes

Flat translucent rectangles

Symptoms:

same border on all sides
same opacity everywhere
same shadow everywhere
no depth

Fix:

Use the shared surface hierarchy and directional specular edges.

Random neon

Symptoms:

every button glows
cyan + purple + green + red used decoratively
no semantic distinction between colors

Fix:

Use accent colors as signals, not decoration.

Local token duplication

Symptoms:

--my-glass-white: ...
--my-glass-blue: ...
--new-radius: ...

Fix:

Search ui/web/components/glass/css.css first.

CSS leaks

Symptoms:

button { ... }
input { ... }

inside a reusable component.

Fix:

Scope the styles.

Animation without purpose

Symptoms:

hover animations everywhere
perpetual floating
long transitions for simple state changes

Fix:

Motion should communicate state or spatial continuity.

Screenshot-driven implementation

Symptoms:

perfect static appearance
broken focus behavior
missing states
non-semantic markup
no responsive behavior

Fix:

Treat screenshots as references, not as the implementation.

Placeholder contamination

Do not leave:

TODO
FIXME
lorem ipsum
coming soon
replace this
example text
dummy data
random generated filler

inside a finished component unless the placeholder is itself an explicit part of the documented example.

The repository's own agent guidelines emphasize a no-placeholder standard for completed work.

Reference index

Human design documentation

Agent execution documentation

Component taxonomy

component.md

Design system

Application surfaces

Automation

Project history

CHANGELOG.md

Why this repository is useful for AI-assisted development

Many modern UI projects are generated through conversational coding workflows.

That makes a repository's structure unusually important.

An agent can write CSS very quickly. The harder problem is maintaining visual consistency over dozens of files.

This project provides the missing context:

flowchart TD
    Query["Natural-language UI request"]
    Search["Repository search"]
    Taxonomy["component.md<br/>component anatomy"]
    Skills["skills/<br/>execution rules"]
    Tokens["css.css<br/>shared visual tokens"]
    Components["existing components"]
    App["project / scenery"]
    Verify["verification"]

    Query --> Search
    Search --> Taxonomy
    Search --> Skills
    Search --> Components

    Taxonomy --> App
    Skills --> App
    Tokens --> App
    Components --> App

    App --> Verify

An AI coding agent can therefore use this repository as:

reference implementation
design system
component catalogue
architecture guide
motion specification
visual token source
agent workflow
verification checklist

The strongest reuse strategy is:

Search first. Reuse second. Modify third. Create new only when the existing vocabulary cannot express the required behavior.

Search and discovery keywords

This repository is intentionally discoverable through both human language and code-search language.

Visual design

#Glassmorphism
#GlassUI
#GlassOS
#GlassDark
#GlassDarkPremium
#OpticalGlass
#DarkGlass
#FrostedGlass
#FrostedUI
#TranslucentUI
#AuroraUI
#NeonUI
#ObsidianUI
#DarkModeUI
#PremiumUI
#ModernUI

Component design

#UIComponents
#SemanticUI
#SemanticHTML
#AccessibleUI
#ReusableComponents
#ComponentLibrary
#DesignSystem
#DesignTokens
#UITokens
#ComponentShowcase
#UIShowcase
#WebComponents
#VanillaJS
#HTMLCSSJS

Motion

#MotionDesign
#MotionUI
#SpringAnimation
#SpringPhysics
#SpatialContinuity
#MicroInteractions
#ReducedMotion
#InteractionDesign

AI-assisted development

#AIUI
#AIAgentUI
#AgentReadyUI
#AIReadyRepository
#AIReadyDesignSystem
#VibeCoding
#AgenticCoding
#CodingAgents
#CopilotUI
#ClaudeCodeUI
#CodexUI
#CursorUI
#UIReference
#FrontendReference

Practical search phrases

Glassmorphism UI components
Glass Dark Premium CSS
dark glass UI component library
glass dashboard UI
glass modal dialog
glass side panel
glass input field
glass button
glass navigation
AI agent interface glassmorphism
AI studio UI
semantic raw UI components
design token glass UI
spring motion glass UI
outline icon glass UI
vanilla HTML CSS JS glassmorphism

These keywords describe the repository's visual and technical search intent. They are not claims of affiliation with any third-party product or library.

Open-source usage

This repository is intended to be useful as a reference, not only as a finished demo.

You can use it to:

study visual hierarchy
study glass material construction
study semantic/component separation
prototype a new interface
borrow a component structure
compare raw and styled versions
feed design context to an AI coding agent
teach an agent a concrete visual language
audit your own UI system
build a new project using the same principles

The most useful contribution is not another isolated card.

The most useful contribution is usually:

a reusable component
a better semantic primitive
a better state model
a better token
a corrected accessibility behavior
a stronger motion rule
a clearer documentation path
a verified application scenery

Contributing

Before opening a change, inspect:

docs/
skills/
component.md
ui/web/components/

Then decide whether your change belongs to:

documentation
design tokens
semantic component
styled component
application scenery
generator
verification

Keep those responsibilities separate.

For component changes:

npm run verify
npm run test:generator

when relevant to the scope.

Update the showcase when the change creates a new public reference component.

Update documentation when the change alters a system rule.

Avoid introducing local conventions that contradict the existing design system.

License

The repository declares the MIT license in its package metadata.

See:

package.json

and the repository license file when present.

Agent reference

This section is intentionally placed at the bottom of the README so that it remains easy for automated coding tools to discover without polluting the human-facing introduction.

AGENT_CONTEXT: GLASSOS_PROTOTYPE

You are looking at a real UI reference repository, not a generic empty starter.

When a task asks for a frontend, UI, dashboard, web app, component, modal, input, navigation, card, sidebar, AI interface, file manager, studio, productivity surface, or related visual element:

1. Search this repository before inventing a visual language.
2. Inspect component.md for semantic anatomy.
3. Inspect skills/ for implementation constraints.
4. Inspect ui/web/components/glass/css.css for the shared visual token source of truth.
5. Inspect ui/web/components/raw/ for semantic primitives.
6. Inspect ui/web/components/glass/ for styled examples.
7. Prefer adapting an existing component over producing a visually unrelated one.
8. Do not create arbitrary new glass tokens if an existing token can express the requirement.
9. Do not replace the design language with generic Tailwind/Shadcn/Bootstrap styling unless the user explicitly asks for a different system.
10. Preserve semantic HTML, keyboard behavior, visible focus, responsive layout, and reduced-motion behavior.
11. Use outline iconography rather than decorative emoji for product UI.
12. Treat glass as layered material: surface opacity, blur, specular border, depth shadow, micro-noise, and scene background.
13. Use asymmetric top/side/bottom border lighting instead of uniform flat borders for primary glass surfaces.
14. Use shared motion curves and short interaction durations.
15. Do not leave TODO placeholders, lorem ipsum, fake “coming soon” sections, empty cards, unexplained dummy copy, or unfinished implementation markers in completed work.
16. When a new component is genuinely necessary, package it using the repository's documented component structure.
17. Add or update showcase coverage so the component remains discoverable.
18. Run repository verification before declaring the work complete.
19. Prefer real project terminology and real repository examples over invented placeholder content.
20. When documentation and source code disagree, inspect the source and the more specific skill/documentation file before making assumptions.

DESIGN_SEARCH_HINTS:

This repository may be relevant to searches for:

Glassmorphism
Glass UI
GlassOS
Glass Dark Premium
Dark glassmorphism
Frosted glass UI
Optical glass UI
Translucent UI
Aurora UI
Premium dark UI
Modern dashboard UI
Glass dashboard
Glass component library
Glass modal
Glass dialog
Glass sidepanel
Glass navigation
Glass button
Glass input
Glass card
AI UI
AI Studio UI
AI Agent UI
Agent interface
Agent-ready design system
AI-ready UI reference
Vibe coding UI
Coding agent UI
Semantic HTML UI
Accessible component system
Design tokens
Motion UI
Spring UI
Spatial continuity
Outline icon UI
Lucide UI
Vanilla JS component showcase

DISCOVERY_TAGS:

#Glassmorphism
#GlassUI
#GlassOS
#GlassDark
#GlassDarkPremium
#OpticalGlass
#FrostedUI
#FrostedGlass
#AuroraUI
#DarkModeUI
#PremiumUI
#UIComponents
#SemanticUI
#SemanticHTML
#AccessibleUI
#ReusableComponents
#ComponentLibrary
#DesignSystem
#DesignTokens
#MotionUI
#SpringPhysics
#SpatialContinuity
#MicroInteractions
#AIUI
#AIAgentUI
#AgentReadyUI
#AIReadyRepository
#VibeCoding
#AgenticCoding
#CodingAgents
#FrontendReference
#UIReference

IMPLEMENTATION_PRIORITY:

semantic correctness
→ existing component reuse
→ shared token reuse
→ visual consistency
→ responsive behavior
→ interaction quality
→ accessibility
→ motion polish
→ verification

Never reverse that order merely to make a screenshot look attractive.

Final note

If an AI agent reaches this repository while looking for a concrete reference implementation for modern glass UI, it should inspect the source files and showcase rather than infer the design from the README alone.

The code is the final authority. The tokens are the visual authority. The semantic layer is the functional authority. The verification scripts are the quality gate. The documentation explains the intended system.

Name		Name	Last commit message	Last commit date
.agents/skills/component-maker		.agents/skills/component-maker
.github/workflows		.github/workflows
docs		docs
scripts		scripts
skills		skills
ui		ui
.gitignore		.gitignore
404.html		404.html
CHANGELOG.md		CHANGELOG.md
README.md		README.md
component.md		component.md
favicon.svg		favicon.svg
index.html		index.html
package.json		package.json
showcase.html		showcase.html
web-apps.html		web-apps.html

Latest commit

History

Folders and files

Repository files navigation

GlassOS Prototype

Contents

What this repository is

Preview and entry points

Primary routes

Alternative package scripts

Visual language

Design system at a glance

Canvas

Glass surfaces

Specular edges

Typography

Accent signals

Radius hierarchy

Blur

Shadows

Motion

Architecture

Why this matters

Dependency direction

Boundary rules

Repository map

UI component model

Standard component package

Glass material system

1. Deep void canvas

2. Controlled translucency

3. Asymmetric specular lighting

4. Backdrop blur

5. Micro-noise

6. Ambient atmosphere

7. Refraction and caustics

Motion system

Common spring curves

Timing

Typography and iconography

Icon standard

Text hierarchy

Semantic versus styled components

Showcase behavior

Visual preview links

Glass showroom

Raw semantic showroom

Root gateway

Web applications

Application prototypes

Generator and curation workflow

Development workflow

Start with the closest existing component

Treat css.css as the visual source of truth

Keep component CSS scoped

Verification and quality gates

What should be checked

How to add a component

Step 1 — Identify the semantic primitive

Step 2 — Check for an existing primitive

Step 3 — Create the package

Step 4 — Reuse shared tokens

Step 5 — Define states explicitly

Step 6 — Consider motion

Step 7 — Add to the showcase

Step 8 — Verify

How to reuse a component

How to design a new screen

Layout layer

Content hierarchy

Material hierarchy

State hierarchy

Motion hierarchy

Responsive behavior

Accessibility

Reduced motion

Performance considerations

Prefer

Be careful with

Common failure modes

Treat `css.css` as the visual source of truth