Deprecated use of magic jQueryUI widget

Jump to solution
Community Novice

Hello All,

I just got this message in my web inspector:

'You're relying on undocumented functionality where Canvas makes jQueryUI widgets out of rich content that has the following class names: .dialogue, .draggable, .resizable, .sortable, .accordion, .tabs.

Canvas is moving away from jQueryUI for our own widgets and this behavior will go away. Rather than relying on the internals of Canvas's JavaScript, you should use your own custom JS file to do any such customizations.'

I am really just wondering if anybody knows what is going on because our style guide has not yet been updated to reflect this change. We are using accordions in many places and if Canvas deprecates this functionality is going to break a lot of our materials. Thus I want to get out in front of this as quickly as possible. It sounds like Canvas is going to be using their own widgets. Will we still have access to those? If so when can we expect the style guide to be updated?

Any insight into this matter would be appreciated.

Thank you



A solution was found. Canvas suggests that institutions stop using Jquery UI and instead include their own custom code for such things.

1 Solution
Instructure Alumni
Instructure Alumni

Hey everybody, this is Ryan Shaw, from the canvas engineering team. I see a lot of great questions here and some worry so I wanted to chime in to provide some guidance and assurance.

A little background: Canvas has, for a long time, used jqueryUI for our own widgets. So when you see a modal dialog pop up or an accordion or a group of tabs, they were probably using jQueryUI. One day, after talking with some awesome customers at instructurecon that were creating their own content, we decided to add this little piece of code: so that if you added class names like .tabs, or .accordion to your content it would automatically turn that element into that kind of jqueryUI widget for you without having to write any code yourself.

The problem:

First, sometimes the markup that gets created from people doing this in their content is not accessible. So, for example, users using a screenreader would not be able to use that content. That’s a huge bummer for them so we wanted to make sure we weren’t contributing to that.

Second, we are starting to rely on React.JS more and more in our front-end code, and we have even written our own UI library ( that is built on React and is much more modern, has better UX, fixes a ton of bugs that would pop up with jqueryUI widgets and, has some of the best accessibility support of any UI lib I’ve ever seen. So we have started replacing places we were using jQueryUI widgets to use instructure-ui widgets and using the latter exclusively for new code.

So eventually, we hope to get to a point where there is nothing that canvas is doing that is using jqueryUI and loading it will make canvas slower for everyone. jQueryUI is a big javascript library, and loading all of it's code on every page has a real cost in terms of time it takes to download and view every page. We don’t want to slow down all of canvas for everyone even if they are not using this.

That's why we put that warning message in there. And in general, it will be safer and less brittle for your custom interaction code to not be dependent on canvas’ code. So us making a change doesn’t break your code and vise-versa. That’s why we recommend loading your own widget library in your custom ThemeEditor JavaScript file if you want to add custom widgets to your content.

As far as when will canvas stop using jqueryUI anywhere, I’ll be the first to tell you that it will take a long measured in years, not months. And as long as we are loading jQueryUI widgets for something we need on the page, there’s no reason not to expose it like this for you to use too.

So the “official” future-proof, encouraged way of adding your own widgets is to include your own UI library in your custom JS file so it is not dependent on anything from canvas’ code. (On a side note, if you are going to do that, make sure that you are using a library that has good accessibility support, there are a lot out there that look nice but are unusable by screenreaders)

But, if you have a bunch of content relying on this and you are willing to stay on top of things, and check the release notes and react if canvas does stop using jqueryUI, you are free to do so, however it is now considered “unsupported”. But we will say something in the release notes if we ever do remove this feature, and in the worst case scenario you could just add jqueryUI to your custom ThemeEditor JavaScript file and a similar snippet to what we did for this and not have to change any of your content even after we stop supporting this.

I hope that helps clear up some of the what, why, and when behind this question. I love reading these forums, you guys are so innovative, so helpful to each other and your passion to create great educational content shows!

View solution in original post