Table of Contents

Understanding Canvas Customizations/Stylesheets

Casey Shew Updated by Casey Shew

Overview

As you are probably aware of, eCornell uses Instructure’s Canvas for our learning management system. One of the features of Canvas that is very advantageous for our use case is the mechanism they provide to upload custom JavaScript and CSS files at the account or subaccount level to enable the customization of the look/feel and functionality in the account. This mechanism is called the Theme Editor. There is a Theme Editor attached to every Canvas account and subaccount, and each has its own area to define custom colors and icons, as well as upload a CSS and JavaScript file for more specific and advanced customizations.

This theme editor provides the mechanism by which different Canvas instances or accounts are made to look and behave differently than others, and why certain page components may work when housed in one Canvas account (or subaccount) but not another. This discrepancy is generally due to the presence, or lack, of certain CSS or JavaScript files uploaded to that account’s theme editor. It should be noted that the theme editor customizations of accounts and subaccounts in Canvas cascade, such that subaccounts inherit all of the code configured in their parent account/s, and additional code can be added to the subaccounts on top of the inherited code from the parent account/s.

How eCornell Leverages the Theme Editor

At eCornell, we use the Theme Editor’s CSS/JS customization mechanism for a wide range of different utilities. The following are examples of the types of things we use it for, but it’s not limited to just these!

  • Specifying custom fonts, colors, and base CSS styles for our instance
  • Manipulating the broader Canvas user interface to better suit our brand and student experience goals
  • Defining custom layouts that use CSS/JS not supported by the Canvas RCE (i.e. On-Demand homepage, Video Playlists/ATEs, etc…)
  • Creating custom branding for specific unit- or partner-oriented subaccounts
  • Centralizing video embed code for central management/updates and more responsive design (specifically Kaltura videos)
  • Loading non-LTI tools and frameworks to include in Canvas (i.e. Pendo, jQuery, etc..)
  • Creating and embedding custom widgets and webapps for specific course needs (i.e. Click to Reveal widgets, Comp Cost Calculator, Spidergraph, etc…)

Yes, all of this is accomplished with just a few CSS and JavaScript files! (albeit very long ones)

There are of course some downsides to using this mechanism so heavily. One of the biggest is that with our content having more custom code dependencies, it’s less easily portable to other systems. Another is that with more customization, the probability increases that new releases from Instructure will conflict with something in our code base and cause an issue. This is to say that while this powerful ability Canvas gives us is fantastic and readily utilized, there should be some caution to adding more and more customization.

Customizations on lms.ecornell.com vs. canvas.cornell.edu

As you are probably aware, lms.ecornell.com is the instance of Canvas on which we deliver our certificate programs, and was our first instance of Canvas. As such, this is where our CSS/JS customizations originated, and our course content naturally became reliant on those customizations to function properly - from custom page layouts and widgets, all the way down to the video players. canvas.cornell.edu was set up many years after lms.ecornell.com, as the university decided to migrate to Canvas from Blackboard to deliver their for-credit courses. 

Many quickly realized when using canvas.cornell.edu, either when importing content developed on lms.ecornell.com or when developing new content, that many of the core components of our courses were not functioning properly on this new instance. Of course, this was due to the Theme Editor not having our CSS/JS files uploaded to it at the root account level. To address this issue, CTI determined it best to set up subaccounts specifically for courses that use eCornell content with its associated layouts, widgets, and styles. The top-level account on canvas.cornell.edu does not have our Theme Editor files present, as it was determined that base styles in our files were not desired globally for all of canvas.cornell.edu, as well as to avoid any potential conflicts with subaccount customizations from other units. Additionally, it was determined that even for the eCornell subaccounts, we would not add the customized surrounding navigation that we use on lms.ecornell.com. The concern was that it could be disorienting or confusing if a student was taking some courses inside an eCornell subaccount and some not, and the surrounding navigation changed when switching between these courses.

All of that being said, this means that while any new course added on lms.ecornell.com automatically will get all of our primary customizations applied to it (because the top-level account on that instance has our Theme Editor files uploaded to it), the same is not true for canvas.cornell.edu. This is because our Theme Editor files are only uploaded to the eCornell-specific subaccounts and not the top-level account. This can result in things like videos not loading properly and page layouts looking broken. To fix these issues, the course in question simply needs to be associated with one of our subaccounts, and then those Theme Editor files will be applied to it resulting in all of our customizations working. A course can only be associated with one subaccount at a time, so it’s generally a good idea to confirm that removing the current subaccount association and changing it to one of ours is not a problem. In rare cases, a course’s administrative staff may have specific needs to keeping the course in a different subaccount than ours, this is rare but these situations require creative problem solving to meet all of the needs.

Customization Scenarios - How to Handle

The following is a list of common scenarios that relate to Canvas customizations and how you should handle them. If your scenario is not reflected in this list, when in doubt, contact Casey Shew and Jason Carroll!

Scenario: A course on canvas.cornell.edu that uses eCornell content is not working properly (videos won’t load, etc…) what do I do?

How to Handle: Shoot an email to Casey Shew (casey.shew@cornell.edu) and Jason Carroll (jasoncarroll@cornell.edu) with a link to the course, or specific course code and term, and an indication of what the course will be used for, as well as a description of the specific issue.

Scenario: I need a new page layout or widget that I cannot make with Canvas’s supported HTML/CSS, and also cannot be accomplished with existing third party tools/solutions (i.e. H5P)

How to Handle: First assess if this will only be used once in one course, or it is intended to be reused repeatedly. If the former, consider writing all of the code in an HTML/CSS/JS file locally, uploading to S3, and then iframing onto your Canvas page. If the latter, or the former and iframing is not appropriate/effective, submit an RTB ticket on Jira and Danny Freire will be assigned in an upcoming sprint to add code to our theme editor files to support this.

Scenario: I’m working with a new partner that requires custom branding that we don’t currently have for their courses

How to Handle: In this scenario, a new subaccount will likely need to be created to apply the custom branding to. Begin with sending an email to Casey Shew (casey.shew@cornell.edu) explaining the requirements from the partner. Depending on the scope and complexity, you may be directed to submit an RTB ticket on Jira, but individual guidance will be provided based on the situation.

Scenario: I’m encountering a bug/issue with our customizations that cannot be resolved by editing the HTML

How to Handle: Submit an RTB ticket on Jira and Danny Freire will be assigned in an upcoming sprint to address the issue.

How did we do?

Canvas HTML Allowlist/Whitelist

Contact