Remove :-moz-ui-invalid default style sheet rules and its novalidate handling
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox88 | --- | fixed |
People
(Reporter: peter.yates, Assigned: emilio)
References
Details
(Keywords: dev-doc-complete)
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0
Steps to reproduce:
Create a page containing a form with a text input that has a pattern attribute and a submit input that has a formnovalidate attribute. Now enter some text that does not match the pattern and deselect the text input.
<form>
<input type="text" pattern="zomg">
<input type="submit" formnovalidate="formnovalidate">
</form>
Actual results:
The text input is outlined in red because the pattern isn't matched.
Expected results:
The text input should have no red outline because the form is set to not apply any validation.
When the form element has a novalidate attribute, the red outline doesn't appear.
It is my understanding based on the spec (https://www.w3.org/TR/html52/sec-forms.html#element-attrdef-submitbuttonelements-formnovalidate) that the two approaches should work in the same manner.
Comment 1•5 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
That is incorrect. The novalidate attribute bypasses validation during form submission only. This control matches :invalid in all browsers (add :invalid { background:red } to your style sheet to see). It seems that only Firefox gives a visual cue by default for invalid form controls at the moment though.
Comment 3•5 years ago
|
||
I discussed this with Emilio on IRC and some historical context for :-moz-ui-invalid can be found in bug 609017 and bug 610415. There's also a :user-invalid pseudo-class in Selectors that nobody implements.
Our tentative conclusion is to do the following:
- Remove the default style sheet rules as other browsers do not have these
- Remove the
novalidatespecial case as it's broken forformnovalidate.
In the future we might want to look into removing this feature altogether, but that is likely more work due to existing internal usage.
| Reporter | ||
Comment 4•5 years ago
|
||
Thank you for the response, the solution you proposed sounds sensible.
| Assignee | ||
Comment 5•5 years ago
|
||
Actually, it might be easier to just do the right thing and don't show the invalid UI if the form submission hasn't been validated...
| Assignee | ||
Comment 6•5 years ago
|
||
(we should probably check with other browsers still to see if they're interested in implementing the :user-valid / :user-invalid pseudo-classes anyhow)
| Assignee | ||
Comment 7•5 years ago
|
||
Err, no, I thought we only showed the invalid ui after submit, but we also show it before submit...
| Assignee | ||
Comment 8•5 years ago
|
||
There's no way to know whether the submission will actually be
validated, because formnovalidate on submit buttons is a thing (and even
if all the submit controls had formnovalidate, you could still submit
the form and validate it via form.submit()), so it seems better to make
these pseudo-classes not depend on this.
Updated•5 years ago
|
| Assignee | ||
Comment 9•5 years ago
|
||
Other browsers don't have this UI, and there's no way to know whether
the form will actually be validated, so it can cause false-positives.
Depends on D105968
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/16aa51f7d201
https://hg.mozilla.org/mozilla-central/rev/70d457e2ca37
Comment 12•5 years ago
|
||
Not really much to do on this one, docs-wise, except to add a rel note; see the discussion at https://github.com/mdn/content/issues/3454
Description
•