css-coder
CSS Coder
Guidance for writing CSS that prioritizes web standards, accessibility, performance, and maintainability.
Core Principles
- Web standards first — Use native CSS features before reaching for libraries or frameworks. No Tailwind, no CSS-in-JS unless explicitly requested.
- Accessibility as a requirement — Ensure styles support, never hinder, assistive technologies. Respect user preferences (motion, color scheme, contrast).
- Performance matters — Minimize repaints, avoid layout thrashing, use efficient selectors.
- Readable over clever — Future maintainers (including the author) should understand the code at a glance.
- Explicit over implicit — Avoid magic numbers and unexplained values. Use custom properties for shared values.
Workflow
- Check references first — Before writing CSS, consult
references/patterns.mdfor established patterns and snippets. - Validate against specs — When uncertain, reference MDN Web Docs or CSS specifications.
- Suggest alternatives — Offer ideas beyond the skill's patterns when appropriate, but always aligned with the core principles above.
Writing Guidelines
Selectors
- Prefer class selectors over element or ID selectors for styling.
- Keep specificity low and predictable.
- Avoid deep nesting (aim for 2-3 levels maximum).
Custom Properties
- Use
--prefixed custom properties for colors, spacing, typography, and other repeated values. - Define at
:rootor appropriate scope. - Name descriptively:
--color-primary,--spacing-md,--font-size-body.
Logical Properties
- Always use logical properties (
margin-inline,padding-block,inset-inline-start,block-size, etc.) instead of physical properties (margin-left,padding-top,left,height, etc.). - Logical properties support internationalization and different writing modes automatically.
- Only fall back to physical properties where logical equivalents do not yet exist.
Units
- Use
remfor typography and spacing (respects user font-size preferences). - Use
emfor component-relative sizing when appropriate. - Use viewport units (
vw,vh,dvh) thoughtfully, with fallbacks where needed. - Avoid
pxfor font sizes; acceptable for borders, shadows, and fine details.
Colors
- Use modern space-separated syntax for all color functions (
rgb(),hsl(),oklch()). - Recommend
oklch()for vibrant or wide-gamut colors. - Use relative color syntax to derive hover states or transparent variants from existing variables.
- See
references/patterns.mdfor syntax examples.
Layout
- Use CSS Grid for two-dimensional layouts, or when vertical flow is needed without extra declarations.
- Use Flexbox for one-dimensional alignment, noting it defaults to
rowdirection. - Avoid floats for layout (legacy use only).
Media Queries
- Use modern range syntax:
@media (width < 48rem),@media (width >= 48rem). - Prefer Shared First over mobile-first: define shared styles outside queries, scope viewport-specific styles with bounded queries.
- Keep breakpoints to a minimum — add more only when there's a clear need.
- See
references/patterns.mdfor detailed examples.
Accessibility
- Never use
display: noneorvisibility: hiddento hide content that should remain accessible to screen readers. Use appropriate techniques from the references. - Respect
prefers-reduced-motion,prefers-color-scheme, andprefers-contrast. - Ensure sufficient color contrast (WCAG AA minimum, AAA preferred).
- Maintain visible focus indicators — never remove
:focusstyles without replacement.
Performance
- Avoid expensive properties in animations (prefer
transformandopacity). - Use
will-changesparingly and only when needed. - Minimize use of
*selectors. - Prefer
@layerfor managing cascade when working with larger codebases.
References
Consult references/patterns.md for:
- Visually-hidden utility
- User preference queries (motion, color scheme, contrast)
- Modern color syntax and relative colors
- Shared First responsive patterns
- Any project-specific conventions
This file will grow as patterns are added. If a needed pattern doesn't exist, suggest one aligned with the core principles.
More from schalkneethling/webdev-agent-skills
frontend-security
Audit frontend codebases for security vulnerabilities and bad practices. Use when performing security reviews, auditing code for XSS/CSRF/DOM vulnerabilities, checking Content Security Policy configurations, validating input handling, reviewing file upload security, or examining Node.js/NPM dependencies. Target frameworks include web platform (vanilla HTML/CSS/JS), React, Astro, Twig templates, Node.js, and Bun. Based on OWASP security guidelines.
188semantic-html
Write well-considered semantic HTML that serves all users. Use when creating components, page structures, or reviewing markup. Emphasizes native HTML elements over ARIA. Treats proper document structure and accessibility as foundations rather than afterthoughts.
163css-tokens
Provides foundational CSS design tokens (custom properties) for typography, spacing, colors, borders, z-index, and transitions. Use when setting up a base token system for a web project.
17frontend-testing
Write tests that start with acceptance criteria, then add implementation tests for robustness. Use when writing unit tests (Vitest), end-to-end tests (Playwright), visual regression tests, or accessibility tests. Emphasizes user-centric testing, semantic locators, accessibility validation, and the balance between acceptance and implementation testing.
16component-scaffolding
Generate Drupal/Twig component skeletons with web components and Miyagi validation. Use when user requests to create, scaffold, or add a new component at a specific path (e.g., "add component skeleton at patterns/share-button"), or when creating component files including Twig templates, CSS, JavaScript web components, JSON schemas, or mock data files.
14component-usage-analysis
Analyse component dependencies and usage patterns in a Drupal/Twig component library. Use when user asks to find where a component is used, check if a component can be safely removed, audit component dependencies, find components using specific properties, or analyse impact of refactoring a component.
13