#JavaScript

We still don't update to major versions of some libraries, e.g. jQuery 4 was only committed to Drupal 11, but in 2012 we didn't have a two year major release cycle, and I think that is frequent enough that it allows us to introduce major revisions to js libraries quickly enough.

Supporting major versions for approximately 4 years each allows us to cycle out older versions quickly enough too - e.g. jQuery 3 when Drupal 10 is EOL.

Updating minor and patch versions every six months is mostly allowing us to keep up with security updates. Ckeditor5 can get tricky because they don't support their own minor versions for 12 months, but the proposal here wouldn't help with a ckeditor5 release one month before a core minor version goes out of support.

In 2012 a major release cycle was more like four years and we also supported Drupal 7 longer than Drupal 9. So for me this issue is thankfully outdated.

Updated the issue summary to link to the current documentation.

1. Introduce a different set of rules for build and development dependencies.
It is not clear to me what the proposed rules are?

2. for build/dev: we should have the assumption that when no policy exists we defer to the license. Usually that means: no guarantee.
Is this issue suggesting to stop the current practice of opening issues in the dependent project?

3. Rely much more on tooling for build/development dependencies to scan periodically for security issues (like it's been set up for once) to help mitigate point #1 and #2
Is there an existing issue to improve tooling to do this?

If there is clarity on 1 and 2, I am sure we can work up proposed text.

The first line of the issue summary states, "our current policy is to never update them once a stable release of Drupal core comes out." That is no longer true. Dependencies are updated before each minor and can also be done in a patch release. Since that has changed, and there is little conversation here since 2016, I question if there is any decision to be made here.

Is there anything to do here?

I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

ARIA Implementation:

// Example of potential ARIA announcement approach
const announce = (message) => {
  const polite = document.getElementById('tabledrag-aria-live');
  polite.textContent = message;
};
announce(Drupal.t('Row moved to new position'));

Weight Input Replacement:

<!-- Current -->
<select class="tabledrag-weight">
  <option value="-15">-15</option>
  <!-- ... -->
  <option value="15">15</option>
</select>

<!-- Proposed -->
<input type="number" class="tabledrag-weight" min="-50" max="50" step="1">

Would an option to disable the "Show row weights" / "Hide row weights" toggle button, either completely or on a role-basis via Permissions fit in this issue as well, or maybe it is already handled in another issue, or need a new issue?

nod_ → closed merge request !11971

Committed d381523 and pushed to 11.x. Thanks!

Tried to simplify some things.

For the credential forms we don't need to change too much logic, we need to reverse some conditions and it works as expected.

@robertom Thanks a lot for improving this patch.

It's now working perfectly for my needs and my request, which was taxonomy only. I didn't try another bundle indeed.

Ok, I think this is ready.

I tested manually both in 11.x and this branch locally.
I tested block and view contextual links and tested with both mouse and keyboard. As far as I can tell both act exactly the same.

I searched for references to backbone, the only references remaining are for toolbar. There are no more references in contextual.

Javascript is not my forte as mentioned, but I am familiar with it, reviewing the code directly I see nothing that looks amiss.

As far as I can tell both larowlan and _nod have worked on this to a non trivial extent.

The only thing I didn't check that may be worth it is performance. I'm not super familiar with JS performance testing so I'll leave that up to a committer to determine if it's necessary.

_nod's comment in 56 make me think the change has been addressed as far as I can tell.

We need a change record with code examples to show when the condition in #38 is likely to occur and code sample to show how to fix it.