[yetanothertw]

Summary

To address #2889 and improve the experience reading the Cross-cluster replication compatibility matrix I've added the :matrix: highlight to the table directive. This now adds a cross-hair highlight to the row/column value and also a fullscreen mode where a user can see the entire table at a glance. (This functionality didn't exist at the time when the issue was opened.)

Changes

• Added the matrix highlight + table directive
• The 8.0–9.0 bucket is split into 8.0–8.17, 8.18, 8.19, 9.0 and 9.1+, with new cell values. Details: The old 8.0–9.0 bucket claimed that a local 9.x cluster could follow a remote 8.0, or a remote 7.17. The Elasticsearch code says neither works (as per Claude). This was a real error in the data, not a presentation problem.
• Removed 5.x and 6.x cells as none of these can interact with a current version and they don't fit the current page's audience (9.x docs) Details: 7.17. It's the one old version that can still follow, or be followed by, an 8.x cluster.
• minor rewording

Questions

I'm contemplating removing the older, unsupported versions from this table.

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes
• No

[github-actions]

Elastic Docs AI PR menu

Check the box to run an AI review for this pull request.

• Review docs changes (docs-review). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

[github-actions]

🔍 Preview links for changed docs

• deploy-manage/tools/cross-cluster-replication.md

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[yetanothertw]

Hi @eedugon, I've added you here as a reviewer, since this is somewhat related to #7529 that we've reviewed before.
Hope that's okay :)

[eedugon]

This isn't rendering well:

From that picture I'd think the local cluster versions are the ones appearing in the first (actually second) row, when the local cluster versions appear in the first column.

Update: Sorry I was wrong, the local cluster is the second row, and the remote cluster is the left column, so that's all right. But somehow, naturally, I'd expect it the other way, but that's a matter of taste (local cluster = 1st column, remote cluster versions = in the row):

(that's taken from CCS docs)

Another question: would it make sense to show first the newest versions? Starting on the top / left with 9.x and ending (bottom / right) with 7.17? (although CCS docs don't do it)

[eedugon]

Note that I also believe some of the ticks are incorrect, even when I'm not sure what's what (local vs remote rows).

These 4 are between 9.0 and 9.1 :

And that doesn't look correct. If local is on 9.0, the remote cluster shouldn't be in 9.1.x, no matter if the note says The matrix shows compatibility between local and remote clusters when the local cluster runs a later version than the remote cluster. It feels wrong, although maybe it's me and it's too early :D

[eedugon]

Added some comments, this feels a bit weird.
I'd suggest to switch rows and colums to show local cluster versions in the first column, so each row would mean "what versions can a local cluster connect to".

Also some of the ticks look incorrect.

[yetanothertw]

Thank you, @eedugon!

I've been staring at this table for way too long and am also confused 😅 haha

I think I got it right now!

Can you please review again?