I have tested this item ✅ successfully on 632ca6c

Working very well. Tested on a few components with different values.

@C-Lodder can you review the JS?

@C-Lodder we need to deprecate the cms.js in j3 and remove it in j4. The code in that file should be either a custom element or some plain js attached to the relative field, same approach as all the rest fields that have some sort of js functionality (calendar, colour, etc)

The showon elements of the cms.js file relates to an attribute that can be applied to most fields so isn't field specific so if JForm specific as opposed to any specific JField type.

The list option specific aspect could be extracted to a separate file but we would need a javascript 'architecture' that allowed for this using callback or pseudo class methods ???

I know this isn't the place to have the debate but if we are not going to use jQuery then we will need our own slimmed down javascript library that is unit tested to avoid duplication of coding effort and code that fails in specific scenarios.

will need our own slimmed down javascript library

No. We have ES5 ES6 and web components. No need for anything else!

@dgt41
I presume you mean we would use code like

xpathresults = document.evaluate('//*[@name="' + fieldName + '"]|//*[@name="' + fieldName + '[]"]', document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null)				

in J4.0 instead of

$fields   = $('[name="' + fieldName + '"], [name="' + fieldName + '[]"]');

That sort of change is quite straightforward for J4.0 and doesn't need a javascript library like jQuery but what about little methods that are used repeatedly in different contexts such as the toggle method discussed above which keeps track of the original display style value, or little animations that would apply to ? Are we not going to have this type of re-usable utility function in J4.0? Would these be added to HTMLElement in a namespace safe way (sorry not sure of the jargon here)?

@GeraintEdwards modern UI should be done through web component or custom elements. If we do it correctly jQuery will be useless (in fact it's already), because frankly we shouldn't do any animations with js but rather pass that to css (60FPS, 16ms Budget and almost all the current recommendations fail with jQuery, especially if you do the test in a cheap android device).
Anyways what you're doing here is fine, but for J4 we might have to rethink the whole approach to these fields.

If you're interested about the custom elements, check https://github.com/joomla-projects/custom-elements
and the relative PR for J4: #17024

Can you sort out the PR so that the only the relevant commits are added?

I think I merged and pushed the wrong branch and now I'm trying to figure it out how to reverse this

Sorted out the bad merge - now the compressed js is up to date with staging and the PR.

What do we need to do to move this forward?

The showon code needs a lot of work:

1. It really slow using jQuery and a large form (I have a prototype version implemented using native query selectors with a pseudo polyfill that falls back to jQuery where the query selector methods don't exist)
2. the toggle needs to be replaced with a CSS transition (this is a very small performance benefit compared to the gains available from improving the finding of conditional elements and processing them on large forms)
3. the toggle/its replacement needs to respect the original CSS state - e.g. a div shouldn't be reset to block if it was an inline-block beforehand
4. the xml syntax should allow for and/or to be combined intelligently with appropriate associative ordering/parenthesis support

A lot of this could be done before 4.0 and I propose putting a PR together to deal with it in the next couple of weeks.

In the meantime cane we move forward with this PR please?

Sorry guys - same problem again with the merge commit. Fixing it now

I'm closing this PR and opening a new one based on a new 'clean' branch.

I'll include references to this one.

Before you submit a PR, I suggest you always update your fork so that you're in sync with the main repo.

Git:

$ git remote add upstream https://github.com/joomla/joomla-cms.git
$ git fetch upstream staging
$ git merge upstream/staging
$ git push origin staging

$ git checkout -b NEW_BRANCH_NAME
// Then do your code changes

Git for Windows/Mac:

• No idea

Thanks - I was trying to merge upstream using my IDE. I'll do it on the command line next time !!

PR is now resurrected as #18998