Render UI with admin theme

Thanks for the help.

:root / html / body selectors match nothing inside a shadow root.

Indeed, this is one of the already identified remaining issues.

Custom properties inherit through the boundary, so tokens declared on an ancestor in the light DOM do reach in — which is why this partially works today and will keep partially failing in confusing ways.

Interesting, I will investigate.

Parent→child CSS relationships across a slot are lost.(...) For a builder whose entire purpose is nesting components into slots, this is the most serious fidelity cost, and it applies to both the per-node and single-DSD variants (the single-DSD variant hoists slot content to the top-level host, so it is still light DOM relative to the component that declared the slot).

We are already meeting this issue outside of the current ticket scope, because of our "dropzone" markup in-between a parent component slot and its children. DSD is neither fixing nor making it worse for now, and I am hoping it can help us mitigate it.

@media queries evaluate against the outer viewport. Shadow DOM is not a separate viewport. The ViewportSwitcher cannot produce truthful responsive output by resizing a shadow host — breakpoints will not fire. Only an iframe gives real responsive preview.

We are already meeting this issue outside of the current ticket scope, see #3542003: Responsive viewports with iframes. DSD is neither fixing nor making it worse.

Everything that walks the DOM must become shadow-aware. document.querySelectorAll('[data-node-id]'), elementFromPoint() (returns the host, needs composedPath()), focus traversal, and the Playwright selectors

I don't see how it is a problem but I may be missing something. Playwright tests are green without needing adaptions.

Rebased.

Styling boundaries

We still have the issues previously discussed.

The UI Skins "theme" is visible around each DSD.

Indeed. Can we merge the body attributes into the shadow content attributes?

:root / html / body selectors match nothing inside a shadow root.

It may be related to shadowRootMode property in DeclarativeShadowDomRenderer which is currently managed like that:

• "open" when the request is not triggered by HTMX: Exposes the internal shadow root DOM for JavaScript (recommended for most use cases). It allows CSS variables to "pierce" the shadow DOM
• "closed" when the request is triggered by HTMX: Hides the internal shadow root DOM from JavaScript. It prevents CSS variables to "pierce" the shadow DOM. However, we have declarative_shadow_dom.js which is opening it after load

Some ideas:

• Do we still need a "closed" Shadow DOM for HTMX requests in server side to open it in JS after load?
• Can we "force" :root inside each declarative shadow dom?
• Can we set a :root as a wrapper at the top of the root panel, so variable will be initialized and will "pierce"

Custom properties inherit through the boundary, so tokens declared on an ancestor in the light DOM do reach in — which is why this partially works today and will keep partially failing in confusing ways.

It already works well with the current state of the MR:

• I add a SDC in the slot of another SDC
• In the parent SDC, I change the value of a design token used by the child SDC using the dedicated Panel
• The value is updated in the child SDC even if it is sandboxed in its own Shadow DOM

DOM manipulation

Everything that walks the DOM must become shadow-aware. document.querySelectorAll('[data-node-id]'), elementFromPoint() (returns the host, needs composedPath()), focus traversal, and the Playwright selectors

It was not an issue until the big UX revamp of July, all mechanisms were working well during manual testing and the playwright tests were all green.

However, we now have playwright fails which may be related to DOM traversing:

• Move within the Navigator
• Move and circular guard
• SSE relays another session edit

and some false negative (we don't manually reproduce the issue, we may just need to adapt element.dragTo(target, {):

• Occupied slot - drops from the library:
• Occupied slot - moving an existing node in
• Navigator keeps Collapse all through a Canvas move

Enthusiasm for this task has been warmly expressed during DrupalCon Rotterdam's demos & workshops 😉

So, here is the current state after a big rebase and the addition of assets/js/shadow_root_styles.js

Core needs a patch

Solution found 🎉 We were missing a Core patch!

--- a/core/misc/htmx/htmx-assets.js
+++ b/core/misc/htmx/htmx-assets.js
@@ -125,7 +125,11 @@
     });

     // The response is the whole page without the assets we handle with loadjs.
-    detail.serverResponse = responseHTML.documentElement.outerHTML;
+    // Unlike outerHTML, getHTML() keeps the declarative shadow roots that
+    // Document.parseHTMLUnsafe() attached, when they are serializable.
+    detail.serverResponse = `<html>${responseHTML.documentElement.getHTML({
+      serializableShadowRoots: true,
+    })}</html>`;

     // Helps with memory management.
     responseHTML = null;

I will create a Core issue soon.

What is already OK

General:

• ✅ Hide .gin--navigation-top-bar which is always displayed with a breadcrumb for admin pages with Core Gin

In Builder/Scaffold:

• ✅ Dropping components & blocks
• ✅ Moving stuff around
• ✅ Right-click menu and its actions: copy, paste, save as preset,
• ✅ open contextual panel on click
• ✅ Nodes updates from modification in ContextualForm Panel, StylesPanel...
• Support placeholders and lazy loader (the admin theme logo was rendered instead of the front one in the site branding block) ⚠️ we need a documentation update, with a schema
• ...

In Library panels' preview pop-ins:

• ✅ Components
• ✅ Blocks
• ✅ Pattern presets

By spliting DSD in root and non-root versions:

