Skip to content

Frontpage slider - #321

Draft
beckej13820 wants to merge 5 commits into
cuny-academic-commons:masterfrom
beckej13820:master
Draft

Frontpage slider#321
beckej13820 wants to merge 5 commits into
cuny-academic-commons:masterfrom
beckej13820:master

Conversation

@beckej13820

@beckej13820 beckej13820 commented Mar 22, 2026

Copy link
Copy Markdown

Boone, can you take a look at this pull request. This is an example of using the Splide JS carousel as a drop in replacement for the older camera.

I'm interested in your opinion, it removes ~3,000 lines of code and replaces them with 300 lines of code because more of the core behavior comes from the JS library.

This was created with Claude Code. I tried to guide it as best I could not to write a ton of code or javascript, but to rely on existing packages and the current styling. The packages would be handled by npm, it uses the existing custom post type to generate the slides.

I'm going to continue to explore what the Splide JS library can do, but my mentality was to recreate the current styling of OpenLab and just do a proof of concept.

Here's an AI generated summary of the changes by Claude Code:

--

Replace Camera.js slider with Splide.js on the front page

This PR replaces the outdated Camera.js slider on the front page with Splide.js, a modern, accessible, and actively maintained slider library. The slider custom post type is unchanged — no content migration required.

Changes

  • Added @splidejs/splide and grunt-contrib-copy as dev dependencies via npm
  • Updated the Grunt build to pull Splide's JS into the vendor bundle (replacing camera.mod.js) and copy Splide's CSS from node_modules into the theme's css/ directory
  • Replaced Camera.js-specific HTML output in openlab_get_home_slider() with Splide's expected markup (splide, splide__track, splide__list, splide__slide)
  • Removed the screen-reader duplicate markup (camera_wrap_sr) — Splide handles accessibility natively via semantic HTML and ARIA attributes
  • Updated style.less to replace Camera.js-specific styles with equivalent rules targeting Splide's classes, preserving the text-over-image overlay design
  • Replaced the Camera.js initialization and manual alt-text workaround in utility.js with a clean Splide init; arrows and pagination dots are automatically hidden when only one slide is present
  • Removed the sliderFocusHandler function, which was a manual accessibility patch no longer needed

Testing (These tests were all done on a local dev environment

[x] Front page renders slider correctly with multiple slides
[x] Text overlay appears over the right side of each slide
[x] Forward/back arrows and pagination dots appear with multiple slides
[x] Arrows and pagination dots are hidden when only one slide is published
[x] Slider renders correctly across blue, green, and red color schemes
[x] No JavaScript console errors on the front page
[x] Slides that are missing a featured image are ignored.
[x] If the text is too long, a scroll bar appears for overflow text
[x] Tested for accessibility with Deque Axe Dev Tools Pro, no errors
[x] Tested for accessibility manually with VoiceOver on Safari and Narrator on Edge.

@beckej13820
beckej13820 marked this pull request as draft March 31, 2026 12:07
@beckej13820

Copy link
Copy Markdown
Author

If this proof of concept looked good, I could keep working on this. For example, the Spindle project has some settings that we can expose to admins, to give them control over things like autoplay, transition type, duration.

I'm curious if AI can allow the OpenLab admins to do some issues more independently, while allowing @boonebgorges to give us oversight and guidance.

@boonebgorges

Copy link
Copy Markdown
Member

Splide in general seems like a fine library for this purpose. The design and layout of interaction buttons are different in this implementation than in the current one. IMO this is probably fine and indeed better, since the existing interaction (such as little bitty circles for nav) is not very good for mobile and probably also has some other a11y issues. But the team should make these design decisions holistically.

As for the AI part of it, I think it's fine to use these tools to build prototypes. I don't love the workflow of having other team members build things using AI tools and then having me review them for actual inclusion in CBOX. Building tools for distribution involves a number of considerations beyond what an AI agent will be able to accomplish out of the box, with specific guidance and prompts. For me to do this after a PR has been opened is a different and in many ways more difficult task than if I myself had steered the agent to build something. As such, for the time being, I would like to limit the use of AI-assisted tools to prototyping, proofs-of-concept, and building tools that are intended to run on an individual site and not be merged into CBOX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants