I have tested this item ✅ successfully on 5f7136b

I have tested this item ? unsuccessfully on 5f7136b

With this PR applied, I get a JS error on browser console: "TypeError: s is undefined" in file calendar.min.js when opening an article for edit.

With debug on so unminified script is used: TypeError: btn is undefined in file calendar.js, line 72, column 5.

Without this PR applied, I don't get this error.

If you remove the button then the whole calendar script will not applied to the field. This is particularly problematic for some cases. In sort the js is initialized through the button element, so it cannot be removed.

That said, what is your use case, maybe there is another workaround...

1. If you dont require an element, dont add it to the DOM
2. Due to the nature of Joomla's classitis, if one creates a new template (both front or backend) then they need to add all these pointless classes because they're used in core. And I'm talking about those who care about their sanity and do not wish to override everything.

As for the JS, there is nothing to initialise on readonly or disabled calendar fields. The calendar should not open, period. Unless you're telling me that the JS manipulate the value on page load.

As for the JS, there is nothing to initialise on readonly or disabled calendar fields.

Disabled calendar fields doesnt mean that the JS part doesnt run (it does, check with some multilingual site) and also the calendar doesnt open but the parsing/reformatting NEEDS to happen...

and also the calendar doesnt open but the parsing/reformatting NEEDS to happen

So the requirement of a button being part of the DOM to initialise JS is just wrong. Buttons are clickable elements. I'd strongly suggest using type=date or data-dalendar to init the JS for value manipulation.

So the requirement of a button being part of the DOM to initialise JS is just wrong.

Right or wrong, this is what's there, you can't remove it for purity or you're just breaking the calendar, or even if you fix that you still breaking B/C...

FWIW the calendar needs to move to custom elements as the rest of the form fields. I've said that countless times...

I can't see how moving the JS init based on the input rather than the button would break B/C. I respect the fact that this PR may break the calendar and am happy to close, but a button requirement when it's not even visible is just stupid.

Then do that, but this can't fly just by removing the button, there's much more there. Thats what I pointed out here

EDIT:
Then do that

moving the JS init based on the input rather than the button