Semantic structure
Use the documented Xshna classes with semantic HTML rather than replacing native elements unnecessarily.
Compose existing xsh- classes on the appropriate HTML element. Keep content order meaningful when CSS is disabled.
XSHNA.CSS 3.0 / PRODUCTION HANDBOOK
Migration from Xshna 2
API preservation, changes and compatibility. Practical engineering and integration guidance for serious commercial applications.
Version policy
Version 3 preserves the xsh- prefix and existing static utility naming. New modules and design overrides add behavior and styling, so visual regression testing is required even where classes remain unchanged.
Brand change
The default theme now uses navy blue as --xsh-primary and related soft, focus and dark tokens. Remove any application-level hardcoded purple overrides left from 2.x and revisit color screenshots and brand guidelines.
Icons fix
External sprites are no longer necessary for shipped examples. Existing sites using <svg><use href="xshna-icons.svg#xsh-icon-home">... should validate same-origin HTTP(S), file path and SVG MIME. Prefer copying inlined SVG markup from docs or loading xshna-icons.js and using data-xsh-icon placeholders.
JavaScript lifecycle
The extended module now exposes initAdvanced() and destroyAdvanced(), while the pro module exposes initPro(), destroyPro() and gridRefresh(table). The combined bundle registers these automatically; never load both combined and modular scripts in one page.
Smoke test
Check buttons, tabs, dialogs, dropdowns, command palettes, accordions, sorting/filtering, brand-theme switches and any dynamically mounted content after upgrade. Keep previous assets available for rollback.
Release status: Use the acceptance checklist before representing any feature as independently certified or accessible in all browsers. Tests delivered with the package are evidence of only the checks actually performed.
Files, tokens and configuration
| Surface | Source of truth | What to check |
|---|---|---|
dist/xshna.min.css | Compiled framework | Styling and responsive behavior |
dist/xshna.min.js | Optional interactions | Lifecycle, event handling and teardown |
src/css/ | Readable source | Public class names and token definitions |
src/contracts/ | Published component contracts where available | State, configuration and behavioral support |
Implementation details
Interactive behavior
Verify focus order, disabled behavior and descriptive labels for interactive patterns.
Load xshna.min.js only if the documented interaction needs it. Your application remains responsible for data, persistence and business rules.
Responsive and localization
Test narrow containers, long translations and user-defined text sizes.
Test 320px-wide viewports, container-constrained instances, keyboard zoom, longer translations and right-to-left text where relevant.
Theme and customization
Use --xsh-* CSS variables for theme values and data-xsh-design / data-xsh-density on the xsh-app root.
Prefer design tokens over hard-coded overrides so components remain coherent across personalities.
What to verify before shipping
- Confirm every documented class used by the feature exists in the release CSS.
- Navigate controls using Tab, Shift+Tab, Enter, Space and Escape where appropriate.
- Test with reduced motion, high contrast, 200% text zoom and a narrow mobile viewport.
- Verify disabled, loading, empty, error and long-content states where relevant.
- Check actual application behavior independently of the preview: these examples use illustrative data.