Revamped InteractiveLayout based on grid module

[frederickobrien]

Part of the grid module cinematic universe (see #15428, #16119, #16133, #16251) for context), this updates InteractiveLayout to use the grid module, and adjusts layout routing to send older pieces to the older setup.

This is near identical to the implementation for StandardLayout save for one key difference. Here the article body itself uses the same grid system. This is to allow for Ed Design in particular to create bespoke article layouts easily. I wonder if this is actually preferable even for non-interactive articles? We could snap elements to the grid rather than using hardcoded negative margins.

The PR also does away with the legacy content__main-column--interactive class on the article body, which had lingered longer than it probably should.

Why

• This makes the starting point for interactive articles normality, rather than a layout which more often than not needs to be rearranged by the atom itself. This will directly lead to less hacky boilerplate DOM manipulation code in interactive atoms, which I think everyone is in favour of
• Aligns interactive articles with the Source design system and even opens the door to being merged with StandardLayout (if there's appetite for that)
• Like StandardLayout this will make it much easier to add new header/furniture arrangements as first class citizens of the platforms

A few open questions

• Display related content in right column or no?
• Why is scrolly behaviour patchy in this new setup?
• Shall we replace the ::before element for centre rules with a more hackable div?

Switchover

Discussion around how to handle older interactive articles is ongoing. This current working approach is to version the content section of the layout depending on date.

Some open questions:

• Do we want the most read sidebar to return?
• Possible to toggle whether ads appear in the article body specifically?
• Could/should/do we want to make InteractiveLayout and StandardLayout one and the same?
• How do we set and hold a contract around data attributes, etc.

Screenshots

Before	After

[github-actions]

Deploy build 29563 of dotcom:rendering-all to CODE

All deployment options

• Deploy build 29563 of dotcom:rendering-all to CODE
• Deploy parts of build 29563 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[frederickobrien]

Why this legacy class was still being applied: #3113

[github-actions]

Deploy build 2373 of dotcom:ab-testing to CODE

All deployment options

• Deploy build 2373 of dotcom:ab-testing to CODE
• Deploy parts of build 2373 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[CDicksonG]

Blocked behind a discussion of how interactives age (Mission: Janitor)

[frederickobrien]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Merge conflicts resolved. The only conflict was InteractiveLayout.tsx, which was deleted in this branch but modified on main. Since the PR replaces it with new components and DecideLayout.tsx no longer imports it, I resolved by keeping the deletion. All other changes from main merged cleanly.

[frederickobrien]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Merge conflicts resolved in commit 9f602ee. Two conflicts:

1. InteractiveLayout.tsx — deleted in this branch, modified on main; kept the deletion since DecideLayout.tsx no longer imports it.
2. StandardLayout.tsx — kept our branch's version (the isLegacyInteractive conditional routing to InteractiveArticleGridDeprecated / StandardLayoutContentGrid); main's inline <article> content was already extracted into StandardLayoutContentGrid.tsx.

[akash1810]

Please rebase this branch against main before deploying to CODE. #16321 made some changes to CI and infrastructure. Deploying this branch without these changes present will either:

• Fail when using Riff-Raff's default update strategy
• OR delete the new infrastructure if using Riff-Raff's "dangerous" mode

Please rebase this branch against main before deploying to CODE.

[egargan]

I'm still digging into this change and what it means for interactives developers, I'll come back to you with a full review in the coming days, but some initial thoughts...

• The new layout markup looks a lot simpler. No more lines or border elements, less nesting, fewer classes... it'll make layout hacking somewhat easier! These are significant changes though which the interactives team should be made aware of, and it's vital that the old/new layout switch works as expected: most of the interactives I've reviewed look very broken – often unreadable – when rendered with the new layout.

• About the publication date guard: does webPublicationDate ever change? is there a scenario where an already-published article with old-style atoms is somehow re-published, then is no longer rendered with the deprecated layout?

• I'm not sure if this is a real issue, but when looking at that Trump trifecta piece in the new layout, the support section at the bottom spans the full width of the page...

  

• The "Most viewed" panel is conflicting with immersive atoms. In articles like this, with immersive atoms towards the top, it looks like there's no "overlap" check between what's in the body and the most viewed panel. I'm assuming this applies to regular articles too? Do we need an ads-spacefinder-style overlap check?

  

[egargan]

Following up on our chat before Fred, the only thing I didn't mention in my last comment was the point about the left-column-body border. It being ::before on the headline element is surprising, and if we ever want to move the headline around for whatever reason, that border will move with it.

You said you'd already considered keeping the borders as actual elements, but I do think this approach would stand up to page hacking more than ::before's would. Accidentally moving them would be harder, as you'd need to explicitly move the border elements, versus whatever element the ::before is attached to.

Otherwise, this is all looking good!

[github-actions]

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.