[Reporting] Remove layout management behaviour

[jloleysens]

This issue is intended as a point of departure for other issues that can inform a more well-defined project (with stakeholders). This issue should be closed once this information has been translated to a more well-defined project.

Summary

Reporting injects custom CSS and JavaScript into the server-side rendering environment to adjust layout for print. See:

• x-pack/plugins/reporting/server/lib/screenshots/inject_css.ts
• x-pack/plugins/reporting/server/lib/layouts

This code is responsible for adjusting UI elements outside of the control of Reporting after they have been rendered. The adjustments optimise the UI for the requested media.

The problem

An implicit contract exists between the UI being rendered (the plugin) and the behaviour of the renderer (Reporting). If either of these changes it will often not be explicit that something may have broken in generated reports until they are re-tested. This "knowledge" that Reporting has is implicit and can be classified as tech debt since it is a burden to maintain and forces Reporting into the domain of what is being rendered not just the process of rendering.

Additionally, any issues encountered with layout are often routed to both the reporting team and the plugin team which creates ambiguity in ownership.

Remove all layout code that adjusts client components

Reporting should not have any concept of "layout" that extends to the domain of how components should respond to different view port sizes or print media. Reporting should only be responsible for rendering a page in the specified size and sharing the result.

This means that clients of reporting become fully responsible for managing layout and should provide a URL to access the print-friendly version of their content.

Path forward

We want to get consumers of reporting to a place where they are empowered to make decisions about how their app looks in the browser and on print and screen media. We also want to ensure that the UX for getting a printable version of various pieces of UI is consistent for all users (cmd/ctrl+P). This is outlined as option 2 for giving users a way to get PDF/PNG reports without saving.

Migration path

In conversation with @timroes we spoke about how removal of layout-related code (CSS and JS) in Reporting will require coordination across the Reporting, Core, Maps, Dashboard, Visualize and Canvas teams to achieve.

A solution: Pure CSS and print media solution

Plugins could add and maintain some CSS that targets print media. Hiding irrelevant visual elements and repositioning any relevant elements once a browser attempts to the print the page.

Challenges

• Today we offer the ability to capture a screenshot "as is" and a screenshot that is optimised for printing on A4 paper, this is "print" vs "screen" media. Will CSS offer everything we might want for creating the kind of layouts we want for those to media for all different views users might want to print?

Related issues

• Getting reporting to a place where full report state is saved with the report object [Discussion] Generating PDF/PNG reports should not require a saved object in plugin #99890

CC @tsullivan

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[tsullivan]

@jloleysens and I spoke earlier today and found that the existence of the xpack.reporting.capture.viewport width and height settings interfere with this effort, since the application (Dashboard) should have its own styles for print view that define the viewport width and height.

Since xpack.reporting.capture.viewport is undocumented and users have no reason to change it, I see those settings as functionally just a constant in the code.

The plan is to deprecate xpack.reporting.capture.viewport by declaring it as unused, and just use constants in the Reporting code (for now). PR: #114019. The settings will be removed from the config schema in 8.0.