cmb wrote: ↑Fri Dec 25, 2020 1:08 pm
IMO the proposed solution is a rather good compromise.
Yes, a compromise like life itself.
But the admin menu was actually not in the foreground of the action, but the mutual influence of user templates and core styles should be minimized.
This would only have been successful if the admin menu was on an extra page and all link targets from it were displayed in an iFrame.
This, in turn, would only work if the core was significantly rewritten.
So a compromise. In the whole backend only the styles from the admin template work - except for preview and edit.
cmb wrote: ↑Fri Dec 25, 2020 1:08 pm
I don't want to derail this thread with implementation details, but I've noticed that some new JS uses arrow functions, which have "only" been introduced with ES 6 (what is mostly unsupported by IE 11). I'm fine with dropping IE 11 support for the back-end, but that needs to be clearly documented. And if we enforce more recent browser versions, we should use that opportunity to drop some old fallbacks (AFAIK, the current admin.js still supports IE 8, what makes no sense in 2020).
In the new admin.min.js are actually some new functions in it (=>, let, ...)
This is due to the fact that for the slide functions should not use jQuery. Stupidly, in other places then again jQuery is used. This could and should perhaps be changed for the final version.
For this, it would certainly be helpful if a specialist looks at the whole JS code again and possibly revises it.
For sure some functions can go out - e.g. the actions when focusing the textareas, but the height calculations are still needed.
If obsolete fallbacks can be removed - all the better!
If this is "through", then we can also minify the admin.min.js again