HTML5 form field helpers

173 views
Skip to first unread message

Stephen Celis

unread,
Jan 4, 2010, 9:31:12 AM1/4/10
to Ruby on Rails: Core
HTML5 is becoming more popular, and there's already some benefit in
using HTML5 in browsers that support it, like MobileSafari, Safari,
and Opera.

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:

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3646-html5-form-field-helpers-email_field_tag-etc

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

Mislav Marohnić

unread,
Jan 5, 2010, 6:26:15 AM1/5/10
to rubyonra...@googlegroups.com
On Mon, Jan 4, 2010 at 15:31, Stephen Celis <stephe...@gmail.com> wrote:

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 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?

Xavier Noria

unread,
Jan 5, 2010, 6:42:31 AM1/5/10
to rubyonra...@googlegroups.com

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...

Rodrigo Rosenfeld Rosas

unread,
Jan 5, 2010, 7:20:05 AM1/5/10
to rubyonra...@googlegroups.com
Mislav Marohnić escreveu:
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 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.

Rodrigo.

Stephen Celis

unread,
Jan 5, 2010, 9:39:53 AM1/5/10
to Ruby on Rails: Core
On Jan 5, 5:26 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:

> 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

Stephen Celis

unread,
Jan 5, 2010, 9:44:24 AM1/5/10
to Ruby on Rails: Core
On Jan 5, 5:26 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:

> 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

Dan Croak

unread,
Jan 5, 2010, 12:31:14 PM1/5/10
to rubyonra...@googlegroups.com
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 (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

Reply all
Reply to author
Forward
0 new messages