• ✅ Don't apply body styles on each shadow root. Some themes have opinionated styles on body element (example: DaisyUI), so only copy body styles in the root shadow dom.
• ✅ Theme switch (as UI Skins' design systems themes) works.
• ✅ "Custom properties inherit through the boundary, so tokens declared on an ancestor in the light DOM do reach in" still works
• ⚠️ It was tempting to shadowrootmode="closed" for the root (it doesn't need to inherit custom properties to ancestors), but it doesn't render properly when closed, so let's keep it open;
• ✅ To make "Render components" feature of Scaffold panel works with CSS variables defined in tree ancestors, we have also added a root DSD at the top

Tests:

• ✅ PHPUnit is green on pipeline.
• ✅ Playwright support "open" shadow dom: https://playwright.dev/docs/locators#locate-in-shadow-dom
• ✅ Playwright tests on ddev are fine if:
  • all display builder test modules are activated
  • the display_builder_theme_test is the only front theme installed
  • the German language is activated.
  • navigation module is not installed

⚠️ Playwright fails in the pipeline don't happen on local environment and may be related to the absence of the Core patch.

Remaining work

• ⚠️ Remaining fails in local playwright: scaffold.spec.ts:17:5 › Move tests @extra: it doesn't seem related to the changes
• ⚠️ With SSE, even if the playwright test is green, the Preview panel is replaced by a timestamp integer. But I have the same issue on 1.0.x branch in my local environment, so it may not be related to the current work.
• ⚠️ What about "Cross-origin stylesheets" ? Is it something to be careful about?

Next step?

The proposal add less than 300 lines of PHP and 100 lines of JS (tests excluded), so it is kind of tight, but we may be able to clean it a bit:

• Remove the remains of db-block custom element?
• Remove $htmx_route from DeclarativeShadowDomRenderer::executeSubrequest() ?
• Remove $admin from DeclarativeShadowDomRenderer? It is always FALSE as far as I know
• Remove DeclarativeShadowDomPageVariantSubscriber?
• Remove html--ds-shadow-dom.html.twig and page--ds-shadow-dom.html.twig templates and their associated logic?

Christian may have an idea to have a single DSD for the full builder (the current approach has nested DSD, it is totally fine in my opinion, but challengeable if we have better idea).

It works :)

3 commits in the MR:

1. feat: #3562060 Render UI with admin theme: the proper change, but need a Core patch
2. Without Core patch: less elegant, with one additional JS file, but don't need the Core patch
3. Unrelated phpstan fixes

Notice for the reviewer:

• I feel a performance boost using Declarative Shadow Dom but id didn't measure it, is it also the case for you?
• There is 1 phpunit fails but it doesn't seem related to the current work: OverrideDisplayTabs: Canonical page lists the rendered display only: ✘ Current display is excluded from its own list. Am I wrong?
• Is the PreviewPanel in SSE replaced by a timestamp integer? If yes, is it also the case with 1.0.x branch?

Local tests:

Next steps / Follow-ups:

• It could be interesting to combine this work with #3627705: Align the builder UI with the Default Admin theme, by removing some overrides instead of remapping them
• As said previously, the change is not that big/complicated (around 400 additional LOC), but it can be made even simpler once we validate it works well
• Documentation update
• Gin in Core ("default admin") manage Light/dark theme switch. What do we need to adapt?

Following our today meeting, assigned to you for review. Don't hesitate to ask questions if necessary.

For your information, I have removed the form.css content because it was the most relevant place to check unaltered admin theme rendering.

here is the compare but did not rebase 3562060-follow-up-render-ui, so perhaps including other merged fix.

Thanks for the compare, that's convenient. I will push the 3562060-follow-up-render-ui rebase to help me visualizing this.

MR 468 review.

Feature review

Cool stuff:

Other feedback:

• ✅ Entity View Overrides and Pattern Preset routes for display building are now rendered with admin theme, it was forgotten in the initial MR.
• ⚠️ The gin toolbar is visible. In MR 183, it was hidden by hook page top

Code review

A look on the gitlab compare page:

• ✅ More CSS Cleaning/removal (partially ported to they initial MR when it has been rebased)
• ✅ the OverrideDisplayTabs phpunit fail (Current display is excluded from its own list) is fixed
• ✅ Some proposed clean-ups have been done: DeclarativeShadowDomPageVariantSubscriber, db-block, $admin from DeclarativeShadowDomRenderer...
• ✅ Removal of RenderableBuilderTrait::wrapContent()
• ✅ Addition of a data-db-shadow-body . May be useful.
• ✅ Simplification of ThemeHooks::stripChrome() now the builder page is not rendered in front theme anymore. However, ⚠️ do we still need _display_builder_full_page_route ?
• ⚠️ Some hook_theme have been added in src/Hook/ThemeHooks.php instead of manipulating the registry. It is not blocking the MR, but is is sad we are back to rely on ThemeManager API while we are pushing to replace them.
• some changes about SSE (in display_builder.twig, ApiControllerBase, ProfileViewBuilder) I am struggling to understand and evaluate

Hi Jean,

Thanks for the new MR which is improving the DSD proposal while removing 90 lines of PHP code.

I move the ticket to RTBC, knowing:

• the feedback and proposals can be discussed in follow-up ticket(s):
  • Remaining cleanup opportunities: DeclarativeShadowDomRenderer::executeSubrequest(), hook_theme, _display_builder_full_page_route...
  • Gin toolbar removal?
  • Light/dark theme switch
  • The "weight" select is now visible in forms (example: field:node:article:field_test[value][sources][0][_weight])
• there is a competing proposal under review in #3629497: Render the Canvas in an iframe on the front theme to address some execution issues in components specific JS