OEP Suggestion: course-wide JS and CSS

[Martin Segado]

Hi all,

Please let me know if this is a good fit for an OEP and I'll put one together. Also let me know if you would also find such a feature useful!

Issue: I and others would benefit from a way to load course-wide JavaScript and CSS assets. There are numerous use cases for this:

• Logging custom events (this alone make the platform even more valuable for conducting research) 
• Consistently styling course content (e.g., by creating classes for things like callout boxes or image alignment)
• Loading useful JS libraries for things like graphing or code syntax highlighting
• Trying experimental features (e.g., a course-material search bar; again, complete with event logging for research)

Existing workaround: It's possible to do this in today's platform, but it requires adding <script> or <style> tags to every single vertical of a course. Clearly this is suboptimal; it increases deployment effort (especially when conducting multi-course experiments) and may needlessly increase network traffic.

Proposed solution: Add a new policy key (name TBD) for course-wide assets:

{
  "web_assets": [
    "/static/mystyles.css",
    "/static/experiment.js",
    "//somecdn.com/library.js"
  ]
}

Proposed implementation: The courseware template already receives and renders an XBlock fragment (which includes JS and CSS resources); additional resources could simply be added to this fragment when the courseware context is created. This approach leverages the existing XBlock/Django infrastructure to handle de-duping and rendering, so I expect little code would be needed for the actual implementation.

Possible concerns & mitigation strategies:

• Security. Again, though, the ability to include arbitrary JavaScript in a course already exists... this feature just provides a more elegant way to do so course-wide. It is possible that making it easier would lead to wider script usage and thus increase the odds of users creating a vulnerability; this could be mitigated by (1) adding a stern warning to the policy key description about including scripts only from trusted origins, or (2) limiting this feature to /static/* files if it's a really big concern.
  
  
• Support. Platform hosts such as edX should make it clear that this is a power-user feature that would carry no support beyond that for current <script> and <style> tags (i.e., the platform guarantees that your scripts will make it into the page, but you're on your own if they don't work or if something breaks due to platform changes). As with security above, it's possible there will be more complaints/support requests from users simply because of wider script/CSS usage, though good documentation and a warning in the policy key description should hopefully keep these to a minimum.

...Thoughts?

Martin (MITx graduate research fellow)

[Andy Armstrong]

Hi Martin,

Thanks for this. The use cases you describe are important, so it would be great to talk through how it can be addressed. I'm not sure if this should be handled as an OEP or not, so I posed that question in our OEP Slack channel (https://openedx.slack.com/messages/open-edx-proposals/).

I have a few thoughts to add to your initial proposal:

 - I like the simplicity of what you are proposing. Using the XBlock runtime's pre-existing loader makes a great deal of sense for the reasons you laid out.

 - I think some of your use cases would be better handled through XBlock dependencies. For example, IMO a complex feature like code syntax highlighting should be associated with a particular XBlock, rather than being added to an Advanced HTML block. Having the assets tied to the course means that even if the block in question is removed, the assets would still be loaded. It would be better to have them requested on-demand by only the blocks that need them. Having said that, we don't have a mechanism in XBlock to allow multiple blocks to share the same library.

 - I'd like to consider how such a mechanism should interact with AMD-style loading. We have had some preliminary experimentation with combining XBlocks with RequireJS, and I think it is important to take that into account.

 - There are performance implications to loading a number of individual files like this. Having said that, it would be difficult to have individual courses contribute files to the static asset pipeline, since courses can be created/imported after the LMS has been stood up.

 - We might want to make this feature be something that can be disabled if a given installation is not comfortable with giving this power to its authors. As you point out, the power is already there through multiple other mechanisms, so maybe this isn't a concern.

Thanks,

 - Andy

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/bbab60d8-eeee-4a4c-935d-75715b7ec33a%40googlegroups.com.

--

Andy Armstrong

edX | UI Architect  | an...@edx.org  

141 Portland Street, 9th floor

Cambridge, MA 02139

http://www.edx.org

[Martin Segado]

Thanks for the reply! Followup thoughts on some of your points below:

- I like the simplicity of what you are proposing. Using the XBlock runtime's pre-existing loader makes a great deal of sense for the reasons you laid out.

...hat-tip to Peter Pinch for that idea ;-)

 - I think some of your use cases would be better handled through XBlock dependencies. For example, IMO a complex feature like code syntax highlighting should be associated with a particular XBlock, rather than being added to an Advanced HTML block. Having the assets tied to the course means that even if the block in question is removed, the assets would still be loaded. It would be better to have them requested on-demand by only the blocks that need them. Having said that, we don't have a mechanism in XBlock to allow multiple blocks to share the same library.

Yeah, I see what you're saying - there's definitely a risk of vestigial libraries being loaded with this approach (or libraries just being loaded earlier than needed). On the other hand, XBlocks also don't seem to me like a great fit for syntax highlighting or similar use cases... some specific concerns:

1. Developing new XBlocks requires enough know-how than it's likely out of reach for course authors (compared to, e.g., dropping in the script/CSS files for PrismJS to add syntax highlighting course-wide)
2. XBlocks have to be accepted/installed into the platform before being used [I think?], while scripts/CSS resources can be added immediately by course authors
3. XBlocks can't currently be nested inside <problem> or <html> modules, so they're not great for things that might appear interspersed with text like code examples or graphs

 - There are performance implications to loading a number of individual files like this. Having said that, it would be difficult to have individual courses contribute files to the static asset pipeline, since courses can be created/imported after the LMS has been stood up.

Agreed, though hopefully this will be less of an issue when HTTP/2 takes over sometime in the not-too-distant future =) The fact that static assets are cached should help in the meantime... it looks like edX sets the Cache-Control max-age to 1 year, and external JavaScript CDNs probably have fairly efficient caching behavior too.

Let me know where I should go from here. Thanks!

Martin

[Andy Armstrong]

Hi Martin,

The conclusion from Slack is that this is a good candidate for an OEP. You can read about the process here:

https://open-edx-proposals.readthedocs.io/en/latest/

You might also want to look at this PR that extends OEP-1 to support product changes:

https://github.com/edx/open-edx-proposals/pull/17

We're all new to the OEP process, so thanks for volunteering to be a guinea pig! Let us know if you need help moving forward.

Thanks,

 - Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/24c480ae-231b-4285-a7d6-dd0f37bf855e%40googlegroups.com.

[Martin Segado]

For anyone reading this, here's the resulting OEP: https://github.com/edx/open-edx-proposals/pull/43