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
Commercial release checklist
Definition of release-quality. Practical engineering and integration guidance for serious commercial applications.
Legal and ownership
Have an authorized Warke Technologies representative approve the product name, copyright owner, licensing model, terms of use, redistribution permissions, privacy notice for the tool site and trademark strategy. The current proprietary notice is not an open-source license. Do not publish public unrestricted code downloads without an approved grant.
Security and provenance
Verify checksums, confirm every executable asset is original or properly licensed, review all third-party dependencies, document the security-contact process, and check for remote telemetry or injected analytics. The three design tools should remain client-only.
QA gate
Run all automated tests; capture visual baselines at mobile/tablet/desktop; test supported browser matrix and keyboard/assistive technology. Verify all documentation links, example interactions, distribution file MIME, CSP compliance, asset cache paths and that the icon catalogue appears. Log test dates and named owners.
Support and versioning
Adopt SemVer. Bug fixes use patch versions; backwards-compatible features use minor versions; changes to documented CSS/JS APIs require a major release. Provide a migration document and a deprecation cycle for removed classes. Make every release archive immutable and retain previous version downloads.
Deployment acceptance
Deploy first to a staging site under the final host configuration. Validate paths through Cloudflare/cPanel/LiteSpeed, minified assets, desktop/mobile docs, Studio/Doctor/Extract, and download exports. A customer-facing announcement should follow—not precede—signoff.
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.