:enabled/:disabled pseudo classes should not match inputs of type "hidden"

ASSIGNED
Assigned to

Status

()

Core
CSS Parsing and Computation
ASSIGNED
10 years ago
8 years ago

People

(Reporter: rflint, Assigned: rflint)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Patch and tests coming up shortly.
Why? Because of the text here?
http://www.w3.org/TR/css3-selectors/#UIstates
Created attachment 295176 [details] [diff] [review]
Patch

(In reply to comment #1)
> Why? Because of the text here?
> http://www.w3.org/TR/css3-selectors/#UIstates
> 
Yep, exactly.
Attachment #295176 - Flags: superreview?(bzbarsky)
Attachment #295176 - Flags: review?(bzbarsky)
Comment on attachment 295176 [details] [diff] [review]
Patch

This isn't the place to fix it.  It just slows down this code, and that patch is wrong anyway (e.g. I don't see you checking anywhere that you're working with an HTML <input>).  The right place to fix this is in the relevant IntrinsicState() implementation.
Attachment #295176 - Flags: superreview?(bzbarsky)
Attachment #295176 - Flags: superreview-
Attachment #295176 - Flags: review?(bzbarsky)
Attachment #295176 - Flags: review-
I should also note that the definition cited in comment 1 is somewhat silly.  For example, you can't tell whether you can "either activate it or transfer the focus to it" until _after_ you have resolved style.  Consider:

  input[type="text"] { display: none; }

Now inputs can't be focused or activated.  That can't stop them from matching :enabled/:disabled, of course.

So it might be worth raising the question of whether hidden inputs should match these selectors in .layout or possibly www-style@w3.org.
Created attachment 295191 [details] [diff] [review]
Patch v2

I agree the wording's a bit odd. Seems the intent is to have these selectors apply to any control capable of accepting user input, be it currently rendered or not - excluding hidden inputs since they don't directly accept input and shouldn't really ever have a UI state.
I'll follow up with Hixie/www-style to clarify this though.
Attachment #295176 - Attachment is obsolete: true
Attachment #295191 - Flags: superreview?(bzbarsky)
Attachment #295191 - Flags: review?(bzbarsky)
Fwiw, if that's the intent, I don't think I agree with that.
<input type="hidden" disabled> prevents the corresponding name/value pair to get submitted, so a hidden input can be disabled.
It would mean that html disabled != css :disabled.
Comment on attachment 295191 [details] [diff] [review]
Patch v2

Much better, but this messes up dynamic type changes.  See the comment at <http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/content/src/nsGenericHTMLElement.cpp&rev=1.744&mark=2813-2814#2811>.  With this change, that comment becomes false.  You should be able to write a test that fails with this patch based on triggering that codepath....  Basically, have a rule like "input:enabled + div { color: green; }" and have a text input followed by a div, then change the input's type to hidden.  You could even make the text input display:none so the div is the only thing showing up before/after.
Attachment #295191 - Flags: superreview?(bzbarsky)
Attachment #295191 - Flags: superreview-
Attachment #295191 - Flags: review?(bzbarsky)
Attachment #295191 - Flags: review-
I agree that this isn't well defined and will remove the check from the Acid3 test.

Updated

10 years ago
No longer blocks: 410460
Duplicate of this bug: 495217
You need to log in before you can comment on or make changes to this bug.