In mobile devices references and notes can account for 50% of the HTML of an article (see https://www.mediawiki.org/wiki/Reading/Web/Projects/A_frontend_powered_by_Parsoid/HTML_content_research#HTML_size_report), mobile intend to scrub references from the initial output and lazy load them (with suitable non-JS fallbacks).
The references extension builds an intermediate representation (IR) while the page is being parsed. If the parser encounters a <references /> tag (or the parser finishes parsing the page and it didn't encounter a <references /> tag), then the IR is used to build the output HTML. However, the IR isn't stored anywhere.
Building an API to surface the IR would require additional storage. In the worse case scenario references account for around 50% of HTML but the IR is likely to be a lot smaller.
When evaluating serialisation methods, bear in mind that we'd prefer to avoid making the user agent doing any more work than it should do, i.e. MobileFrontend relies on querying the DOM for the note every time the user taps a reference, which could be eliminated if we were to deliver references as a map of reference ID to note.
- References intermediate representation saved via setExtensionData
- API endpoint for surfacing intermediate representation in Cite extension
- No changes in MobileFrontend but someone needs to confirm that API result is compatible with what is happening in mobile.references ResourceLoader module in references.js getReference function