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

RESOLVED INVALID

Status

()

RESOLVED INVALID
14 years ago
14 years ago

People

(Reporter: og, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 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

14 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

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

Comment 3

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

Comment 4

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

Comment 5

14 years ago
Created attachment 178512 [details]
Short html file to verify the Topic
(Reporter)

Comment 6

14 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
Browsers.

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

greets
Olaf

Updated

14 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

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

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
Confirming
CCing myself

Status: UNCONFIRMED → NEW
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.