Closed Bug 1264157 Opened 4 years ago Closed 4 years ago
:in-range & :out-of-range CSS pseudo-classes shouldn't match disabled or readonly inputs
Steps to reproduce: 1. Open the attached testcase webpage in Firefox. 2. Observe the colors of the outlines of the <input>s. What is the expected behavior? The outlines should be green, indicating that the disabled or readonly <input type=number>s did not match the :in-range or :out-of-range CSS pseudo-classes. What went wrong? The outlines are orange and red, indicating that the disabled or readonly <input type=number>s matched the :in-range or :out-of-range CSS pseudo-classes. ---- Based on my reading of the HTML spec, :in-range and :out-of-range should never apply to disabled or readonly <input>s. Per https://html.spec.whatwg.org/multipage/scripting.html#selector-in-range > The :in-range pseudo-class must match all elements that are **candidates for constraint validation**, have range limitations, and [...] > The :out-of-range pseudo-class must match all elements that are **candidates for constraint validation**, have range limitations, and [...] Per https://html.spec.whatwg.org/multipage/forms.html#candidate-for-constraint-validation > A submittable element is a **candidate for constraint validation** except when a condition has **barred the element from constraint validation**. Per https://html.spec.whatwg.org/multipage/forms.html#the-readonly-attribute:barred-from-constraint-validation > If the **readonly** attribute is specified on an input element, the element is **barred from constraint validation**. Per https://html.spec.whatwg.org/multipage/forms.html#enabling-and-disabling-form-controls:-the-disabled-attribute:barred-from-constraint-validation > If an element is **disabled**, it is **barred from constraint validation**. Thus, disabled and readonly <input>s are barred from constraint validation, meaning they are not candidates for constraint validation, thus causing them to be disqualified by the 1st of the 3 conditions which are required for an element to match :in-range or :out-of-range.
See Also: → https://bugs.webkit.org/show_bug.cgi?id=156530
This has now been fixed in both WebKit and Chrome. See the respective bug links in the "See Also" field.
Whiteboard: [parity-chrome] → [parity-chrome][parity-webkit][parity-safari]
Here's a patch with a successful try-run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=051bc37b198a&selectedJob=23605802 Note that until the time, week, and datetimelocal elements also correctly support range constraints, the web platform test will continue to fail. As such I added a mochitest in the patch just for this bug, which can be removed when the time comes.
Assignee: nobody → wisniewskit
Status: NEW → ASSIGNED
Attachment #8769503 - Flags: review?(bzbarsky)
Comment on attachment 8769503 [details] [diff] [review] 1264157-do_not_match_disabled_or_readonly_inputs_with_in-range_or_out-of-range.diff r=me Can you check this in yourself, or do you need someone to check it in for you?
Attachment #8769503 - Flags: review?(bzbarsky) → review+
No, I can set checkin-needed, but I don't have actual commit privileges yet.
OK. Let's set that, and if the sheriffs haven't gotten to this by tomorrow I'll get it landed. Thank you for the patch!
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/cee7b4d83f04 Do not match disabled/readonly inputs with :in-range and :out-of-range. r=bz
I've added a compatibility note for this to https://developer.mozilla.org/en-US/docs/Web/CSS/:in-range#Browser_compatibility. Sebastian
I think this is worth a mention in Firefox 50 for devs too.
(In reply to Jean-Yves Perrier [:teoli] from comment #9) > I think this is worth a mention in Firefox 50 for devs too. Added. Sebastian
You need to log in before you can comment on or make changes to this bug.