Comments

Damien Tournoud’s picture

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.

RobLoach’s picture

Title:Consider use cases for custom data-* attributes» Use data-* attributes instead of ID selectors in Drupal.settings - Meta issue
Component:theme system» javascript
Status:Active» Postponed
StatusFileSize
new77.67 KB

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.

sun’s picture

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.

Jacine’s picture

Subscribe.

sun’s picture

Title:Use data-* attributes instead of ID selectors in Drupal.settings - Meta issue» [meta] Use HTML5 data-* attributes instead of #ID selectors in Drupal.settings
Status:Postponed» Active
RobLoach’s picture

Issue tags:+JavaScript

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.

Jacine’s picture

Issue tags:+sprint

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

LewisNyman’s picture

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

ericduran’s picture

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.

cosmicdreams’s picture

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?

nod_’s picture

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?

cosmicdreams’s picture

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?
nod_’s picture

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.

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

nod_’s picture

Issue summary:View changes

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

nod_’s picture

Issue summary:View changes

add js-related issues

Wim Leers’s picture

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.

RobLoach’s picture

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

RobLoach’s picture

Issue summary:View changes

add data-drupal-states

mortendk’s picture

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

mortendk’s picture

Issue summary:View changes

g

cosmicdreams’s picture

Issue summary:View changes

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

catch’s picture

Issue summary:View changes
catch’s picture

Issue summary:View changes
martin107’s picture

Issue summary:View changes

Added major bug fix pending

catch’s picture

Priority:Normal» Major
catch’s picture

Issue tags:+beta target
LewisNyman’s picture

Issue tags:+frontend
LewisNyman’s picture

Issue tags:-sprint