Open
Bug 410472
Opened 17 years ago
Updated 2 years ago
:enabled/:disabled pseudo classes should not match inputs of type "hidden"
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
NEW
People
(Reporter: rflint, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
2.48 KB,
patch
|
bzbarsky
:
review-
bzbarsky
:
superreview-
|
Details | Diff | Splinter Review |
Patch and tests coming up shortly.
Comment 1•17 years ago
|
||
Why? Because of the text here? http://www.w3.org/TR/css3-selectors/#UIstates
Reporter | ||
Comment 2•17 years ago
|
||
(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 3•17 years ago
|
||
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-
Comment 4•17 years ago
|
||
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.
Reporter | ||
Comment 5•17 years ago
|
||
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)
Comment 6•17 years ago
|
||
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 7•17 years ago
|
||
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-
Comment 8•17 years ago
|
||
I agree that this isn't well defined and will remove the check from the Acid3 test.
Updated•4 years ago
|
Assignee: rflint → nobody
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•