No. The white flash is not because body was left out of the named view-transition elements.

OD-3008 only assigns view-transition-name to .sidebar and .topbar. That is intentional: those two boxes are captured as their own snapshots so chrome does not blank with the rest of the document. html is already the automatic root participant. body is included in that root snapshot, and it already has a page background (#EEF0F8 in light mode, var(--dark-mode-darker) in dark mode).

Giving body its own view-transition-name would not stop the flash. Page content still lives in body, so it would still use the browser's default cross-fade. Naming body would also work against the "only pin chrome" design from OD-3008, and it can stack awkwardly with the automatic root name on html.

What you are seeing is that default root animation: ::view-transition-old(root) fades out while ::view-transition-new(root) fades in. At the midpoint both snapshots are translucent, so the canvas behind the ::view-transition overlay shows through. That canvas is typically white, which is why the page looks like it flashes white — especially in dark mode.

Sidebar and topbar are separate snapshots, so they should not disappear with the document, but they still use the same default fade unless those animations are customized.

Reducing the flash would mean giving html / ::view-transition a theme-matching background and/or replacing the default root (and maybe chrome) animations — not adding a name on body.

What you are seeing is that default root animation: ::view-transition-old(root) fades out while ::view-transition-new(root) fades in. At the midpoint both snapshots are translucent, so the canvas behind the ::view-transition overlay shows through. That canvas is typically white, which is why the page looks like it flashes white — especially in dark mode.

What if we made the canvas transparent? Would this impact light mode or dark mode themes?

Making the canvas transparent would not remove the flash, and it would not treat light and dark mode the same.

::view-transition is already transparent. That is why the fade flashes white: at the midpoint you are looking through two translucent snapshots at whatever sits behind the overlay. During the transition that is not the live html / body background (#EEF0F8 in light mode, var(--dark-mode-darker) in dark mode). It is the browsing-context canvas, which stays the UA default (typically white) because we do not set color-scheme on html.

So a transparent canvas:

• Light mode: little visible change. The page is already near-white, so a white canvas blending through is easy to miss.
• Dark mode: the flash stays, or gets worse. White still shows through #151521.

Transparency also does not restyle either theme after the transition ends. The html / body theme colors stay as they are.

If the idea is to let the canvas follow the theme, that is color-scheme (for example html.dark-mode { color-scheme: dark; }), not background: transparent. Even then, an opaque theme-matching background on ::view-transition — or replacing the default root cross-fade — is the more reliable way to hide the midpoint.

Yes, but the problem with setting the color scheme on the HTML is that .sidebar is always dark. So this would work well if the user was using the dark scheme. However, if the user is using the light scheme, then the sidebar will flash white.

Kindly consider a solution.

Agreed. color-scheme on html is the wrong lever here.

.sidebar is always var(--dark-mode-dark) (#23232d), including in light mode. color-scheme only sets one browsing-context canvas color. In light mode that canvas is light, so the default sidebar fade (::view-transition-old(sidebar) / ::view-transition-new(sidebar)) still shows that light color through the translucent snapshots. Dark mode would look fine; light mode would flash the sidebar.

A single canvas color cannot be both the page theme and the always-dark sidebar.

The fix is to stop relying on the canvas, and treat each snapshot group as its own surface:

1. Paint the overlay / root group with the page background (#EEF0F8 in light mode, var(--dark-mode-darker) in dark mode). That removes the white root flash without color-scheme.

2. Hold chrome opaque. OD-3008 named .sidebar and .topbar so they would not blank with the document; the default cross-fade on those names is what lets the wrong color show through. Disable that fade (and mix-blend-mode: plus-lighter on the image pair) so sidebar stays dark in both themes and topbar stays white or dark with the theme.

3. If a chrome fade is still wanted, give ::view-transition-group(sidebar) a fixed var(--dark-mode-dark) background, and ::view-transition-group(topbar) the same background as .topbar (white / var(--dark-mode-dark)). Do not use color-scheme on html for this.

Option 2 plus a theme-matching ::view-transition background is the one I would implement: root still cross-fades on a themed backing, chrome stays put, and light-mode sidebar never punches through to white.

That looks good to me.

the chrome fade is still wanted.

What would also be absolutely amazing is to add view transitions for fixed elements, such as for .sidebar As well as its good children and grandchildren, which will help achieve a smooth transition effect. The same goes for .side-info

What are your thoughts on the feasibility of this?

Feasible in part, but not as a blanket “name .sidebar and every descendant” (or the same for .side-info).

Cross-document view transitions require a unique view-transition-name in each document. A duplicate name skips the whole transition — that is why OD-3008 named only .sidebar and .topbar, and left .side-info and .main out.

Unique, always-present sidebar chrome is feasible: .sidebar-header, .sidebar-brand, and .sidebar-footer. Those can have their own names so they morph independently of the menu body. .sidebar-body is also unique, but it is a large region whose contents change; naming it adds another snapshot without much extra smoothness.

Menu items and other grandchildren are not feasible as a CSS-class pass. .sidebar-menu, .menu-header, .menu-item, and .menu-link are repeated (user/admin menu plus project menu; many items). Labels are not unique either — Code exists as both a top-level submenu and a Settings submenu. Unique names would need a stable per-item key in markup, which OD-3008 deliberately avoided (no extra HTML ids, no Wicket markup ids). Even with keys, pairing only helps when the same item exists on both pages (in-project navigation). Project → administration drops most items, and each extra name is two snapshots.

.side-info cannot take the class name. a.side-info is duplicated on issue/PR/build pages (header trigger + dock). div.side-info is usually one panel, but:

• On desktop it is in-flow, not position: fixed. Lifting it out of the root snapshot would float the pane while .main cross-fades around it.
• It is fixed only below 1199px / .hide-side-info.
• Many layout pages have no panel at all.
• Children (.header, .body) are generic, and the body is page-specific (issue vs PR vs build), so grandchildren almost never pair.

I would keep chrome names at .sidebar / .topbar, add the themed overlay + group backgrounds we already agreed (fade kept), and not name sidebar descendants or .side-info unless we later add a carefully unique key for a small set of stable pieces (header/brand/footer only).

That looks good to me.

Please create a new issue for this work and close this issue. Ensure to identify the motivation and design rationale, so that everything is clear in that new issue without needing to refer back to this one.

Created #3026 for this work. It is self-contained: motivation, why the flash happens, rejected approaches (body name, transparent canvas, color-scheme on html, naming sidebar descendants / .side-info), and the agreed design (themed overlay + chrome group backgrounds, fade kept). Closing this question.

@zaakiy can you record a screen cast to demonstrate the issue? I did not notice any flash.

@zaakiy no need for the screencast. I clicked more and did find white flashing. It is even worse than not applying the transition, as page loading feels slow now. I will revert the change.