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.
Single-element disclosures that can be controlled from multiple buttons.
Native details/summary is recommended for simpler disclosure. The advanced accordion script is optional.
A browser-native, namespaced interface framework.
No. Deploy the compiled CSS and optional JavaScript.
Yes. Include the assets in any HTML response.
<div class="xsh-accordion"><details open><summary>What is Xshna.css?</summary><p>A browser-native, namespaced interface framework.</p></details><details><summary>Does hosting need Node.js?</summary><p>No. Deploy the compiled CSS and optional JavaScript.</p></details><details><summary>Can I use this with PHP?</summary><p>Yes. Include the assets in any HTML response.</p></details></div>Use data-xsh-collapse="#xsh-target-id" and aria-controls on a button, and hidden on the target. The JS synchronizes aria-expanded.
<button class="xsh-btn xsh-btn-secondary" data-xsh-collapse="#xsh-collapse-content" aria-controls="xsh-collapse-content" aria-expanded="false">Show technical details</button>
<div class="xsh-card xsh-mt-4" id="xsh-collapse-content" hidden>Additional technical implementation details are available here.</div>Customize this component through --xsh-* CSS tokens, data-xsh-* configuration attributes and documented xsh-* utilities. Use the optional JavaScript distribution only when an interactive behavior is needed.
| 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 |
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.
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.
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.
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.