Research Findings: Existing Extensions vs. Custom Solution

This document summarizes research into whether Wikifunctions / Abstract Wikipedia should reuse existing MediaWiki reference-related extensions (Cite, Popups, MobileFrontend) or implement a custom reference solution.

Option 1: Reusing Existing Extensions (Cite / Popups / MobileFrontend)

Pros

• Consistency with Wikipedia Using the same extensions ensures visual and functional consistency with standard Wikipedia reference behavior.

• Works out of the box with all features For standard use cases, the extensions work immediately without custom code. They support different reference types, styling, and interactions.

• Accessibility Existing extensions already handle keyboard navigation, screen readers, and other accessibility requirements.

Cons

• MobileFrontend extension not available The MobileFrontend extension is not loaded on Wikifunctions / Abstract Wikipedia, so the reference drawer does not work out of the box on mobile devices.

• Cite extension async HTML issues The Cite extension expects reference content to be present during initial page load. WikiLambda function outputs are rendered asynchronously, which prevents proper initialization.

• Extension dependency risk Reference HTML must comply with extension-specific standards. Changes to upstream extensions may break our implementation, and we have no control over those updates.

• Complex HTML requirements Extensions require strict HTML structures (e.g. ol.references, cite_note-* IDs), which are difficult for Wikifunctions editors to generate correctly.

• Limited customization Behavior and appearance cannot be easily customized without modifying core extension code, creating maintenance and upgrade challenges.

Option 2: Creating a Custom Solution

Pros

• Simpler HTML We can define minimal, easy-to-generate HTML, making it easier for Wikifunctions editors to add references without understanding complex Cite markup.

• Unified solution A single implementation can work consistently across Wikifunctions and Abstract Wikipedia.

• Async-friendly References can initialize correctly even when content is rendered asynchronously. We fully control timing and initialization.

• Custom Drawer with upstream potential We can build a custom Drawer using Vue.js and Codex and later upstream it to Codex, contributing back to the MediaWiki community.

• Full control Complete ownership of the implementation allows optimization for WikiLambda-specific use cases and requirements.

• No external dependencies Eliminates dependency on extensions that may change or break unexpectedly.

• Tailored UX The reference experience can be designed specifically for Wikifunctions editors and readers, potentially improving usability.

Cons

• Development effort Requires building popup and drawer functionality, accessibility features, and styling from scratch.

• Maintenance burden Ongoing responsibility for maintaining, testing, and updating the reference system.

• Testing requirements Must be tested across browsers, devices, and accessibility scenarios already covered by existing extensions.

• Potential inconsistency A custom solution may look or behave differently from standard Wikipedia references, which could confuse some users.

Conclusion

Based on the research conducted in this sandbox:

• Existing extensions have critical limitations While Cite and Popups work well for traditional Wikipedia articles, they are not suitable for WikiLambda’s use case. Key blockers include:
  • Async HTML rendering (Cite expects content at page load)
  • Missing MobileFrontend on Wikifunctions (no mobile drawer)
  • Dependency risks from upstream extension changes
  • Complex HTML requirements for editors

• A custom solution is recommended A WikiLambda-specific reference system provides:
  • Simpler HTML for editors
  • Unified behavior across Wikifunctions and Abstract Wikipedia
  • Async-friendly rendering
  • Full control over implementation
  • No external dependencies
  • UX tailored to WikiLambda users

• Modern ecosystem opportunity Building a custom solution allows us to leverage Vue.js and Codex to create a modern, maintainable implementation. The Drawer component can later be upstreamed to Codex, benefiting the broader MediaWiki ecosystem.

• Trade-offs are acceptable While a custom solution introduces development and maintenance costs, these are justified by async compatibility, platform unification, and independence from extension changes.

• Variant 3 demonstrates feasibility but is not viable long-term Inline reference patterns using .mw-reference-text and matching IDs work only in synchronous read views. They do not support async rendering or broader use cases and will not be built upon.

• Path forward We will proceed with Variant 4, using a simple custom HTML structure supported by custom JavaScript for popover and drawer behavior.