If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

INPUT TYPE="hidden" generates vertical space




Layout: Form Controls
16 years ago
16 years ago


(Reporter: Adam Hauner, Assigned: rods (gone))


Windows NT

Firefox Tracking Flags

(Not tracked)



(2 attachments)



16 years ago
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.5+) Gecko/20011112

Tag <INPUT TYPE="Hidden" NAME=""> isn't hidden, in page this tag generates some
vertical space. See attachement.

Comment 1

16 years ago
Created attachment 57574 [details]
Testcase showing two nested DIVs and INPUT in 1st DIV
The issue here is that <input type="hidden"> is an inline element.  So the
markup given is laid out correctly by layout.

I would suggest switching from "visibility: hidden" to "display:none" for hidden
inputs now that elements with display:none submit correctly.

The usual XBL form control mantra probably applies.
Ever confirmed: true

Comment 3

16 years ago
What is the usual XBL form control mantra?
"This will be fixed when we go to XBL form controls"  :)

Comment 5

16 years ago
Also happens under Linux

Comment 6

16 years ago
Oh, oh, "rewrite it in XBL."  Gotcha.  Seems like if there's any control that
will be easy to do, it's input type=hidden.  Is there any reason you can think
of that we could not do the frames in XBL one by one?

Comment 7

16 years ago
> The issue here is that <input type="hidden"> is an inline element.  So the
> markup given is laid out correctly by layout.

I'm sorry, Boris, but that what i've found for this case in HTML4.01 spec:
"Authors may create controls that are not rendered but whose values are
submitted with a form."
(http://www.w3.org/TR/html401/interact/forms.html#hidden-control). Note that
standard says that hiddens should not be rendered at all. All <input> elements
differ much from each other, so I think they cannot be treated in common way as
elements of certain kind (though even some of their properties may be similar).

Besides, even if we can accept a hidden as inline element why then element lie
this: <span style="height:0px"></span> doesn't create any vertical space though
it is definetely of an inline nature. I mean, if this can be more convinient
algorithmically why don't treat hidden as an inline element with default height
set to 0?

More than this, almost all the authors build their forms with hiddens not
counting to mention their appearance on the page.

Please, correct me if my arguments are not proved enough...

Comment 8

16 years ago
Everyone agrees it shouldn't take up space, don't worry :)
Ah.  Please don't put spin on what I said.  I said, "is an inline element" not
"should be an inline element".  The spec does not say what the display type of
<input type="hidden"> is.  Switching to display:none, which I recommend, if you
note, will have exactly the effect you want -- the element will not take any
space at all.

So your arguments are perfectly correct. The part that you got wrong is your
assumption that what I said disagrees with what you said.  It does not.

Comment 10

16 years ago
Great! Then another question... When approximately the XBL controls may be expected?

P.S. Workaround with "display:none" works well undoubtedly but we cannot update
all the Net such way :-)
XBL form controls.... likely in the 0.9.7 -- 0.9.9 timeframe.

The display:none thing has nothing to do with the net and is not a workaround. 
We would be setting this in Mozilla's useragent stylesheet (instead of
visibility:hidden, which is what we use now).  It could not be done in the past
because form controls with display:none would not submit, but that should no
longer be a problem once jkeiser is done moving things about.  jkeiser, does
<input type="hidden"> with display:none work correctly at this point?
Last time I checked.  Yeah, it sounds like a simple fix.
Created attachment 58260 [details] [diff] [review]
Patch to fix

Good to hear that display:none works peachy now.  :)
rod, jkeiser, would one of you two review this?
Keywords: patch, review
Comment on attachment 58260 [details] [diff] [review]
Patch to fix

I have tested and it submits the form
http://www.zbarsky.org:8000/~bzbarsky/test.html just fine.
Attachment #58260 - Flags: review+

Comment 16

16 years ago
Comment on attachment 58260 [details] [diff] [review]
Patch to fix

sr=attinasi | Since display:none causes us to avoid making a frame at all, is
the -moz-binding rule necessary? Also, do we want to make it !important just to
be safe (so an author / user sheet cannot make it visible)?
Attachment #58260 - Flags: superreview+
I can't figure out why the -moz-binding would stop being necessary if we have no
frame... so I would vote to leave it as-is for safety (unless someone knows for
a fact that it really is unnecessary then, in which case away it goes).

I'm divided on making the display !important.  It makes some sense, but there
are legitimate reasons I can think of (debugging purposes) to want to easily see
the controls...  I'm loath to make this !important unless it becomes a real

Marc, if you feel about it strongly we can make it !important, but I would
rather not.
checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 112126 has been marked as a duplicate of this bug. ***
*** Bug 111525 has been marked as a duplicate of this bug. ***
looks like checkin to bug 109847 fixes the vertical space I seen on input box.
opps.. wrong bug was going to add that comment to bug 102802.
*** Bug 112816 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
*** Bug 115413 has been marked as a duplicate of this bug. ***
*** Bug 116231 has been marked as a duplicate of this bug. ***

Comment 26

16 years ago
ok with 0.9.7
don't have enough magic to change state to VERIFIED


16 years ago
QA Contact: madhur → tpreston
You need to log in before you can comment on or make changes to this bug.