suppress the generation of the authenticity_token div

Sorry for 2 comments. Messed up the formatting.

Afaik a "wrapper" element is required for html validation.

The code being generated currently is not good though:

<div style="margin:0;padding:0;display:inline"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value=".............." /></div>

Reasons:

• Some people do not like tag-soup.
• Inline CSS is bad.
• Its hard to use display: none instead of display: inline.

Quick & Easy fix:

Generate: <div class="protect_from_forgery"><input name="utf8" type="hidden" value="&#x2713;" /><input name="authenticity_token" type="hidden" value=".............." /></div>

...and in scaffold.css

.protect_from_forgery { display: inline; margin: 0; padding: 0; }

The css class name could be different as it includes the utf-8 flag as well and thus is not "exactly" matching what it contains.

Better fix:

1. Add class="protect_from_forgery" or something similar to all 3 hidden input fields for browser backwards compatibility (IE, other browsers can access the hidden elements style by going by css selector [type="hidden"].
   
2. Prepend the the 3 hidden fields to
   
   • either: first generation of a rails3 input/textarea/select
   • or: the first generation of a rails3 submit/button

I've made a patch with cake_joe's suggestion. I hope it can be integrated for Rails 3.0.2.

First of all, thanks.

Looking through your patch I notices this line:
tags = snowman_tag << method_tag

Snowman is not exactly the same like authenticity token => http://railssnowman.info/
So the class name is not perfect or rather in some cases its missleading. Thus CSS classname 'rails_snowman_and_authenticity_wrapper' or something /better/ would fit better ;-)

I changed the CSS classname as suggested by cake_joe to "snowman_and_authenticity_wrapper", which I think conveys the message. See the patch for suggestions and comments.

Added .diff file for compatibility reasons.

Thanks Jeff for reviewing the patch! I added your tip about checking for whitespace to the Rails Guides, so other developers can benefit from it.

@ Josh: +1 for the wrapper name 'standards_and_authenticity_wrapper'. Your idea works well for upgrading without hassles, though adds more extra/"bloat" code. Do you want to keep that forever or just have one deprecation "version" and then drop it. Is the extra code worth that? IMHO: worst if it stays like it currently in 3.1.

@cake_joe : I am not saying that the ticket doesn't have some merit, but there are lots of use cases not taken into account before this could be a cohesive change.

I think the first step is to add the form_tag variation so you can pass :standards_tag_class => 'auth_class' and have the inline properties replaced by a class.

Then a Railtie addition can be set up so you can define it for all your forms.

As for a default for new apps, I am not sure about this as it requires people to either use scaffold.css or application.css, if they do not use these asset files then they won't know about the css class.

Thanks,

Josh

@Josh: The naming of the wrapper class is implementation specific. It shouldn't, so renaming it to "standards_and_authenticity_wrapper" is better. I furthermore look into a solution for a more flexibel class assigning.

Is it a good idea to make it a configuration setting, like this?:

config.standards_and_authenticity_wrapper.class = <name_of the_class>

So people can assign their own class name and add it to their own style to the stylesheet. If the config class isn't set it will just display the inline style, otherwise the class. What do you think?

@Lars, I would suggest you take Kozs advice on board and instead go down the custom form builder road. Maybe after this has been added we can look into the Railtie config possibility, but right now I do not think it has priority.

Create a patch, with tests, which allows for custom form builders to generate whatever markup users want, then we can go from there.

Thanks,

Josh

@Josh and @Michael, I'm going to work on the more generic solution, like Michael suggested; refactoring it to a custom form bulder so users can generate the markup they want. I will let you know when I have finished the patch.