Skip to content

:wrapper_html => false #712

Closed
ryanisinallofus opened this Issue Oct 6, 2011 · 12 comments

4 participants

@ryanisinallofus

The forced li is nice, as is the associated coding forms talk but there are times where you just NEED to not have any wrapper html. It would be really cool if we could just set it to false.

@justinfrench
Owner

Can you give me an example where this is the case... where you need to implement your own wrapper, or to not have one at all?

@gucki
gucki commented Oct 10, 2011

@justinfrench I think a nice example would be when you want to place two inputs inside one wrapper.
Just like most forms have for ex. City: zipcode city. Or can this easily be done somehow different with formtastic 2.0? :)

@justinfrench
Owner

@gucki

I have a few answers to that:

  1. Studies show that those side-by-side inputs (as opposed to a nice uniform series of labels and widgets) actually perform way worse in user testing. This may sound like weak "change the design to suit the tool" answer, but it's really true, utterly pragmatic, doesn't require any more code, and explains why I haven't been motivated to solve it.

  2. I'd argue strongly that zip code and city both need their own wrapper — the wrapper is there to semantically contain the grouping of label, widget, hints and errors (plus relevant classes like required). If there were errors on the zip code, where would you render them? If find that these kinds of requests are a little half-baked when it comes to the details. Instead, keep the wrappers and position/style them differently with CSS. Group them together in a field set if needed.

  3. There's some allowances in the CSS for inputs that have multiple fragments (the date-time ones being obvious). While I haven't done one myself, I imagine that you could craft an :as => :zip code_and_city input that takes advantage of all this stuff. It's on my list of shit to experiment with, would be happy for someone to sponsor it up to the top of my weekend todo list :)

  4. Custom Inputs can do anything, but I think once you get into the details for this kind of case, you'll wish you hadn't.

@ryanisinallofus

"Studies show that those side-by-side inputs (as opposed to a nice uniform series of labels and widgets) actually perform way worse in user testing."

You are operating on outdated info there, or you aren't thinking of specific cases where it makes sense. Like with an expiration date? Credit card numbers and security codes? For too general of an accusation to make.

Either way it seems like :wrapper_html => false is a logical feature but we basically went with your #2 response before reading this.

Thanks for the response.

@ryanisinallofus

Oh yeah, as for the specific example: an invoice creator where you display the form elements for hours and price in a table because it makes sense to. You can't place LIs in TDs.

@ryanisinallofus

Sorry I didn't mean to close this. @justinfrench can close it if he wants to.

@gucki, I think if you want more control over the HTML you might want to try simple_form.

http://blog.plataformatec.com.br/tag/simple_form/

@justinfrench
Owner

@ryanisinallofus there's always cases where side-by-side will work better than a stacked form. I was generalising, but doing so as someone who does lots of user testing around forms. I don't think the case originally stated by @gucki (city, zip code) would benefit from side-by-side fields. When you introduce proper labelling and error messages, I don't think the expiration date and credit card number examples hold up either (another vote for #2 above).

However, in ANY case where Formtastic is not appropriate, I recommend using regular Rails form helpers for the relevant parts of the form (they can be mixed and matched inside the Formtastic DSL). This is what I do myself, and what I recommend. Formtastic is here to help me (and you) when it can, and intentionally stays out of the way when it can't.

In the cases we're talking about above, all I'm hearing is some text fields and maybe some non-standard labelling. Rails has stuff for this out of the box. I'm yet to be convinced we need this feature in the DSL, but still open minded and listening. Closing for now, feel free to re-open.

@gucki
gucki commented Oct 14, 2011

@justinfrench Even when I try to tell them to do it differently, at the end you have to do what customers want. In my case this was the case with the zip/ city stuff, I also had the same issue one for credit card expiry as mentioned by @ryanisinallofus.

I know I can use custom inputs (I did one to make checkbox fields look like any other input), but it seems overkill for this requirement here. I also didn't find a generic way to solve it using css (anyone knows one?).

What about making form.input accept a block? The contents should be put inside the wrapper and that's it.

@justinfrench
Owner

@gucki I understand your position with the client, but don't necessarily agree. I'll try to blog something about the CSS-only solution soon.

In regards to the "accept a block" thing... what does that really buy you? An

  • tag. You can't automatically put a class on it for the input type (it's essentially custom). You can't put an errors or required class on it because it's impossible to know what attributes are inside it. It can't be for an attribute. All you're left with is an
  • tag wrapper. These are effectively the same:

    <%= f.input :wrapper_html => { :class => "foo bah" } do %>
      ...
    <% end %>
    
    <%= content_tag :li, :class => "input foo bah" do %>
      ...
    <% end %>
    

    Maybe I'm missing something?

  • @libryder

    I had to stop using formtastic on one of my forms because <li>'s can't exist outside of one of their parent elements (<ul>, <ol>, etc). It's not valid HTML.

    @justinfrench
    Owner

    @libryder

    1. they can exist outside: "If its parent element is an ol, ul, or menu element, then the element is an item of the parent element's list, as defined for those elements. Otherwise, the list item has no defined list-related relationship to any other li element."

    2. What are you doing that requires it to be outside?

    @libryder

    Thanks for the reply.. I mean for valid HTML, you can't have <li>'s floating around in space. My solution was to wrap the input element in a <ul>. A super simple solution that I for some reason overlooked. I'm back to formtastic now. :)

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Something went wrong with that request. Please try again.