[meta] Use HTML5 data-* attributes instead of #ID selectors in Drupal.settings

The data attributes are definitely something we should use. Drupal.settings can get pretty hairy at times. Switching to data attributes would improve page loading speed, clean up the markup, and reduce the amount of code required.

jQuery 1.6 greatly improves the performance of .data() retrieval, so postponed for #1085590: Update jQuery UI to the latest in the git repository.

Changing to a meta issue so that we can split it into different parts of core... AJAX settings, Tabledrag configuration, etc, like Damien mentioned.

Subscribe.

There are some cases where .once() could be switched with .data(). The benefit would be speed as the DOM wouldn't have to re-render the elements, the downside is that we wouldn't be able to select the newly processed elements with CSS.

I have been using data- attributes to handle urls in the sliding navigation on my latest mobile navigation prototype. http://nav3.d8mux.org/admin

I think that Drupal.settings is a nice convention. Perhaps we can make it an interface that other javascript implements. That implementing code can decide show it's going to store data (localStorage, data- syntax, ajax to key-value storage mechanism).

If we're talking about a persistence layer for our javascript, should the ideal solution be generalized enough for this?

User Stories:

• I have a complex widget or component that needs to know it's state, I want to persist data that drives state-based logic
• I have a slideshow that both cycles through slides AND loads a separate set of slides when the the "View More" link is clicked
• In a site with media elements I want to store an offset variable that controls the starting point or endpoint of that media file
• When listing ordered assets, I want simple ways to mass reorder based on metadata of the thing
• I want to dynamically reorder all the photo nodes that drive a gallery grid view based on a property
• I want to dynamically sort a list of movie nodes that are in my queue based on properties: genre, title, rating.
• I want to dynamically update the comment count of my blog post in near real-time (long polling)
• For a multi-state block, want to store the settings of nonactive states so I can quickly switch from my currently active state to another state.
• For a form that can create more form elements dynamically add more items, I want to store the default settings of those child items so that I don't have to do a round-trip to create more.
• For a form that can create more form elements dynamically, I want to store a child count constraint or other restrictions on the form so that I can control the behavior of my form without the need of a round-trip with the server.

List of complex widgets that may qualify as needing data- to drive state-based logic

• Dashboard blocks
• Poll
• Tree structures
• Lists
• Dynamic Forms
• More?

Edit module: data- attributes implementation

In the Edit module, I'm using data- attributes to add metadata to existing output (specifically: rendered fields and entities). Often, the ID attribute is already set. Even more often, classes are already set.
So, what I do is: 1) never add an ID attribute; 2) add classes for selecting (I cannot imagine jQuery('[data-edit-id]') to be faster than jQuery('.edit-field')); 3) add data attributes for describing, in my case: data-edit-id which is <entity type>:<entity ID>:<field name> and data-edit-field-label.

I still use Drupal.settings, but only for "global settings", such as the URL where subforms can be generated (which is built based on the data-edit-id).

Best practice?

AFAICT, the best practice rule regarding ID+class vs. data- attributes is very simple, and as follows:

For selecting, use classes or IDs. For metadata, use data attributes.