I've created a patch (with tests) that adds the following input tag
helpers:
- email_field_tag (and email_field)
- url_field_tag (etc.)
- telephone_field_tag (aliased to phone_field_tag)
- number_field_tag
- range_field_tag
- search_field_tag
The ticket/patch is available here:
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.
Stephen
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).
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 think method_missing is very danger in this situation. In case of a misspelled word, no exception would be raised when calling the code to generate the input.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?
> 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.
Stephen
> 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).
>> number_field_tag "quantity", nil, :in => 0..10
=> '<input name="quantity" id="quantity" type="number" min="0"
max="10" />
Stephen
Look at how the spec (http://www.w3.org/TR/html5/) 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:
http://diveintohtml5.org/forms.html
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.
> --
>
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>
--
Dan Croak
@Croaky