Some may feel that something like "text_field_tag 'email', nil, :type
=> 'email'" is good enough, but this doesn't work for "text_field"
because any "type" option is overridden to "text" (this could be fixed
with a smaller patch).
I do think, though, that providing helper methods like
"email_field_tag" will encourage wider adoption of HTML5, and that's a
good thing for everyone.
I suggest making this smaller patch, since it fixes a bug that prevents people from specifying arbitrary types for form inputs. Next, I would make a patch that adds method_missing to form builder and allows things like anything_field, which creates an input with type=“anything”. This is might be a good future-proof solution until the HTML5 spec is finalized—what do the others think?
If in the future there's a new input type people using old versions
could define their own helper as a last resort. I don't think this use
case deserves a solution with method_missing. Prefer explicit methods
here.
I mean, if we expected dozens of new input types it could be worth it
perhaps, but...
I suggest making this smaller patch, since it fixes a bug that prevents
people from specifying arbitrary types for form inputs.
I've attached this additional patch to the ticket, though I still
believe that the only way to encourage people to use the new spec is
to provide them with more explicit helpers.
Next, I would make a
patch that adds method_missing to form builder and allows things like
`anything_field`, which creates an input with type="anything". This is might
be a good future-proof solution until the HTML5 spec is finalized—what do
the others think?
These HTML5 input types have been in the spec since at least the
beginning of 2008, and like the others, I'd rather not use
method_missing here.
Next, I would make a
patch that adds method_missing to form builder and allows things like
`anything_field`, which creates an input with type="anything". This is might
be a good future-proof solution until the HTML5 spec is finalized—what do
the others think?
Additionally (and something I probably should have itemized), these
aren't all blind helper methods. Both number_field_tag and
range_field_tag have :min and :max attributes that can be set using a
range and :in (to match the syntax of other Rails helpers).
I've +1'ed the smaller options["type"] ||= field_type patch for now
but I'd like to see this go farther in some way.
Look at how the spec (HTML Standard) divides inputs by
"states of the type attribute". One extreme solution for Rails would
be an input_field with a ton of options. The other extreme is a helper
for each state.
Right now, there's not much difference between text fields and
telephone, search, and email fields. The date pickers, numbers, and
ranges "feel" different:
So, a slightly more incremental change might be to introduce number
and range tags.
Simply having all of these helpers around, however, is great
encouragement for Rails developers and "Rails 3: HTML5 friendly" has a
nice marketing ring to it.
