Strength Rules
Each rule is a chip in the markup. The chip turns green when the value passes and red when it fails, and any failing chip blocks the form submit.
Confirm Password
Point a second field at the first with data-password-match. The submit stays blocked until the two values are equal. There are two patterns for showing the result, and both are canonical.
Two Patterns
With a match chip. Use this when the confirm field sits beside strength rules, as the demo above shows. The chip joins the rule list and updates while the user types in either field, so the whole password state reads in one place.
Without a chip. Use this when confirm is the only check on the field. Set data-password-match and ship no rule list. The component still blocks the submit and still shows the mismatch message, because the match test does not depend on chips. This suits a short form where one more chip adds noise.
Do not add a chip only because the demo has one. Pick the pattern that matches the field's role.
Custom Rules
Add data-rule-pattern to a chip and the regular expression becomes the rule. The chip then counts and gates like a built-in one, with no JavaScript to write.
Built-in Features
Activates on any form container that carries the nds-password class. Chips start checking on the first keystroke.
Length, capital letter, small letter, number, and symbol checks are ready to use. Ship a chip for each rule you want.
A regular expression on a chip becomes a working rule, so a project-specific policy needs no JavaScript.
A retype field tracks the first field as the user types in either one, so a mismatch shows before submit.
A failing rule or a mismatch blocks the submit through native constraint validation, with a message under the field.
A hidden live region reports how many rules are met, so the chips are not silent to a screen reader.
The container carries the number of passing rules, ready to drive a strength bar from a stylesheet.
Register rules, force a re-check, and read the current result through the JS API.
Usage Guidelines
Best Practices
- Use this on sign-up, change-password, and password-reset forms, where the user picks a new value and needs to know the policy up front
- Do not use it on a sign-in form. The user already has a password there, so a plain password field from Text Fields is enough
- Ship one chip per rule the server enforces. A chip the server ignores teaches the user a policy that is not real
- Keep
minlengthon the input. The browser enforces it on its own, so length still blocks the submit if the JavaScript never loads - Place
nds-password-rulesinside thedata-feedback-targetfooter, and give every chipdata-permanent. A validation message then takes over that slot and the chips come back when it clears - Prefer
data-rule-patternoveraddRule()for a one-off rule, so the expression sits next to the message the user reads - Anchor a pattern with
^and$when the whole value must match. Without anchors the expression matches anywhere in the value - Write each chip message as the rule itself, such as "One number (0-9)", not as an error. The chip turns red on its own when the rule fails
- Give the retype field a match chip. Without it the mismatch only shows at submit
- Add a hidden username field with
autocomplete="username"above the password fields so password managers save the right credential - Do not treat the strength number as a security measure. It counts chips, not how hard the password is to guess
Structure Classes
| Class | Description |
|---|---|
nds-password | Add to nds-form-container to opt the field into rule checking and match checking |
nds-password-rules | Wrapper for the rule chips, placed inside the data-feedback-target footer. Point the input's aria-describedby at it. The footer has no layout of its own, so this wrapper owns the chip spacing |
nds-password-status | Visually hidden live region that receives the rules-met announcement. Optional, but a screen reader gets no live feedback without it |
Data Attributes
| Attribute | Description |
|---|---|
data-password-match | Set on nds-form-container to a CSS selector for the source input. Makes this field a confirm field. Resolved once at init, so a source field added later needs NDS.Password.reinit() |
data-rule | Set on a chip inside the container. Values: length, upper, lower, digit, special, match. Any other name needs data-rule-pattern or addRule(), otherwise the chip stays grey and is never counted |
data-rule-pattern | Set on a chip to a regular expression. Overrides a built-in name of the same value. The expression matches anywhere in the value unless you anchor it. An invalid expression logs a warning and leaves the chip inert |
data-status | Set on each chip to neutral in your markup. The component switches it to success or error per keystroke. The JavaScript loads after first paint, so a chip without a starting value has no style until then |
data-permanent | Set on each chip. A validation message in the same footer hides the chips instead of destroying them, and they return when the message clears. Without it the chips are dismissed for good on the first error |
data-password-strength | Written by the component on the container: the number of passing chips, and always 0 while the field is empty. Read it in CSS to drive your own strength bar, one rule per level, for example .nds-password[data-password-strength="5"] .my-strength-bar { width: 100%; }. NDS ships no meter element: the bar is yours |
minlength | The native HTML attribute on the input. Sets the threshold for the length rule. Defaults to 8 when absent |
JavaScript API
The NDS.Password API wires containers, registers rules, and reports the current result. Fields already in the HTML are wired for you. Call NDS.Password.init() after adding a field to the page.