This allows users to select (and copy) and entire column, without ending up with an interlaced mess.
Note that CSS grids are not supported by all our target browsers:
So the table layout will need to be preserved for legacy browser users.
As the DOM order will change between the table layout and the grid layout, the conversion will have to done with JS.
The above approach is a bit hacky as it modifies the DOM output significantly after doing some feature detection. It could be gadgetised.
A better approach would be to create a new DiffFormatter in the backend that outputs the grid DOM structure, but it’s hard to know which structure the client supports ahead of time.
Once we are generating the grid DOM on the server the following options are available:
Output the grid DOM only and fix the alignment using JS for browsers which don’t support CSS grids (similar to how ContentTranslation keeps paragraphs aligned). You would then have:
- browsers which support CSS grid (~93% according to caniuse) get a correct layout instantly, regardless of if JS is enabled
- browsers without CSS grid (mostly IE11) will get a two column layout, with the rows aligned momentarily later by JS
- if JS disabled and no CSS grid support (probably a small fraction of a percent), then side by side diff without alignment shown.
Grid and table
Another approach would be to ship both versions of the diff (grid and table) to the client, and then only show the one which is supported using an @supports selector. The downside here is increased bandwidth for large diffs, but it would work in all browsers without requiring JS.
I also expect a lot of gadgets and extensions (three col diff, revision slider ?) have come to rely on the current table DOM, so changing that could cause regressions.