Switched to use `display:none` in extra_tags_for_form method. #6608

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
Contributor

gaelian commented Jun 3, 2012

The use of display:inline with the content_tag call in the
extra_tags_for_form method potentially causes display issues with some
browsers, namely Internet Explorer. IE's behaviour of not collapsing
the line height on divs with ostensibly no content means that the
automatically added div containing the hidden authenticity_token, utf8
and _method form input tags may interfere with other visible form
elements in certain circumstances. The use of display:none rather
than display:inline fixes this problem.

Closes #6403.

@gaelian gaelian Switched to use `display:none` in extra_tags_for_form method.
The use of `display:inline` with the content_tag call in the
extra_tags_for_form method potentially causes display issues with some
browsers, namely Internet Explorer. IE's behaviour of not collapsing
the line height on divs with ostensibly no content means that the
automatically added div containing the hidden authenticity_token, utf8
and _method form input tags may interfere with other visible form
elements in certain circumstances. The use of `display:none` rather
than `display:inline` fixes this problem.

Closes #6403.
d5f6fdb
Owner

spastorino commented Jun 3, 2012

/cc @jeremy

Member

drogus commented Jun 3, 2012

I like that, but we need to know which browsers (if any) stop sending those hidden fields if they're inside display: none element.

Contributor

gaelian commented Jun 3, 2012

@drogus, this point was discussed in issue #6403 where @pixeltrix mentioned that failure to send the hidden fields due to display:none being set on the containing div was only a historical problem now. Perhaps he can shed some definite light on this matter.

Member

drogus commented Jun 4, 2012

@Gaellan I missed that, thanks for clarification. If it's the case, I'm fine with merging it.

Contributor

gaelian commented Jun 4, 2012

@drogus cool. No worries.

Any word on this? I'd like the functionality

Owner

rafaelfranca commented Jul 28, 2012

Some browsers still doesn't send the data inside display:none elements. We need to investigate better.

Contributor

gaelian commented Jul 31, 2012

@rafaelfranca which browsers are the ones suspected to still be causing trouble?

Owner

rafaelfranca commented Jul 31, 2012

Firefox 12

Contributor

gaelian commented Jul 31, 2012

I see. And later versions of FF do not exhibit the same behaviour?

Owner

rafaelfranca commented Jul 31, 2012

I don't know. We need to investigate. I tried in the same version to reproduce but without success.

Owner

pixeltrix commented Jul 31, 2012

@rafaelfranca who reported the FF12 failure? There are some issues regarding invalid HTML5 form elements that are hidden:

https://bugzilla.mozilla.org/show_bug.cgi?id=595451
https://bugzilla.mozilla.org/show_bug.cgi?id=693025
https://bugzilla.mozilla.org/show_bug.cgi?id=724537

I wonder if this was the cause of their failure?

Owner

rafaelfranca commented Jul 31, 2012

One guy at the Brazilian ruby on rails mailing list (I hope the google portuguese-english translation can help). In that case he was using radio buttons.

Owner

pixeltrix commented Jul 31, 2012

Sounds like the category_id field is a belongs_to association and if it's set to :null => false in schema.rb Formtastic will mark it as required - so it could fall into the being the bug described above.

Owner

rafaelfranca commented Jul 31, 2012

Yes, make sense.

Member

schneems commented Nov 5, 2012

Any update on this?

mhuggins commented Nov 7, 2012

Sorry if this is a dumb question, but I've always wondered why Rails does this:

<div style="margin:0;padding:0;display:none">
  <input name="authenticity_token" type="hidden" value="NrOp5bsjoLRuK8IW5+dQEYjKGUJDe7TQoZVvq95Wteg=" />
</div>

Instead of this:

<input name="authenticity_token" type="hidden" value="NrOp5bsjoLRuK8IW5+dQEYjKGUJDe7TQoZVvq95Wteg=" />

In other words, why even wrap hidden inputs inside a div in the first place?

@mhuggins it's "kinda similar" to what @pixeltrix explained here: #6403 (comment). For historical reasons, it's due to some browser weirdness and rendering quirks with hidden inputs.

Member

steveklabnik commented Dec 15, 2012

So, did we ever come to any consensus, @pixeltrix @rafaelfranca ?

Contributor

eval commented Mar 21, 2013

Triage fairy: any update on this?

Contributor

al2o3cr commented Mar 21, 2013

@mhuggins - late to the discussion, but the biggest reason the input tags are wrapped in a block-level element is that the old HTML 4.01 Strict doctype required that wrapping - bare input tags inside a form were not valid.

Owner

pixeltrix commented Jan 5, 2014

Closed by 7a085da

@gaelian thanks for your contribution!

pixeltrix closed this Jan 5, 2014

jumski commented Feb 18, 2014

Guys I'm struggling how to get following form to display properly:

.row
  = form_for @form, url: admin_copies_path do |f|
    .span6
      = render 'some/partial/with/fields'
    .span6
      = render 'some/other/partial/with/fields'

I'm using bootstrap 2 and it cant handle any additional element before my span6's - what I see is columns displaying vertically instead of horizontally.

Any ideas how to elegantly move this additional fields to the end of the form?

Thanks in advance!

Owner

pixeltrix commented Feb 18, 2014

@jumski try putting the form around the row - is bootstrap using :first or an adjacent selector?

jumski commented Feb 18, 2014

@pixeltrix wow didn't expected so fast response :)

after fiddling with reopening FormTagHelper and overriding form methods I had an aha moment and tried exacly what you proposed.

Guest what - problem solved!

Thanks a lot for you support!

@chancancode chancancode referenced this pull request Sep 9, 2014

@gaelian @pixeltrix gaelian + pixeltrix Switched to use `display:none` in extra_tags_for_form method.
The use of `display:inline` with the content_tag call in the
extra_tags_for_form method potentially causes display issues with some
browsers, namely Internet Explorer. IE's behaviour of not collapsing
the line height on divs with ostensibly no content means that the
automatically added div containing the hidden authenticity_token, utf8
and _method form input tags may interfere with other visible form
elements in certain circumstances. The use of `display:none` rather
than `display:inline` Fixes this problem.

Fixes #6403
7a085da
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment