Various CSS work
This commit is contained in:
Janus C. H. Knudsen
parent
ef174af0e1
commit
15579acba8
52 changed files with 8001 additions and 944 deletions
149
CLAUDE.md
149
CLAUDE.md
|
|
@ -126,6 +126,88 @@ The solution follows a clean architecture pattern with these main projects:
|
|||
- `global.json` - .NET SDK version configuration (currently .NET 9.0)
|
||||
|
||||
|
||||
## Implementing New Pages - MANDATORY Checklist
|
||||
|
||||
<CRITICAL>
|
||||
When implementing a new page or feature, you MUST analyze existing patterns BEFORE writing any code. Creating duplicate components or overriding existing styles is a critical failure.
|
||||
|
||||
### Step 1: Identify UI Elements in POC/Design
|
||||
|
||||
List ALL UI elements the new page needs:
|
||||
- Stats cards / KPI boxes
|
||||
- Tables / Lists
|
||||
- Tabs
|
||||
- Badges / Status indicators
|
||||
- Buttons
|
||||
- Cards
|
||||
- Forms
|
||||
|
||||
### Step 2: Read the Component Catalog
|
||||
|
||||
**MANDATORY:** Read `wwwroot/css/COMPONENT-CATALOG.md` before creating ANY new page.
|
||||
|
||||
This file contains:
|
||||
- All reusable components with examples
|
||||
- Correct usage patterns (e.g., tabs use `.active` class, not data attributes)
|
||||
- Design tokens reference
|
||||
- Table/grid patterns with subgrid
|
||||
|
||||
**Component Catalog Location:** `PlanTempus.Application/wwwroot/css/COMPONENT-CATALOG.md`
|
||||
|
||||
### Step 3: Document Reusable vs New
|
||||
|
||||
Before writing code, create a list:
|
||||
|
||||
| Element | Existing Component | File | Action |
|
||||
|---------|-------------------|------|--------|
|
||||
| Stats cards | `swp-stat-card` | stats.css | REUSE |
|
||||
| Tabs | `swp-tab-bar` | tabs.css | REUSE |
|
||||
| Role badge | `swp-status-badge` | cash.css | REUSE (add variant if needed) |
|
||||
| Status badge | `swp-status-badge` | cash.css | REUSE (add variant if needed) |
|
||||
|
||||
### Step 4: NEVER Create Duplicate Components
|
||||
|
||||
❌ **WRONG**: Creating `swp-role-badge` when `swp-status-badge` exists
|
||||
✅ **CORRECT**: Add `.owner`, `.admin` variants to existing `swp-status-badge`
|
||||
|
||||
❌ **WRONG**: Creating `swp-employee-status` for a new status type
|
||||
✅ **CORRECT**: Add `.active`, `.invited` variants to existing `swp-status-badge`
|
||||
|
||||
**Rule:** If a component exists, add a variant class - don't create a new element.
|
||||
|
||||
### Step 5: Add Header Comment to New CSS
|
||||
|
||||
Every feature CSS file MUST have a header listing reused components:
|
||||
|
||||
```css
|
||||
/**
|
||||
* Feature Styles - Description
|
||||
*
|
||||
* Feature-specific styling only.
|
||||
* Reuses: swp-stat-card (stats.css), swp-tab-bar (tabs.css), etc.
|
||||
*/
|
||||
```
|
||||
|
||||
### Common Failure Modes
|
||||
|
||||
1. ❌ **Creating custom stat cards** instead of using `swp-stat-card`
|
||||
- `swp-stat-card` uses `font-family: var(--font-mono)` for values
|
||||
- Custom implementations lose this consistency
|
||||
|
||||
2. ❌ **Using wrong tab pattern** (data attributes instead of classes)
|
||||
- Correct: `<swp-tab class="active">`
|
||||
- Wrong: `<swp-tab data-active="true">`
|
||||
|
||||
3. ❌ **Creating new badge elements** instead of adding variants
|
||||
- ALL badges use `swp-status-badge` with variant classes
|
||||
- Add new variant to cash.css, don't create `swp-role-badge`, `swp-employee-status`, etc.
|
||||
|
||||
4. ❌ **Different font sizes** in tables
|
||||
- Use `var(--font-size-base)` consistently
|
||||
|
||||
</CRITICAL>
|
||||
|
||||
|
||||
## CSS Guidelines
|
||||
|
||||
### Grid + Subgrid for Table-like Layouts
|
||||
|
|
@ -170,6 +252,56 @@ swp-my-table-row {
|
|||
- `kasse.css` - swp-kasse-table / swp-kasse-table-row
|
||||
|
||||
|
||||
### Sticky Header + Tab Content Pattern
|
||||
|
||||
For sider med tabs, brug de **GENERISKE** komponenter fra `page.css`:
|
||||
|
||||
**Struktur (TO NIVEAUER ER KRITISK):**
|
||||
```html
|
||||
<swp-sticky-header> <!-- Generisk - fra page.css -->
|
||||
<swp-header-content> <!-- Generisk - fra page.css -->
|
||||
<swp-page-header>...</swp-page-header>
|
||||
<swp-stats-row>...</swp-stats-row> <!-- optional -->
|
||||
</swp-header-content>
|
||||
<swp-tab-bar>...</swp-tab-bar> <!-- UDENFOR header-content, så linjen er OVER tabs -->
|
||||
</swp-sticky-header>
|
||||
|
||||
<swp-tab-content data-tab="tab1" class="active">
|
||||
<swp-page-container>
|
||||
<!-- Tab 1 indhold -->
|
||||
</swp-page-container>
|
||||
</swp-tab-content>
|
||||
```
|
||||
|
||||
**KRITISK:**
|
||||
- Brug `swp-sticky-header` og `swp-header-content` fra page.css
|
||||
- ALDRIG opret feature-specifikke varianter (swp-cash-sticky-header, swp-employees-header, etc.)
|
||||
- Linjen (border-bottom) er på `swp-header-content`, så den er MELLEM stats og tabs
|
||||
- Tab-bar er UDENFOR header-content, INDEN I sticky-header
|
||||
|
||||
**Reference:** Se `page.css` for styling, `Features/CashRegister/Pages/Index.cshtml` for brug
|
||||
|
||||
|
||||
### Undgå Feature-Specifikke Layout-Komponenter
|
||||
|
||||
**ALDRIG** opret feature-specifikke varianter af layout-komponenter:
|
||||
|
||||
❌ **FORKERT:**
|
||||
```css
|
||||
swp-cash-sticky-header { ... }
|
||||
swp-employees-sticky-header { ... }
|
||||
swp-products-sticky-header { ... }
|
||||
```
|
||||
|
||||
✅ **KORREKT:**
|
||||
```css
|
||||
/* I page.css - én generisk komponent */
|
||||
swp-sticky-header { ... }
|
||||
```
|
||||
|
||||
**Regel:** Hvis en komponent er ren layout (sticky header, grid, container), skal den være generisk og ligge i `page.css`. Feature-specifikke styles er kun til feature-specifikt indhold (swp-cash-stats, swp-employee-table, etc.)
|
||||
|
||||
|
||||
## NEVER Lie or Fabricate
|
||||
|
||||
<CRITICAL> NEVER lie or fabricate. Violating this = immediate critical failure.
|
||||
|
|
@ -242,4 +374,21 @@ swp-my-table-row {
|
|||
break builds.
|
||||
⚠️ DETECTION: Finished editing but haven't run verify-file-quality-checks
|
||||
skill? → STOP. Run it now. Show the output.
|
||||
|
||||
10. ❌ BAD THOUGHT: "I'll create a new component, it's faster than searching for
|
||||
existing ones."
|
||||
✅ REALITY: Creating duplicate components causes style conflicts, inconsistent
|
||||
UX, and maintenance burden. The codebase already has reusable patterns.
|
||||
Duplicating them wastes time on fixes later.
|
||||
⚠️ DETECTION: About to create a new CSS element or ViewComponent? → STOP.
|
||||
Search wwwroot/css/ for existing patterns first. Document what exists vs.
|
||||
what needs to be created. Show your analysis before writing code.
|
||||
|
||||
11. ❌ BAD THOUGHT: "This element looks different in the POC, so I need to create
|
||||
a new version."
|
||||
✅ REALITY: POC files often use slightly different markup for prototyping.
|
||||
The production codebase has established patterns. Match the production
|
||||
patterns, not the POC variations.
|
||||
⚠️ DETECTION: POC uses different element names or attributes than existing
|
||||
code? → STOP. Use the production pattern. The POC is just a reference.
|
||||
</CRITICAL>
|
||||
Loading…
Add table
Add a link
Reference in a new issue