Safari Reader vs. cross-document view transitions
Claim: Safari does not offer Show Reader for an article reached by a cross-document view transition. The identical document, reloaded, does offer it. Only the navigation path differs — the markup is byte-identical.
Must be served over http(s). Safari never offers Reader on
file:// URLs, so opening these files directly will show nothing either way.
Test A — with @view-transition
- Open the WITH index.
- Click through to the article.
- Open the page menu. Expected bug: no “Show Reader” — only “Hide Distracting Items”.
- Now reload (⌘R) without navigating away. “Show Reader” appears.
Test B — control, no view transition
- Open the WITHOUT index.
- Click through to the article.
- “Show Reader” is offered immediately, with no reload needed.
Confirmed on
Tested by hand against this reproduction, on separate devices:
| Platform | Version | Result |
|---|---|---|
| Safari — macOS | 26.6.2 (21624.5.1.11.3) | Reproduces as described |
| Safari — iPadOS | iPadOS 27 beta | Reproduces as described |
| Captive browser — iOS | 26.6.1 | Reproduces as described |
| Safari — iOS | 26.6.1 | Differs — see below |
iOS Safari behaves differently
On iOS, taking the WITH path does not fully suppress Reader the way the other platforms do. The Reader button is present, but the page does not announce “Reader Available” on load.
So on iOS the capability survives while the availability signal does not, whereas on macOS, iPadOS, and the iOS captive browser the Reader entry itself is missing until reload. Worth noting because it suggests the announcement and the menu entry are driven separately, and that whatever the transition disrupts sits upstream of both.
What was measured
Both articles were run through Safari's own article-finder
(ReaderArticleFinder.js) inside WebKit:
| Page | Reader finder | Score | Click-through pagereveal |
Reload |
|---|---|---|---|---|
vt/post.html |
found <article> |
33,554 | viewTransition: true |
false |
novt/post.html |
found <article> |
33,554 | false |
false |
Safari's ReaderMinimumScore is 1,600. Both pages clear it by more than twenty
times, and score identically — the transition is the only variable.
Two things this is not
-
Not a layout-timing problem. Sampling
getBoundingClientRect()on the<article>every frame from document-start through the transition gives 92 frames, all stable at 640 × 2004.9, with none below Safari's 280 × 295 candidate minimum. The article is fully laid out the whole time, so the finder is not measuring an unrendered page. - Not the page menu failing. “Hide Distracting Items” is still offered on the affected page. The menu works; only article detection is missing.
See README.md in
this repository
for the full write-up.