Skip to content
This repository has been archived by the owner. It is now read-only.

Proposing to replace default invalid state for form elements by indeterminate #1073

Closed
notabene opened this issue Nov 8, 2017 · 6 comments
Closed

Comments

@notabene
Copy link
Member

@notabene notabene commented Nov 8, 2017

Hi all,

(Please forgive me in advance if some terms are approximate, and feel free to correct me if needed for more relevant naming of states, pseudo-states, pseudo-selectors etc.; I won't be offended the least.)

We (@notabene and @Lausselloic) have a problem with the browser validation occurring on form elements: by default, if a field is required, its :invalid pseudo-state is triggered as soon as the page is loaded.

The problem we have is that if we style elements based on the :invalid pseudo-selector, fields are shown as invalid even though a user has not yet had the chance to interact with it.

If I read correctly, the spec in its current state for required does not specify that a field is invalid as of page load. It just says that it is boolean, either true or false. Understandably it's false by default since it's required but was not filled (or checked if it's radio checkboxes). We think that a third indeterminate state should be added, and the browser should, for instance, consider the field as invalid only when one tabs/clicks out of it (AKA when the blur event is triggered) or when one submits the form.

This way a field would not default to being invalid as long as one has not yet interacted with it or its containing form.

By the way, we have the same problem, although a bit less prominent, with patterns: if a field requires a pattern, its :invalid pseudo-state is triggered as soon as the first character is typed. Could the following option be considered: when field is blurred, compare the field value to the pattern and only then trigger its :invalid state.

@notabene
Copy link
Member Author

@notabene notabene commented Nov 8, 2017

(Also EDITORS, feel free to edit this issue's title if it's too long to your taste) 😉 [wink emoji]

@emmanuelclement
Copy link

@emmanuelclement emmanuelclement commented Nov 8, 2017

Same here.

@ffoodd
Copy link

@ffoodd ffoodd commented Nov 9, 2017

FWIW, :indeterminate pseudo-class already exists for checkboxes, radios and progress (latest
HTML5 W3C recommendation
).

@notabene
Copy link
Member Author

@notabene notabene commented Nov 29, 2017

Also, it seems that the problem has been identified too in the CSS Selector Level 4 draft:

The :user-invalid pseudo-class represents an element with incorrect input, but only after the user has significantly interacted with it.

@chaals chaals added this to the When it's ready milestone Dec 17, 2017
@ffoodd
Copy link

@ffoodd ffoodd commented Dec 20, 2017

FWIW, if your input has a placeholder you might deal with the issue by using :placeholder-shown.

If placeholder is shown, then input hasn't been focused. However it require to use a placeholder (but as far as I tested this, it works even if placeholder is empty).

CodePen it or it didn't happen

@siusin
Copy link
Contributor

@siusin siusin commented Jul 29, 2019

Thanks @notabene .

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.

If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.

If you have questions about this, please open an issue on the W3C HTML WG repository or send an email to public-html@w3.org.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants