Change Details

## Requirements - Identify links to pages that do not exist. - Support different red link behavior on desktop (class, link to edit view) and apps (remove links). - Support re-styling of red links for skins & accessibility. - Perform well, both server & client side. ## Non-requirements - Stub thresholds: These can be implemented client side with a separate API request, for users that have this option enabled. ## Solutions ### Separate metadata Provide a JSON array containing hrefs of pages that do not exist. On most pages, this array will be very short or empty. Clients can then use this array to find links to non-existing pages, and apply the transformations they would like. Advantages: - Easy to implement server side. - Avoids latency overheads of server-side DOM parsing. - Can be consistently applied to old content. However, a general limitation of red link updates for old revisions is that current link tables are only available for the latest revision, which means that links in old revisions might not be updated. - Consistent matching interface helps clients render red links for specific use cases. Disadvantages: - Client requirements: - Process JSON and run JS. - Extra API request. - API complexity: Need to expose metadata in separate API. ### Parsoid DOM pass Retrieve list of red links in page (as in separate metadata solution), and rewrite href / add classes in DOM processing pass. Advantages: - Still relatively easy to implement server side. - Low extra cost. - No need for JS on the client. - Compatible with existing skins. - No need for extra API. - Records accurate 'at the time' snapshot of how a page looked. Disadvantages: - Implements a specific kind of handling / rewriting, which then needs to be undone / changed for other use cases. - Changes in href (ex: linking to edit views) complicate matching for further post-processing. Not touching the href would mean that clients would need to modify the href dynamically, negating the advantage of not needing to execute JS. - Does not automatically update for old revisions. - Increases fraction of re-renders that change the content. ### Parsoid DOM pass + html2html update end point As in `Parsoid DOM pass`, but also update red link markup in old revisions through a Parsoid HTML2HTML end point. Advantages: - As for `Parsoid DOM pass`. - More up-to-date red link information in old revisions. Disadvantages: - Extra complexity in Parsoid and RESTBase. - Increased latency and cost for accesses to old revisions, especially if the update is applied on each request.

## Requirements - Identify links to pages that do not exist. - Support different red link behavior on desktop (class, link to edit view) and apps (remove links). - Support re-styling of red links for skins & accessibility. - Perform well, both server & client side. ## Non-requirements - Stub thresholds: These can be implemented client side with a separate API request, for users that have this option enabled. ## Solutions ### 1) Separate metadata Provide a JSON array containing hrefs of pages that do not exist. On most pages, this array will be very short or empty. Clients can then use this array to find links to non-existing pages, and apply the transformations they would like. Advantages: - Easy to implement server side. - Avoids latency overheads of server-side DOM parsing. - Can be consistently applied to old content. However, a general limitation of red link updates for old revisions is that current link tables are only available for the latest revision, which means that links in old revisions might not be updated. - Consistent matching interface helps clients render red links for specific use cases. Disadvantages: - Client requirements: - Process JSON and run JS. - Extra API request. - API complexity: Need to expose metadata in separate API. ### 2) Parsoid DOM pass Retrieve list of red links in page (as in separate metadata solution), and rewrite href / add classes in DOM processing pass. Advantages: - Still relatively easy to implement server side. - Low extra cost. - No need for JS on the client. - Compatible with existing skins. - No need for extra API. - Records accurate 'at the time' snapshot of how a page looked. Disadvantages: - Implements a specific kind of handling / rewriting, which then needs to be undone / changed for other use cases. - Changes in href (ex: linking to edit views) complicate matching for further post-processing. Not touching the href would mean that clients would need to modify the href dynamically, negating the advantage of not needing to execute JS. - Does not automatically update for old revisions. - Increases fraction of re-renders that change the content. ### 3) Parsoid DOM pass + html2html update end point As in `Parsoid DOM pass`, but also update red link markup in old revisions through a Parsoid HTML2HTML end point. Advantages: - As for `Parsoid DOM pass`. - More up-to-date red link information in old revisions. Disadvantages: - Extra complexity in Parsoid and RESTBase. - Increased latency and cost for accesses to old revisions, especially if the update is applied on each request.

## Requirements - Identify links to pages that do not exist. - Support different red link behavior on desktop (class, link to edit view) and apps (remove links). - Support re-styling of red links for skins & accessibility. - Perform well, both server & client side. ## Non-requirements - Stub thresholds: These can be implemented client side with a separate API request, for users that have this option enabled. ## Solutions ### 1) Separate metadata Provide a JSON array containing hrefs of pages that do not exist. On most pages, this array will be very short or empty. Clients can then use this array to find links to non-existing pages, and apply the transformations they would like. Advantages: - Easy to implement server side. - Avoids latency overheads of server-side DOM parsing. - Can be consistently applied to old content. However, a general limitation of red link updates for old revisions is that current link tables are only available for the latest revision, which means that links in old revisions might not be updated. - Consistent matching interface helps clients render red links for specific use cases. Disadvantages: - Client requirements: - Process JSON and run JS. - Extra API request. - API complexity: Need to expose metadata in separate API. ### 2) Parsoid DOM pass Retrieve list of red links in page (as in separate metadata solution), and rewrite href / add classes in DOM processing pass. Advantages: - Still relatively easy to implement server side. - Low extra cost. - No need for JS on the client. - Compatible with existing skins. - No need for extra API. - Records accurate 'at the time' snapshot of how a page looked. Disadvantages: - Implements a specific kind of handling / rewriting, which then needs to be undone / changed for other use cases. - Changes in href (ex: linking to edit views) complicate matching for further post-processing. Not touching the href would mean that clients would need to modify the href dynamically, negating the advantage of not needing to execute JS. - Does not automatically update for old revisions. - Increases fraction of re-renders that change the content. ### 3) Parsoid DOM pass + html2html update end point As in `Parsoid DOM pass`, but also update red link markup in old revisions through a Parsoid HTML2HTML end point. Advantages: - As for `Parsoid DOM pass`. - More up-to-date red link information in old revisions. Disadvantages: - Extra complexity in Parsoid and RESTBase. - Increased latency and cost for accesses to old revisions, especially if the update is applied on each request.