@olives/devos 2.1.0

package/.agents/skills/modern-web-guidance/guides/forms/autofill-payment-form.md

@@ -0,0 +1,125 @@
+# Build a payment form that follows best practice
+
+Payment forms are the single most critical part of the checkout process. Poor payment form design is a common cause of shopping cart abandonment.
+
+Create a form that makes it as easy as possible for users to enter payment details on desktop and mobile. Ensure the form makes the most of built-in browser features for autofill, validation and data entry constraints.
+
+## How to implement
+
+Outlined below are the most important guidelines for building successful payment forms.
+
+### Use meaningful, valid HTML
+
+Make the most of the elements and attributes built for creating forms:
+
+-   `<form>`, `<input>`, `<label>`, and `<button>`
+-   `type`, `autocomplete`, and `inputmode`
+
+These enable built-in browser functionality, improve accessibility, and add meaning to markup.
+
+### Use the `<label>` element to label form fields for data entry
+
+To label an `<input>`, `<select>`, or `<textarea>`, use a `<label>`. Associate a label with an input by giving the label's `for` attribute the same value as the input's `id`.
+
+### Make the most of HTML attributes
+
+Make it easy for users to enter data, by using the appropriate `<input>` element `<type>` attribute to provide the right keyboard on mobile and enable basic built-in validation by the browser.
+
+Always use `type="email"` for email addresses and `type="tel"` for phone numbers.
+
+```html
+<!-- type="email"/"tel" gives mobile users the right keyboard and enables built-in validation -->
+<input type="email" id="email" name="email" autocomplete="email" required>
+<input type="tel" id="phone" name="phone" autocomplete="tel">
+```
+
+Every `<input>`, `<select>`, and `<textarea>` element SHOULD have an appropriate `autocomplete` attribute, to improve accessibility and help users avoid re-entering data.
+
+### Make buttons helpful
+
+Use `<button>` for buttons. You can also use `<input type="submit">`, but don't use a `div` or some other random element acting as a button. Button elements provide accessible behaviour, built-in form submission functionality, and can easily be styled.
+
+Give each form submit button a value that says what it does. For each step towards checkout, use a descriptive call-to-action that shows progress and makes the next step obvious. For example, label the submit button on your delivery address form **Proceed to Payment** rather than **Continue** or **Save**.
+
+### Use a single name input where possible
+
+Allow your users to enter their name using a single input, unless you have a good reason for separately storing given names, family names, honorifics, or other name parts. Using a single name input makes forms less complex, enables cut-and-paste, and makes autofill simpler.
+
+Allow international names. For validation, avoid using regular expressions that only match Latin characters. Latin-only excludes users with names or addresses that include characters that aren't in the Latin alphabet. Allow Unicode letter matching instead—and ensure your backend supports Unicode securely as both input and output. Unicode in regular expressions is well supported by modern browsers.
+
+### Allow for a variety of address formats
+
+When adding form fields for an address in a payment form, be aware of the variety of address formats, even within a single country. Do not make assumptions about "normal" addresses.
+
+If possible within your data requirements, consider using a single `<textarea>` element for address. This is the most flexible option for a variety of local and international address formats.
+
+### Use autocomplete for billing address
+
+By default, set the billing address to be the same as the delivery address. Reduce visual clutter by providing a link to edit the billing address (or use summary and details elements) rather than displaying the billing address in a form.
+
+Use appropriate autocomplete values for the billing address, just as you do for shipping address, so the user doesn't have to enter data more than once. Add a prefix word to autocomplete attributes if you have different values for inputs with the same name in different sections. For example:
+
+```
+<input autocomplete="shipping address-line-1" ...>
+...
+<input autocomplete="billing address-line-1" ...>
+```
+
+### Show checkout progress
+
+For each step towards payment, use page headings and descriptive button values that make it clear what needs to be done now, and what checkout step is next.
+
+Use the `enterkeyhint` attribute on form inputs to set the mobile keyboard enter key label. For example, use `enterkeyhint="previous"` and `enterkeyhint="next"` within a multi-page form, `enterkeyhint="done"` for the final input in the form, and `enterkeyhint="search"` for a search input.
+
+### Help users avoid re-entering payment data
+
+Make sure to add appropriate `autocomplete` values in payment card forms. Without autocomplete, users may keep a physical record of payment card details or store them insecurely.
+
+```html
+<!-- cc-number tells autofill this is a card number, not a generic number field -->
+<!-- inputmode="numeric" gives a numeric keyboard without the increment/decrement spinner -->
+<!-- DO NOT use type="number" — it adds increment/decrement controls and strips leading zeros -->
+<input id="cc-number" name="cc-number" type="text" autocomplete="cc-number"
+       inputmode="numeric" maxlength="19" pattern="[\d ]{13,19}" required>
+
+<!-- cc-name autofills with the name exactly as it appears on the card; Unicode pattern allows international names -->
+<input id="cc-name" name="cc-name" type="text" autocomplete="cc-name"
+       maxlength="50" pattern="[\p{L} \-\.]+" required>
+
+<!-- cc-exp autofills the full expiry date as MM/YY -->
+<!-- MANDATORY: Place format hints above the input so autocomplete popovers or virtual keyboards do not obscure them during editing -->
+<span id="exp-hint" class="hint">Format: MM/YY</span>
+<input id="cc-exp" name="cc-exp" type="text" autocomplete="cc-exp"
+       aria-describedby="exp-hint" maxlength="5" required>
+
+<!-- cc-csc autofills the security code; DO NOT use type="password" here -->
+<input id="cc-csc" name="cc-csc" type="text" autocomplete="cc-csc"
+       inputmode="numeric" maxlength="4" pattern="[0-9]{3,4}" required>
+```
+
+### Use a single input for payment card and phone numbers
+
+For payment card and phone numbers use a single input: don't split the number into parts. That makes it easier for users to enter data, makes validation simpler, and enables browsers to autofill. Consider doing the same for other numeric data such as PIN and bank codes.
+
+### Validate carefully
+
+You should validate data entry both in realtime and before form submission. One way to do this is by adding a pattern attribute to a payment card input. If the user attempts to submit the payment form with an invalid value, the browser displays a warning message and sets focus on the input.
+
+However, your pattern regular expression must be flexible enough to handle the range of payment card number lengths: from 14 digits (or possibly less) to 20 (or more). Card security codes (also known as CSC, CVC, CVV, or other names) consist of 3 or 4 digits.
+
+Allow users to include spaces when they're entering a new payment card number, since this is how numbers are displayed on physical cards. That's friendlier to the user (you won't have to tell them "they did something wrong"), less likely to interrupt conversion flow, and it's straightforward to remove spaces in numbers before processing.
+
+### Help save users from accidentally missing data fields
+
+Add the `required` attribute to mandatory fields. Modern browsers automatically prompt and set focus for missing data.
+
+## Fallback strategies
+
+Baseline status for enterkeyhint: Widely available. It's been Baseline since 2021-11-02.
+Supported by: Chrome 77 (Sep 2019), Edge 79 (Jan 2020), Firefox 94 (Nov 2021), Safari 13.1 (Mar 2020), and Safari iOS 13.4 (Mar 2020).
+Baseline status for Email, telephone, and URL <input> types: Widely available. It's been Baseline since 2015-07-29.
+Supported by: Chrome 5 (May 2010), Edge 12 (Jul 2015), Firefox 4 (Mar 2011), Safari 5 (Jun 2010), and Safari iOS 3 (Jun 2009).
+Baseline status for inputmode: Widely available. It's been Baseline since 2021-12-07.
+Supported by: Chrome 66 (Apr 2018), Edge 79 (Jan 2020), Firefox 95 (Dec 2021), Safari 12.1 (Mar 2019), and Safari iOS 12.2 (Mar 2019).
+
+Autofill is a progressive enhancement. In browsers that do not support autofill, users will simply need to manually enter their payment details. The semantic HTML constraints (such as `type`, `inputmode`, `pattern`, and `required`) will still function appropriately to validate user input and provide the correct virtual keyboards.

package/.agents/skills/modern-web-guidance/guides/forms/autofill-sign-in-form.md

@@ -0,0 +1,135 @@
+# Build a sign-in form that follows best practice
+
+Use cross-platform browser features to build sign-in forms that are secure, accessible and easy to use.
+
+If users ever need to sign in to your site, then good sign-in form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designed sign-in forms get high bounce rates. Each bounce could mean a lost customer and a disgruntled user—not just a missed sign-in opportunity.
+
+## How to implement
+
+Outlined below are the most important guidelines for building successful sign-in forms.
+
+### Use meaningful, valid HTML
+
+Make the most of the elements and attributes built for creating forms:
+
+- `<form>`, `<input>`, `<label>`, and `<button>`
+- `type`, `autocomplete`, and `inputmode`
+
+These enable built-in browser functionality, improve accessibility, and add meaning to markup.
+
+### Use the `<label>` element to label form fields for data entry
+
+To label an `<input>`, `<select>`, or `<textarea>`, use a `<label>`. Associate a label with an input by giving the label's `for` attribute the same value as the input's `id`.
+
+### Make the most of HTML attributes
+
+Make it easy for users to enter data, by using the appropriate `<input>` element `<type>` attribute to provide the right keyboard on mobile and enable basic built-in validation by the browser.
+
+Always use `type="email"` for email addresses and `type="tel"` for phone numbers.
+
+Every `<input>`, `<select>`, and `<textarea>` element SHOULD have an appropriate `autocomplete` attribute, to improve accessibility and help users avoid re-entering data.
+
+### Make buttons helpful
+
+Use `<button>` for buttons. You can also use `<input type="submit">`, but don't use a `div` or some other random element acting as a button. Button elements provide accessible behaviour, built-in form submission functionality, and can easily be styled.
+
+Give each form submit button a value that says what it does. Use a clear, recognizable label. For example, use **Sign In** rather than **Continue** or **Submit**.
+
+### Use a single name input where possible
+
+Allow your users to enter their name using a single input, unless you have a good reason for separately storing given names, family names, honorifics, or other name parts. Using a single name input makes forms less complex, enables cut-and-paste, and makes autofill simpler.
+
+Allow international names. For validation, avoid using regular expressions that only match Latin characters. Latin-only excludes users with names or addresses that include characters that aren't in the Latin alphabet. Allow Unicode letter matching instead—and ensure your backend supports Unicode securely as both input and output. Unicode in regular expressions is well supported by modern browsers.
+
+### Show sign-in progress
+
+For each step towards sign-in, use page headings and descriptive button values that make it clear what needs to be done now, and what the next step is.
+
+Use the `enterkeyhint` attribute on form inputs to set the mobile keyboard enter key label. For example, use `enterkeyhint="previous"` and `enterkeyhint="next"` within a multi-page form, `enterkeyhint="done"` for the final input in the form, and `enterkeyhint="search"` for a search input.
+
+### Help users avoid re-entering sign-in data
+
+Make sure to add appropriate `autocomplete` values in sign-in forms.
+
+This enables browsers to help users by securely storing sign-in details and correctly entering form data. Without autocomplete, users may be more likely to keep a physical record of sign-in details, or store sign-in data insecurely on their device.
+
+### Validate carefully
+
+Validate data entry both in realtime and before form submission. Use `type="email"` for email inputs — the browser will validate the format automatically. Add the `required` attribute to mandatory fields to prevent empty submissions.
+
+### Put sign-in in its own `<form>` element
+
+Always use the `<form>` element when you're getting users to enter data
+
+Don't wrap inputs in a `<div>` and handle input data submission purely with JavaScript. It's generally better to use a `<form>` element. This makes your site accessible to screenreaders and other assistive devices, enables a range of built-in browser features, makes it simpler to build basic functional sign-in for older browsers, and can still work even if JavaScript fails.
+
+### Don't double up inputs
+
+Some sites force users to enter emails or passwords twice. That might reduce errors for a few users, but causes extra work for all users, and increases abandonment rates. Asking twice also makes no sense where browsers autofill email addresses or suggest strong passwords. It's better to enable users to confirm their email address (you'll need to do that anyway) and make it easy for them to reset their password if necessary.
+
+### Keep passwords private—but enable users to see them if they want
+
+Passwords inputs should have `type="password"` to hide password text and help the browser understand that the input is for passwords. (Note that browsers use a variety of techniques to understand input roles and decide whether or not to offer to save passwords.)
+
+You should add a **Show password** toggle to enable users to check the text they've entered—and don't forget to add a **Forgot password** link.
+
+### Give mobile users the right keyboard
+
+Use `<input type="email">` to give mobile users an appropriate keyboard and enable basic built-in email address validation by the browser… no JavaScript required!
+
+If you need to use a telephone number instead of an email address, `<input type="tel">` enables a telephone keypad on mobile. You can also use the `inputmode` attribute where necessary: `inputmode="numeric"` is ideal for PIN numbers.
+
+### Prevent mobile keyboard from obstructing the Sign in button
+
+If you're not careful, mobile keyboards may cover your form or, worse, partially obstruct the Sign in button. Users may give up before realizing what has happened.
+
+Where possible, avoid this by displaying only the email (or phone) and password inputs and Sign in button at the top of your sign-in page. Put other content underneath.
+
+### Help users to avoid re-entering data
+
+You can help browsers store data correctly and autofill inputs, so users don't have to remember to enter email and password values. This is particularly important on mobile, and crucial for email inputs, which get high abandonment rates. There are two parts to this:
+
+1.  The `autocomplete`, `name`, `id`, and `type` attributes help browsers understand the role of inputs in order to store data that can later be used for autofill. To allow data to be stored for autofill, modern browsers also require inputs to have a stable `name` or `id` value (not randomly generated on each page load or site deployment), and to be in a `<form>` element with a `submit` button.
+1.  The `autocomplete` attribute helps browsers correctly autofill inputs using stored data.
+
+For email inputs use `autocomplete="username"`, since `username` is recognized by password managers in modern browsers—even though you should use `type="email"` and you may want to use `id="email"` and `name="email"`. For password inputs, use the appropriate `autocomplete` and `id` values to help browsers differentiate between new and current passwords.
+
+### Use autocomplete="current-password" and id="current-password" for an existing password
+
+MANDATORY: Use `autocomplete="current-password"` and `id="current-password"` for the password input in a sign-in form. This tells the browser that you want it to use the current password that it has stored for the site.
+
+For a sign-in form:
+
+```
+<input type="password" autocomplete="current-password" id="current-password" …>
+```
+
+### Enable the browser to suggest a strong password
+
+Modern browsers use heuristics to decide when to show the password manager UI and suggest a strong password.
+
+Built-in browser password generators mean users and developers don't need to work out what a "strong password" is. Since browsers can securely store passwords and autofill them as necessary, there's no need for users to remember or enter passwords. Encouraging users to take advantage of built-in browser password generators also means they're more likely to use a unique, strong password on your site, and less likely to reuse a password that could be compromised elsewhere.
+
+### Help save users from accidentally missing inputs
+
+MANDATORY: Add the `required` attribute to both email and password fields. Modern browsers automatically prompt and set focus for missing data.
+
+```html
+<input type="email" id="email" name="email" autocomplete="username" required>
+<input type="password" id="password" name="password" autocomplete="current-password" required>
+```
+
+### Allow password pasting
+
+Some sites don't allow text to be pasted into password inputs.
+
+Disallowing password pasting annoys users, encourages passwords that are memorable (and therefore may be easier to compromise) and, according to organizations such as the UK National Cyber Security Centre, may actually reduce security. Users only become aware that pasting is disallowed after they try to paste their password, so disallowing password pasting doesn't avoid clipboard vulnerabilities.
+
+### Fallback strategies
+
+Baseline status for Email, telephone, and URL <input> types: Widely available. It's been Baseline since 2015-07-29.
+Supported by: Chrome 5 (May 2010), Edge 12 (Jul 2015), Firefox 4 (Mar 2011), Safari 5 (Jun 2010), and Safari iOS 3 (Jun 2009).
+Baseline status for inputmode: Widely available. It's been Baseline since 2021-12-07.
+Supported by: Chrome 66 (Apr 2018), Edge 79 (Jan 2020), Firefox 95 (Dec 2021), Safari 12.1 (Mar 2019), and Safari iOS 12.2 (Mar 2019).
+
+Autofill is a progressive enhancement. In browsers that do not support autofill, users will simply need to manually enter their sign-in credentials. The semantic HTML constraints (such as `type`, `inputmode`, and `required`) will still function appropriately to validate user input and provide the correct virtual keyboards.

