This project is archived and is in readonly mode.

#5825 ✓resolved
Stephen Celis

HTML5 Data Attributes

Reported by Stephen Celis | October 16th, 2010 @ 08:54 PM | in 3.x

Specifying HTML5 data attributes for tags could be more streamlined. Right now you would use string keys and repetition.

To create, for example, this:

<div class="user" data-location="{&quot;city&quot;:&quot;Chicago&quot;,&quot;state&quot;:&quot;Illinois&quot;}" data-name="Stephen" id="user_1">

You would do something like this:

div_for user, 'data-name' =>, 'data-location' => { city:, state: user.state }.to_json do
# ...

Here's a proposed simplification, using a single "data" node to define the attributes:

div_for user, data: { name:, location: { city:, state: user.state } } do
# ...

Seeing as data attributes are accessed primarily by JavaScript (with libraries like jQuery already interpreting embedded JSON objects), it makes sense to convert said objects to JSON automatically rather than create pseudo-nested attributes like "data-location-city" and "data-location-state".

Comments and changes to this ticket

  • Stephen Celis
  • Aditya Sanghi

    Aditya Sanghi October 16th, 2010 @ 10:12 PM

    • Importance changed from “” to “Low”

    Stephen, I assume you are actually sending a hash to div_for with :data as the key or an ACTUAL json object?

    I assume it's a pure ruby hash and your example above is wrong. Checking the patch now.

    Very exciting indeed. +1 for the idea of course.

  • Stephen Celis

    Stephen Celis October 16th, 2010 @ 10:16 PM

    Aditya, the example should be right but the syntax is Ruby 1.9. The 1.8.x equivalent:

    div_for user, :data => { :name =>, :location => { :city =>, :state => user.state } } do
    # ...
  • Aditya Sanghi

    Aditya Sanghi October 16th, 2010 @ 10:27 PM

    • Milestone set to 3.x
    • Assigned user set to “Xavier Noria”
    • Tag set to actionview, html5, patch, tag

    The patch applies cleanly.

    This needs some documentation related updates too (and perhaps a few more tests?).

    +1 for sure!

  • Stephen Celis

    Stephen Celis October 16th, 2010 @ 10:40 PM

    Thanks for taking a look!

    Happy to add documentation if the interest is there :)

  • Aditya Sanghi

    Aditya Sanghi October 17th, 2010 @ 09:12 AM

    • State changed from “new” to “open”
  • Xavier Noria

    Xavier Noria October 17th, 2010 @ 11:05 AM

    Stephen, excellent the idea is good. Let's work a bit on the patch.

    It would definitely need documentation. On one hand in the very method API of course. I think also that this idiom should be preferred, so existing examples would be rewritten as well. Would you please ack the tree for them?

    The call to h() could double-escape stuff, perhaps html_safe? could be checked?

    Also, assert_dom_equal would probably be better for the test.

    Would you like to work on these remarks?

  • Aditya Sanghi

    Aditya Sanghi October 17th, 2010 @ 11:26 AM


    Are you talking about moving all examples to the 1.9 supported format (the one similar to json)? Wouldnt that cause a bit of an uproar? I'll be happy to make the change to the documentation if its okay with Stephen.

  • Xavier Noria

    Xavier Noria October 17th, 2010 @ 11:34 AM

    I mean, ack for

    ack '^\s*#.*data-'

    and see whether the new idiom is better in some example (perhaps the answer is there are none worth changing, don't know). The idea is that examples should implicitly communicate the preferred way of doing things.

    BTW, h() checks html_safe? it could be the case that the check is not needed.

  • Xavier Noria

    Xavier Noria October 17th, 2010 @ 11:44 AM

    Ah, Aditya, regarding docs contribution.

    Any patch should have proper code, tests, and docs. Remember, the source of documentation is master. Doing a separate patch for docs would be like doing a separate patch for tests. I think it is better that there's a single patch, complete and round.

  • Aditya Sanghi

    Aditya Sanghi October 17th, 2010 @ 11:54 AM

    Xavier, i misunderstood your earlier comment as moving all (even unrelated to this particular change) examples to the 1.9 format.
    Yes I understand that a patch should include all relevant bits (code, docs, test) as one commit as far as possible.

    Having said that (and feel free to PM on github if the conversation is digressing), what is the policy per ruby 1.9 way of doing things in Rails examples and documentation. Are we actively updating documentation to show the 1.9 way or still making sure the documentation is backward compatible with 1.8?

  • Xavier Noria

    Xavier Noria October 17th, 2010 @ 12:01 PM

    Not really, policy is not to use 1.9 by now. Examples should run in the officially supported versions.

    When we drop 1.8 then example code should be updated to use what is considered to be best in 1.9.

  • Stephen Celis

    Stephen Celis October 17th, 2010 @ 01:36 PM

    I'll clean up the patch and add 1.8-formatted docs.

  • Stephen Celis

    Stephen Celis October 17th, 2010 @ 02:24 PM

    Here's an update to the patch with documentation and a couple changes:

    • Symbols will not be JSON-escaped (to avoid JavaScript ""strings"").
    • Data sub-keys will be dasherized.

    For the second change, I realized that the HTML5 JavaScript API automatically converts dashed-words to camelCase, so it makes sense to go by best practices.

    // E.g., #id[data-foo-bar="baz"]
    document.getElementById("id").dataset.fooBar // => "baz"

    If a person prefers more control over this, they can of course declare the entire "data-with_underscores" keys.

  • Repository

    Repository October 17th, 2010 @ 11:19 PM

    • State changed from “open” to “resolved”
  • Jeff Kreeftmeijer

    Jeff Kreeftmeijer November 7th, 2010 @ 04:57 PM

    • Tag cleared.

    Automatic cleanup of spam.

  • bingbing

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

Referenced by