auto-claude: 5.2 - Explain native form validation, input types, and accessibility patterns
This commit is contained in:
@@ -17,6 +17,10 @@
|
||||
"initialCode": "<form>\n <label for=\"name\">Name: *</label>\n <input type=\"text\" id=\"name\" name=\"name\">\n \n <label for=\"email\">Email: *</label>\n <input type=\"email\" id=\"email\" name=\"email\">\n \n <button type=\"submit\">Submit</button>\n</form>",
|
||||
"solution": "<form>\n <label for=\"name\">Name: *</label>\n <input type=\"text\" id=\"name\" name=\"name\" required>\n \n <label for=\"email\">Email: *</label>\n <input type=\"email\" id=\"email\" name=\"email\" required>\n \n <button type=\"submit\">Submit</button>\n</form>",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "The required attribute activates the browser's Constraint Validation API, which checks field values before allowing form submission. When a user tries to submit with empty required fields, the browser automatically focuses the first invalid field, displays a localized error message (\"Please fill out this field\" in English), and blocks the submit event—no JavaScript needed. The :invalid CSS pseudo-class lets you style invalid fields (like red borders), and screen readers announce required fields as \"Email, required, edit text\" so all users know which fields are mandatory.",
|
||||
"diagram": "Native Validation Flow\n\nBefore Submit:\n┌────────────────────────────┐\n│ <input required> │ ← Browser monitors\n│ [empty] │ validity state\n└────────────────────────────┘\n :invalid pseudo-class\n\nOn Submit Click:\n┌────────────────────────────┐\n│ Browser checks: │\n│ ✓ Is field filled? │\n│ ✗ Empty → INVALID │\n└────────────┬───────────────┘\n │\n ↓ Blocks submit\n┌────────────┴───────────────┐\n│ [!] Please fill out this │ ← Localized\n│ field │ browser message\n└────────────────────────────┘\n Focus moved here\n\nCSS States Available:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n:valid → Green border\n:invalid → Red border\n:required → Asterisk icon\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "attribute_value",
|
||||
@@ -41,6 +45,10 @@
|
||||
"initialCode": "<form>\n <label for=\"password\">Password:</label>\n <input type=\"password\" id=\"password\" name=\"password\" required aria-describedby=\"password-hint\">\n <small id=\"password-hint\">Must be 8-20 characters</small>\n \n <button type=\"submit\">Create Account</button>\n</form>",
|
||||
"solution": "<form>\n <label for=\"password\">Password:</label>\n <input type=\"password\" id=\"password\" name=\"password\" required minlength=\"8\" maxlength=\"20\" placeholder=\"Enter password\" aria-describedby=\"password-hint\">\n <small id=\"password-hint\">Must be 8-20 characters</small>\n \n <button type=\"submit\">Create Account</button>\n</form>",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "Constraint attributes define validation rules that the browser enforces automatically. The minlength attribute triggers :invalid state and blocks submission if the value is shorter than 8 characters, while maxlength physically prevents typing beyond 20 characters (a hard limit, not just validation). The pattern attribute accepts regex for complex rules like \"uppercase + lowercase + number\" without any JavaScript validation code. Placeholder text disappears when typing starts, so never use it instead of a label—use aria-describedby to link visible hint text for screen reader users.",
|
||||
"diagram": "Constraint Validation Rules\n\nAttribute Behaviors:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nminlength=\"8\" Validates on submit\n Can type less, can't submit\n Error: \"Too short (min 8)\"\n\nmaxlength=\"20\" Prevents typing\n Keyboard blocked at char 20\n No error (can't violate)\n\npattern=\"...\" Regex validation\n Example: \"[A-Z][a-z]+\"\n Error: \"Match format\"\n\nmin=\"1\" max=\"5\" Number range\n For type=\"number\"\n Error: \"Out of range\"\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\nAccessibility Pattern:\n┌────────────────────────────┐\n│ <label for=\"pw\">Password │ ← Visible label\n│ <input id=\"pw\" │\n│ aria-describedby=\"hint\">│ ← Links to hint\n│ <small id=\"hint\"> │ ← Visible hint\n│ Must be 8-20 chars │ (not placeholder)\n└────────────────────────────┘"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "attribute_value",
|
||||
@@ -70,6 +78,10 @@
|
||||
"initialCode": "<form>\n <h2>Create Account</h2>\n \n <label for=\"fullname\">Full Name *</label>\n <input type=\"text\" id=\"fullname\" name=\"fullname\">\n \n <label for=\"email\">Email *</label>\n <input id=\"email\" name=\"email\">\n \n <label for=\"password\">Password *</label>\n <input id=\"password\" name=\"password\">\n \n <label>\n <input type=\"checkbox\" id=\"terms\" name=\"terms\">\n I agree to the Terms of Service *\n </label>\n \n <button type=\"submit\">Register</button>\n</form>",
|
||||
"solution": "<form>\n <h2>Create Account</h2>\n \n <label for=\"fullname\">Full Name *</label>\n <input type=\"text\" id=\"fullname\" name=\"fullname\" required>\n \n <label for=\"email\">Email *</label>\n <input type=\"email\" id=\"email\" name=\"email\" required>\n \n <label for=\"password\">Password *</label>\n <input type=\"password\" id=\"password\" name=\"password\" required minlength=\"8\">\n \n <label>\n <input type=\"checkbox\" id=\"terms\" name=\"terms\" required>\n I agree to the Terms of Service *\n </label>\n \n <button type=\"submit\">Register</button>\n</form>",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "This form demonstrates layered validation and accessibility best practices working together. Semantic input types (email, password) provide baseline validation and appropriate mobile keyboards, required attributes enforce mandatory fields, minlength adds password security rules, and the visual asterisks (*) in labels give sighted users a hint—but screen readers rely on the required attribute to announce \"Email, required, edit text\". Checkboxes can be required too, forcing users to agree to terms before submission. All validation happens natively in the browser before any server-side processing, saving bandwidth and providing instant feedback.",
|
||||
"diagram": "Complete Form Validation Layers\n\n┌─────────────────────────────┐\n│ <input type=\"email\" │ Layer 1: Type Validation\n│ required │ Layer 2: Required\n│ minlength=\"8\"> │ Layer 3: Constraints\n└─────────────────────────────┘\n\nValidation Execution Order:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n1. Check required (not empty?)\n2. Check type (valid email?)\n3. Check constraints (minlength?)\n4. Check pattern (regex match?)\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nALL must pass to submit ✓\n\nAccessibility Checklist:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n✓ <label for=\"id\"> linked\n✓ Semantic input types\n✓ required attribute (not just *)\n✓ Visible error hints\n✓ Focus outline (keyboard nav)\n✓ Checkbox labeled correctly\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\nBenefits:\n• No JavaScript needed\n• Localized error messages\n• Mobile keyboard optimization\n• Screen reader compatible\n• Instant client-side feedback"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "attribute_value",
|
||||
|
||||
Reference in New Issue
Block a user