bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Styling the root element (input{}) causes that these definitions applies even to hidden input fields




Layout: Form Controls
13 years ago
13 years ago


(Reporter: Olaf Gleba, Unassigned)




Firefox Tracking Flags

(Not tracked)




(1 attachment)



13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041201 Camino/0.8.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041201 Camino/0.8.2

If you try to define ex. 'border: 1px solid red;' to the root HTML element
(input {}), all of the definitions will also apply to hidden Fields. In this
example it causes a red border around the hidden input.

In Fact, the hidden Field becomes visible ;)

Reproducible: Always

Steps to Reproduce:
1. define root element (-> input {attr})
2. produce a hidden element in the html
3. viola, hidden field becomes visible

Comment 1

13 years ago
err. are you complaining about firefox or camino? if you're experiencing this
problem in camino, then you shouldn't file your bug in the firefox product.
please attach a testcase or testcases demonstrating your problem. the closest
thing i could come up with based on your description does not have the behavior
you describe (w32 2005032005).

Comment 2

13 years ago
That testcases (in URL) has 2 INPUT elements in it, only one is styled which
seems to be correct.

Comment 3

13 years ago
WFM, Camino 2005031508. Try a nightly build.

Comment 4

13 years ago
WFM and I'm not even using nightly (Fx 1.0.2 and Moz 1.8b2)

Comment 5

13 years ago
Created attachment 178512 [details]
Short html file to verify the Topic

Comment 6

13 years ago
Added a simple testcase.

This behaviour is related to every (!) gecko Browser on any plattform.
Alle other Browsers that i can test with (Opera 6-7 X/Win, any IE X/Win, Safari)
seems to handle this differently than Geckos.

Maybe it is not really a gecko bug, but more a feature request to handle this
like the others. Because i can`t verify till now which Browser`s behave is
against the standards.

Again a short description (and slight correction of my intial post): At first
sight it is clear to me, that a definition on the root input effects every input
element. But since it makes definitly no sense to style a hidden input, all
others than geckos seems to ignore all style definitions on type hidden.

As long as i do not define display attributes (block, inline) on the root input,
everythings o.k (try to delete the display: block; attr. in testcase) and no
attr. is applied to the hidden input.

But sometimes i have to declare display attr. to it (depending on the layout
enviroment). And this causes the trouble. 

IMHO it would be nice, if the Geckos would treat the hidden type input as they
are,- hidden in every case. And do not apply any styles on it. Like the other

For me this gives me the opportunity to avoid redundant style definitions (by
assign a class to every input in the html).



13 years ago
Assignee: bugs → nobody
Component: Form Manager → Layout: Form Controls
Product: Firefox → Core
QA Contact: form-manager → layout.form-controls
Version: unspecified → Trunk

Comment 7

13 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050325

I can confirm this on latest-trunk running WindowsXP Pro SP1 Build 2600.
Cleaning some things up on this and confirming.

Adding testcase keyword
Fixing the Hardware and OS to All
CCing myself

Ever confirmed: true
Keywords: testcase
OS: MacOS X → All
Hardware: Macintosh → All
Hidden inputs just have "display: none" in the UA stylesheet.  But you're
explicitly overriding this in your styles.

We _could_ make hidden inputs always be display:none no matter what the page
style says.  But that just takes away the page author's choice for how they
should be rendered.

Marking invalid, since the behavior is what we want it to be.
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.