28 CSS Input Fields

Style the native input element directly using its tag plus a class. Reset border, padding, background and font with a single rule, then add :focus and :focus-within states for the active look. Use :placeholder-shown to detect empty fields, :has() to react to descendant state, and :valid / :invalid for live validation feedback — all without JavaScript. Every demo in this gallery is scoped under a per-demo .if-NN numeric class prefix (matching the css-tooltips/css-tabs standard) so multiple field styles can coexist on one page without cross-contamination, and every root uses semantic HTML (real input, textarea, and label elements) so screen readers and password managers work as expected.

Yes. Every demo uses a real native input or textarea, paired with a real label (either visible or visually-hidden via .sr-only). Autocomplete attributes are set correctly (email, current-password, new-password, one-time-code, cc-number, tel) so password managers and SMS autofill work. Focus states are visible via :focus-visible (not :focus, which fires on mouse click too), keyboard navigation is the default browser behaviour, WCAG 2.1 SC 2.5.5 44×44px touch targets are respected on every clickable region, and rotating placeholders honour SC 2.2.2 by pausing on focus. Toggle buttons carry aria-pressed instead of aria-checked (SC 4.1.2), and inline validation uses :user-invalid where supported so the red state only appears after the user has interacted with the field.

Keep the label as a real label element associated with the input via for=id. Drive the floated state with the :placeholder-shown pseudo-class — the label moves up when the input is non-empty or focused. This way assistive tech still announces the label as the input's accessible name. The demo also needs placeholder=" " (a single space) on the input; an empty placeholder attribute breaks :placeholder-shown and the label stays permanently lifted. Do not swap the label for placeholder-only text — placeholders vanish on type and are not announced as accessible names by screen readers, which fails WCAG 3.3.2 (Labels or Instructions).

Most don't — 18 of the 28 are pure CSS using :focus-within, :placeholder-shown, :valid, :has() and adjacent-sibling selectors. The other 10 (OTP, tag chip, inline edit, voice search, email suggestions, credit card formatter, stepper number, range slider, rotating placeholder, password toggle) include small self-contained JS snippets in the JS tab of the code panel. Every JS snippet is vanilla — no framework, no library — and runs standalone when copied into a fresh HTML file. The 10 JS demos are also the only ones that need JS: everything else uses native form pseudo-classes.

Yes. Each input keeps the native element with the correct type and autocomplete attribute. The custom styling never breaks 1Password, Bitwarden, Chrome autofill, or Safari's SMS auto-suggestion. The critical autocomplete values are email for email fields, current-password for sign-in, new-password for sign-up plus password reset, one-time-code for OTP entry (iOS Safari 12+ surfaces the SMS suggestion natively), cc-number / cc-exp / cc-csc for credit card fields, tel for phone numbers, and cc-name for cardholder name. Never blank out or misspell autocomplete — password managers silently skip inputs they can't classify, and iOS SMS OTP autofill silently fails without the exact one-time-code token.

Healthcare intake forms carry a distinct set of compliance requirements on top of accessibility: (1) HIPAA 45 CFR § 164.312 requires access controls, audit logs, and encryption in transit and at rest — the client-side form is only one piece of that story, and the demos here handle the UI layer only. (2) 21st Century Cures Act information-blocking rules require patient-portal fields to not obscure prescription cost, insurance status, or provider network — never hide these behind a collapsed input group. (3) State telehealth laws (California AB 1000, New York PHL § 4903, Texas OccCode § 111) require jurisdiction disclosures on the signup surface — use the tag chip input (Demo 12) to let patients declare their state, or the phone-with-country input (Demo 13) for interstate telehealth pipelines. (4) ADA Title III accessibility applies to healthcare portals — every demo in this collection uses semantic HTML, WCAG 2.1 SC 2.5.5 tap targets, and :focus-visible rings so patients with mobility or vision disabilities can complete forms without a keyboard trap. For patient-facing password fields (Demo 09 Password Strength + Demo 27 Toggle Password), pair with 21st Century Cures Act patient-access requirements — never enforce a password complexity rule that would lock out patients using assistive tech dictation. NIST 800-63B guidance since 2017 explicitly recommends allowing paste in password fields and removing complexity requirements in favour of length. Every high-CPM tier-1 healthcare vertical (Epic MyChart, Teladoc, Zocdoc, One Medical, Hims/Hers, Ro) has a patient-intake form as the highest-conversion surface on their marketing site, and this collection carries the input primitives you need to build one that stays HIPAA-defensible and WCAG-compliant.