package/.agents/skills/modern-web-guidance/guides/forms/autofill-sign-up-form.md

@@ -0,0 +1,145 @@
+# Build a sign-up form that follows best practice
+
+Use cross-platform browser features to build sign-up forms that are secure, accessible and easy to use.
+
+If users ever need to sign up to your site, then good sign-up form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designed sign-up forms get high bounce rates. Each bounce could mean a lost customer and a disgruntled user—not just a missed sign-up opportunity.
+
+## How to implement
+
+Outlined below are the most important guidelines for building successful sign-up forms.
+
+### Use meaningful, valid HTML
+
+Make the most of the elements and attributes built for creating forms:
+
+-   `<form>`, `<input>`, `<label>`, and `<button>`
+-   `type`, `autocomplete`, and `inputmode`
+
+These enable built-in browser functionality, improve accessibility, and add meaning to markup.
+
+### Use the `<label>` element to label form fields for data entry
+
+To label an `<input>`, `<select>`, or `<textarea>`, use a `<label>`. Associate a label with an input by giving the label's `for` attribute the same value as the input's `id`.
+
+### Make the most of HTML attributes
+
+Make it easy for users to enter data, by using the appropriate `<input>` element `<type>` attribute to provide the right keyboard on mobile and enable basic built-in validation by the browser.
+
+Always use `type="email"` for email addresses and `type="tel"` for phone numbers.
+
+Every `<input>`, `<select>`, and `<textarea>` element SHOULD have an appropriate `autocomplete` attribute, to improve accessibility and help users avoid re-entering data.
+
+### Make buttons helpful
+
+Use `<button>` for buttons. You can also use `<input type="submit">`, but don't use a `div` or some other random element acting as a button. Button elements provide accessible behaviour, built-in form submission functionality, and can easily be styled.
+
+Give each form submit button a value that says what it does. Use a clear, recognizable label. For example, use **Create account** or **Sign up** rather than **Continue** or **Submit**.
+
+### Use a single name input where possible
+
+Allow your users to enter their name using a single input, unless you have a good reason for separately storing given names, family names, honorifics, or other name parts. Using a single name input makes forms less complex, enables cut-and-paste, and makes autofill simpler.
+
+Allow international names. For validation, avoid using regular expressions that only match Latin characters. Latin-only excludes users with names or addresses that include characters that aren't in the Latin alphabet. Allow Unicode letter matching instead—and ensure your backend supports Unicode securely as both input and output. Unicode in regular expressions is well supported by modern browsers.
+
+### Show sign-up progress
+
+For each step towards sign-up, use page headings and descriptive button values that make it clear what needs to be done now, and what the next step is.
+
+Use the `enterkeyhint` attribute on form inputs to set the mobile keyboard enter key label. For example, use `enterkeyhint="previous"` and `enterkeyhint="next"` within a multi-page form, `enterkeyhint="done"` for the final input in the form, and `enterkeyhint="search"` for a search input.
+
+### Help users avoid re-entering sign-up data
+
+Make sure to add appropriate `autocomplete` values in sign-up forms.
+
+This enables browsers to help users by securely storing sign-up details and correctly entering form data. Without autocomplete, users may be more likely to keep a physical record of sign-up details, or store sign-up data insecurely on their device.
+
+### Validate carefully
+
+Validate data entry both in realtime and before form submission. Use `type="email"` for email inputs — the browser will validate the format automatically. For passwords, use a `pattern` attribute to enforce strength requirements and provide clear error messages when validation fails. Add the `required` attribute to mandatory fields to prevent empty submissions.
+
+### Put sign-up in its own `<form>` element
+
+Always use the `<form>` element when you're getting users to enter data
+
+Don't wrap inputs in a `<div>` and handle input data submission purely with JavaScript. It's generally better to use a `<form>` element. This makes your site accessible to screenreaders and other assistive devices, enables a range of built-in browser features, makes it simpler to build basic functional sign-up for older browsers, and can still work even if JavaScript fails.
+
+### Don't double up inputs
+
+Some sites force users to enter emails or passwords twice. That might reduce errors for a few users, but causes extra work for all users, and increases abandonment rates. Asking twice also makes no sense where browsers autofill email addresses or suggest strong passwords. It's better to enable users to confirm their email address (you'll need to do that anyway) and make it easy for them to reset their password if necessary.
+
+### Keep passwords private—but enable users to see them if they want
+
+Passwords inputs should have `type="password"` to hide password text and help the browser understand that the input is for passwords. (Note that browsers use a variety of techniques to understand input roles and decide whether or not to offer to save passwords.)
+
+You should add a **Show password** toggle to enable users to check the text they've entered—and don't forget to add a **Forgot password** link.
+
+### Give mobile users the right keyboard
+
+Use `<input type="email">` to give mobile users an appropriate keyboard and enable basic built-in email address validation by the browser… no JavaScript required!
+
+If you need to use a telephone number instead of an email address, `<input type="tel">` enables a telephone keypad on mobile. You can also use the `inputmode` attribute where necessary: `inputmode="numeric"` is ideal for PIN numbers.
+
+### Prevent mobile keyboard from obstructing the Sign up button
+
+If you're not careful, mobile keyboards may cover your form or, worse, partially obstruct the Sign up button. Users may give up before realizing what has happened.
+
+Where possible, avoid this by displaying only the email (or phone) and password inputs and Sign up button at the top of your sign-up page. Put other content underneath.
+
+### Help users to avoid re-entering data
+
+You can help browsers store data correctly and autofill inputs, so users don't have to remember to enter email and password values. This is particularly important on mobile, and crucial for email inputs, which get high abandonment rates. There are two parts to this:
+
+1.  The `autocomplete`, `name`, `id`, and `type` attributes help browsers understand the role of inputs in order to store data that can later be used for autofill. To allow data to be stored for autofill, modern browsers also require inputs to have a stable `name` or `id` value (not randomly generated on each page load or site deployment), and to be in a `<form>` element with a `submit` button.
+1.  The `autocomplete` attribute helps browsers correctly autofill inputs using stored data.
+
+For email inputs use `autocomplete="username"`, since `username` is recognized by password managers in modern browsers—even though you should use `type="email"` and you may want to use `id="email"` and `name="email"`. For password inputs, use the appropriate `autocomplete` and `id` values to help browsers differentiate between new and current passwords.
+
+### Use autocomplete="new-password" and id="new-password" for a new password
+
+MANDATORY: For a sign-up form, use `autocomplete="new-password"`.
+
+```html
+<!-- new-password prevents password managers from auto-filling an existing password into this field -->
+<input type="password" id="new-password" name="new-password" autocomplete="new-password" required>
+```
+
+### Enable the browser to suggest a strong password
+
+Modern browsers use heuristics to decide when to show the password manager UI and suggest a strong password.
+
+Built-in browser password generators mean users and developers don't need to work out what a "strong password" is. Since browsers can securely store passwords and autofill them as necessary, there's no need for users to remember or enter passwords. Encouraging users to take advantage of built-in browser password generators also means they're more likely to use a unique, strong password on your site, and less likely to reuse a password that could be compromised elsewhere.
+
+### Help save users from accidentally missing inputs
+
+Add the `required` attribute to both email and password fields. Modern browsers automatically prompt and set focus for missing data.
+
+### Allow password pasting
+
+Some sites don't allow text to be pasted into password inputs.
+
+Disallowing password pasting annoys users, encourages passwords that are memorable (and therefore may be easier to compromise) and, according to organizations such as the UK National Cyber Security Centre, may actually reduce security. Users only become aware that pasting is disallowed after they try to paste their password, so disallowing password pasting doesn't avoid clipboard vulnerabilities.
+
+### Offer third-party login
+
+Many users prefer to sign in to websites using an email address and password sign-up form. However, you should also enable users to sign in using a third-party identity provider, also known as federated login.
+
+This approach has several advantages. For users who create an account using federated login, you don't need to ask for, communicate, or store passwords.
+
+You may also be able to access additional verified profile information from federated login, such as an email address—which means the user doesn't have to enter that data and you don't need to do the verification yourself. Federated login can also make it much easier for users when they get a new device.
+
+### Take care with usernames
+
+Don't insist on a username unless (or until) you need one. Enable users to sign up and sign in with only an email address (or telephone number) and password—or federated login if they prefer. Don't force them to choose and remember a username.
+
+If your site does require usernames, don't impose unreasonable rules on them, and don't stop users from updating their username. On your backend you should generate a unique ID for every user account, not an identifier based on personal data such as username.
+
+Also make sure to use `autocomplete="username"` for usernames.
+
+### Fallback strategies
+
+Baseline status for Email, telephone, and URL <input> types: Widely available. It's been Baseline since 2015-07-29.
+Supported by: Chrome 5 (May 2010), Edge 12 (Jul 2015), Firefox 4 (Mar 2011), Safari 5 (Jun 2010), and Safari iOS 3 (Jun 2009).
+Baseline status for inputmode: Widely available. It's been Baseline since 2021-12-07.
+Supported by: Chrome 66 (Apr 2018), Edge 79 (Jan 2020), Firefox 95 (Dec 2021), Safari 12.1 (Mar 2019), and Safari iOS 12.2 (Mar 2019).
+
+Autofill is a progressive enhancement. In browsers that do not support autofill, users will simply need to manually enter their sign-up credentials. The semantic HTML constraints (such as `type`, `inputmode`, and `required`) will still function appropriately to validate user input and provide the correct virtual keyboards.