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

I would definitely welcome removing most of our current Javascript settings and embed those directly in the DOM. Most of the settings (AJAX settings, Tabledrag configuration, etc.) target precise elements anyway.

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 to jQuery UI 1.9.

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

I wouldn't necessarily agree with converting most, but general usage of data attributes is absolutely a must. Whether data attributes make sense vs. Drupal.settings needs analysis per use-case. Non-ID selectors being the prime example, of course. Markup may also be replaced via #ajax and may use the identical settings afterwards.

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.

Would love to see some progress here. Adding it to the current sprint.

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

So anyone has any ideas for this?

I'm not totally convince that data-* should completely replace Drupal.settings. But maybe we can give developers a simple way of getting their data-* attributes, even though technically is already pretty simple.

Maybe this is just documenting a new way of doing things.

Actually I have no idea :-p just starting the conversation all over again.

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?

I fully agree that some things needs to get out of Drupal.settings. Some data structure in settings are workaround to be able to use $.extend() and they are not very pretty (I'm looking at you ajaxPageState).

I'm not sure we want an abstraction over localStorage or data-, they have different use-case and have a API that's not too bad, nothing like the DOM from a couple of years ago, but I don't know, it could be good to have. At least I'm sure about using data- attributes (like most people here).

So I guess the next step to get this going is list all use-cases in core and decide case by case what we're going to do. Anyone up for it?

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?

About form elements i don't think that'll be possible because I think FAPI needs to precess things on the server too. That would be cool if that was possible though.

• Another one even if xjm is going to kill me: states.js use fields attributes to store conditions.
• use data- attributes to store the offset of some DOM element that has a position:fixed and displace tableheader properly #1440628: [Meta] javascript toolbar/tableheader with url fragment mess

(edit)
From sun @ IRC

One fantastic use-case for html5 data- properties would be the Modules page. Output the dependencies of a module in data- properties, and if you hit submit with missing dependencies, show an dialog or whatever that asks you to also enable the dependencies. I.e., keep the server-side validation logic, but make the client-side quicker/faster/better.

Indeed #1473760: Use data-* to check modules dependencies before submit.

Revise description summary to point to branching issues from this meta issue.

add js-related issues

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.

Over at #675446: Use jQuery UI Autocomplete, we're switching to the data- attribute for the autocomplete path.

add data-drupal-states

from the css & markup perspective this would be wonderfull :)
we could then remove the js- prefix from the css, so a theme could pack whatever css it wants without unfortunately breaking drupal - an epic win !

+3 for this

g

Removed reference to Dashboard CSS cleanup as that's not in Drupal core anymore.

Added major bug fix pending

Actual name proposed and used for a while already.

suppose related is affected by this change

Found interesting bug:

When you have an ajax form on the page, and when some ajax operation happened, Drupal send new generated form elements IDs to the drupalSettings.ajax array. See HTML IDs are now randomized for AJAX responses

Suppose we need some kind of client-side invalidation? Does this problem will be solved by using data attributes instead of global variable?

Ah.

It looks bad but does it trigger wired bugs on the page? Because if it does it might be more than a major bug…

No, I didn't find any bugs related to this, on frontnd or backend.

But if you have a heavily used ajax form (for example ajax filter, like exposed views filters), your page in browser will be larger and larger, and finally crashed.

Ok good, not critical then.

We need a new major issue for this. Can you open one please? I have a few ideas to solve it.

Sure. Please follow: #2561619: Drupal Ajax objects and settings grows endlessly

This issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.

This could potentially be implemented in a minor with BC, so moving to 8.2.x.