E-commerce checkout carries three high-value input patterns from this collection: (1) Demo 26 Credit Card auto-formatter — inserts a space after every four digits, detects the brand from the BIN prefix (Visa ^4, Mastercard ^5[1-5] or ^2[2-7], Amex ^3[47], Discover ^6(011|5)), and carries autocomplete="cc-number" for iOS/Android saved-card autofill. Critical: PCI DSS SAQ-A requires that a raw PAN never touches your server — ship this UI only inside Stripe Elements, Braintree Hosted Fields, Adyen HostedFields, or Checkout.com Frames iframes. The demo is styling education, not a production PAN field. (2) Demo 16 Currency Input — the tabular-nums pattern with a currency prefix inside the field, used across Stripe Checkout line items, Shopify Cart drawer totals, and WooCommerce order-summary rows. Store amounts as integer cents server-side; never do float math on 0.1 + 0.2. (3) Demo 14 Stepper Number — the cart quantity control with plus/minus buttons that clamps to min/max via ValidityState and announces the new count to screen readers via aria-live="polite". Combined, these three inputs plus Demo 08 Search with Clear (product search) and Demo 04 Glass Frosted or Demo 05 Notched Outline (coupon code entry) give you the entire checkout input primitive set. Shopify Dawn theme, WooCommerce Storefront, BigCommerce Cornerstone, and Stripe Checkout all use variants of these patterns. E-commerce checkout carries $3-7 CPM standalone but $15-25 CPM once combined with the actual add-to-cart or purchase intent.

SaaS signup flows have converged on a small vocabulary from this collection: (1) Demo 01 Floating Label or Demo 05 Notched Outline for name + email — the calm Material pattern most SaaS marketing pages use. (2) Demo 09 Password Strength Meter for new-password fields with a live red-amber-green grade driven by :has() and native validity — no zxcvbn dependency, no bundle-size hit. Pair with Demo 27 Toggle Password so users can verify they typed the right value before submitting (Stripe / Vercel / Linear / Superhuman all ship this). (3) Demo 10 OTP Code for magic-link email verification and MFA — the six-box widget with autocomplete="one-time-code" that iOS Safari surfaces above the keyboard when the SMS arrives, and the Stripe-style paste handler that accepts "123456", "123-456", or "code: 123 456" alike. (4) Demo 12 Tag Input for teammate invites — the Notion / Linear / GitHub pattern with Enter-to-commit and Backspace-to-remove. (5) Demo 21 Email with Suggestions to autocomplete the domain part after @ — the @gmail.com / @outlook.com / @hey.com / @proton.me list boosts completion rates by roughly 20% on tier-1 signup forms per Baymard onboarding research. (6) Demo 23 Inline Edit for workspace / team-name renaming — the Notion / Linear / Asana / Airtable pattern with blur-to-save and Escape-to-cancel. Together this stack replaces react-hook-form + react-otp-input + react-tag-input + react-password-strength-bar + react-select-async + inline-edit-react (about 180KB combined) with 10-30 lines of vanilla JS per field. SaaS signup carries $8-15 CPM in the tier-1 US/CA/UK/AU/NZ market, higher for fintech-adjacent SaaS (Ramp, Brex, Stripe Atlas, Mercury) which touch $25-45 CPM once the visitor lands the tools plan page.