Skip Navigation

[Resolved] jQuery UI Conflicts due to overwritten CSS

This support ticket is created 2 years, 8 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 - - 9:00 – 13:00
14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 - - 14:00 – 18:00

Supporter timezone: Africa/Casablanca (GMT+01:00)

This topic contains 2 replies, has 2 voices.

Last updated by Jamal 2 years, 8 months ago.

Assisted by: Jamal.

Author
Posts
#2142845
Screenshot 2021-08-15 at 09.58.35.png

I load jQuery UI with a custom scope into a GUI of a plugin I am using, so I do not conflict with other plugins using jQuery UI.

It was a tad of a pain to make it work with other Plugins loading jQuery UI (I bet Toolset Developers can sing songs of the same challenge).
I noticed that Toolset has a particular way of ensuring styles are applied to the Toolset UI as desired, it seems basically it erases any custom classes from the main jQuery UI wrappers that are not starting with an ui- and then appends its own class to the wrapper.
This caused issues when loading my own, properly scoped jQuery UI Style made with the theme roller. However I was able to solve that the same way as Toolset seems to do - adding my own CSS scope to the wrapper on the fly whenever any of the particular buttons is clicked that triggers my own UI.

This works great (although unconventional), but I couldn't help to notice that Toolset is applying CSS styles to some generic classes of the UI without considering its scope.
One such example are "buttons".
See the attached screenshot and the CSS loaded by Toolset without scope as follows:

body.wp-admin .wpcf-ui-dialog
,body.wp-admin .wpcf-ui-dialog .ui-dialog-titlebar
,body.wp-admin .wpcf-ui-dialog .ui-dialog-titlebar-close
,body.wp-admin .wpcf-ui-dialog .ui-dialog-content
,body.wp-admin .ui-corner-all:not(.button)
{
    -webkit-border-radius: 0;
    -moz-border-radius: 0;
    border-radius: 0;
}

We can see most of the selectors are considering the scope, but not body.wp-admin .ui-corner-all:not(.button)
This of course causes every "not .button" items (the UI button here has class ui-button instead of button) to apply Toolset Styles.
I think this can be done better, by scoping it, like so:
body.wp-admin .wpcf-ui-dialog .ui-corner-all:not(.button)

I am aware that this is likely no priority for Toolset but it would be nice to have this fixed instead of hardcoding an !important into my own UI theme, which even if I use scope everywhere, is the wrong thing to do.

#2143059

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hello Beda and thank you for contacting Toolset support.

I'll escalate this issue to our 2nd Tier for another opinion. And I'll get back to you as soon as possible.

I must confess that I did not reproduce it on a clean install to fully understand what happens. And I wonder if you would like to provide a minimal plugin to reproduce this issue on a clean install?
I created a sandbox installation if you want to upload the plugin on it. You can log into it with the following URL hidden link

#2143743

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hello Beda, the issue has been escalated to the developers. As you figure it out, it is a trivial fix that we should add when we'll update our CSS in an upcoming release.

All the best,
Jamal

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.