Change Details

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). Given an article's references are not needed straight away it should be possible to obtain them via an API separately from the rest of the content and render this functionality via JavaScript. 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](http://chimeces.com/loot-content-analysis/) but the IR is likely to be a lot smaller: [] How much space does the serialised IR require? * What's the best serialisation method to use in terms of size/performance? [] Where should this data be stored? ExtensionStorage? Memcached? 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. #mediawiki-extensions-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.

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). Given an article's references are not needed straight away it should be possible to obtain them via an API separately from the rest of the content and render this functionality via JavaScript. 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](http://chimeces.com/loot-content-analysis/) 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. #mediawiki-extensions-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. Acceptance criteria: [] 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

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). Given an article's references are not needed straight away it should be possible to obtain them via an API separately from the rest of the content and render this functionality via JavaScript. 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](http://chimeces.com/loot-content-analysis/) but the IR is likely to be a lot smaller:. [] How much space does the serialised IR require?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. #mediawiki-extensions-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. Acceptance criteria: * What's the best serialisation method to use in terms of size/performance?[] References intermediate representation saved via setExtensionData [] Where should this data be stored? ExtensionStorage? Memcached? 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. #mediawiki-extensions-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.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