Consider an original equipment-return form. A technician enters a case-sensitive device alias, a workshop bin label, and a note about a loose connector. Capitalizing the first character of eLab-7 changes the alias, while sentence capitalization is useful for the note.
Give each field the hint its content needs
Use ordinary text inputs for these identifiers and a textarea for the note:
<form id="equipment-return">
<label for="alias">Device alias, including letter case</label>
<input id="alias" name="alias"
autocapitalize="none" spellcheck="false">
<label for="bin">Bin label</label>
<input id="bin" name="bin" autocapitalize="characters">
<label for="note">Return note</label>
<textarea id="note" name="note"
autocapitalize="sentences"></textarea>
</form>
The form intentionally has no form-wide capitalization setting; each field states its own task. The alias field also disables spelling assistance, which is a separate behavior. Neither attribute validates the alias against an inventory record.
The accepted value pairs are none or off, sentences or on, plus words and characters. Avoid relying on an unspecified default when letter case matters. Browser defaults and supported input methods differ.
autocapitalize has no effect on email, url, or password input types, where automatic capitalization is not enabled. Use the right semantic type for an email address instead of changing it to text just to add this attribute.
Keep presentation separate from the submitted value
A CSS rule such as text-transform: uppercase can make a value look uppercase while leaving its underlying text unchanged. A typing hint is another distinct mechanism. If the workshop's bin IDs must be stored in a canonical uppercase form, define that rule in the actual submission system.
For an application whose documented bin identifiers use ASCII letters, digits, and hyphens, an illustrative normalization step is:
function canonicalBinLabel(raw) {
const candidate = raw.trim();
if (!/^[A-Za-z0-9-]+$/.test(candidate)) {
throw new Error('Use the letters, digits, and hyphens on the bin label.');
}
return candidate.toUpperCase();
}
Call it at the application's submission boundary and show a useful error if it rejects the value. Enforce the same policy on the server. This policy is appropriate only because the workshop defines bin IDs that way. Do not apply it to the case-sensitive device alias or assume it is a universal rule for people's names.
The HTML text-input guide explains reading the current .value. Read that value when collecting the return record, rather than inferring it from the field's visual capitalization.
Test typing, paste, and existing records separately
On a supported phone, focus the alias field and enter eLab-7. Check its stored value and confirm the application has not added its own capitalization handler. A physical desktop keyboard does not demonstrate virtual-keyboard behavior, and a headless viewport set to phone width does not open the user's keyboard.
In the bin field, type a test label, then paste a lowercase version. The pasted value may stay lowercase even when the keyboard hint requests uppercase entry. That is why a real canonicalization rule belongs at submission, if the system needs one.
Also load an existing return record. Assigning input.value does not run a virtual keyboard, so the capitalization hint should not be treated as a data migration. Confirm that eLab-7 remains exactly that alias when the record is loaded, saved, and reopened.
Finish the return form by comparing the reopened alias with the equipment label and the bin ID with the workshop's accepted format. The note can use normal sentence entry without changing either identifier's rules.