I am working on a new Chrome layout for Kibana using CSS Grid for the Workspace Chrome project. The plan is to create it as a second layout engine and merge the progress into the main branch while keeping it hidden behind a feature flag. While building, I am integrating some workarounds for EUI components to work with the new layout, but I hope we can remove these workarounds before making the new layout ready for production and enabling the flag for users.

The main difference between the old layout and the new layout is that, instead of just a fixed header, we can now have a fixed footer and side navigation on the left and right. To implement this, we’re changing from a fixed display for the header with padding on the top of the body to a grid layout.

Proper detailed figma link: https://www.figma.com/design/10ca4AhnWDkyJklUDXnHg5/Sidebar?node-id=5192-259808&p=f&m=dev

So far, I have found and hacked around the following EUI places that need improvements to work with the new layout. They usually come from areas where EUI uses the variable –euiFixedHeadersOffset, which is no longer sufficient.

🟨 Overlay Flyout

Overlay flyout in EUI is implemented as a body element with –euiFixedHeadersOffset position from the top. In new layout we need to support flyout that are application scoped so they should visually appear inside application area:

Currently I hacked it by overriding the flyout css and by having sidebar index higher the flyout (for appearance animation behind the sidebar):

.kbnBody .euiFlyout:not(.euiCollapsibleNav) {
 // overlay flyout should only cover the application area
 &[class*='right']:not([class*='push']) {
   ${logicalCSS('top', 'var(--kbn-layout--application-top, 0px)')};
   ${logicalCSS('bottom', 'var(--kbn-layout--application-bottom, 0px)')};
   ${logicalCSS('right', 'var(--kbn-layout--application-right, 0px)')};
 }

But we need a proper solution. Possibly allow specifying the parent container for flyouts instead of using the body by default?

🟨 Push Flyout

Similar problem with the push flyout. Right now, it assumes that it pushes the body, but we need it to push the application container instead. The workaround on the Kibana side is a bit more complicated. We listen for the padding-right on the body that EUI sets and apply it to the app container.

Update:

The terrible hack in Kibana will be removed with this simple EUI improvement #8872

This is a good short-term solution, but in the long run, we talked with @tkajtoch about EUI looking into supporting push flyouts related to the specific container instead of body.

🔴 pushMinBreakpoint in flyout

Currently it is relative to the body, but we need it relative to the flyout container.

🔴 Any other useBreakpoint?

No exact use-case or workaround yet, but we most likely need to redo useBreakpoint usage to be relative to some closest “breakpoint” container instead of a body.

✅ EuiCollapsibleNavBeta

This nav is used for solution navigation and serverless. It works well for fixed layout and it would be tricky to make it work properly for the new grid layout. we need to decide if we need to tweak it to work with the new layout or if we can straight away go to using new nav with grid layout

Updated: We with @weronikaolejniczak decided to keep it working as is with the grid layout (using push flyout mechanism), but integrate the new side-nav as a proper grid cell into grid layout

✅ EuiFlyout's includeFixedHeadersInFocusTrap

Currently all EuiFlyouts include all EUI fixed headers into focus trap. Since in new layout the headers are no longer fixed, they are not included into the focus trap by default. We need a mechanism to globally define more "default" focus shards in addition to predefined EuiHeader[fixed]

Updated: This behavior should be covered by #8849 and new includeSelectorInFocusTrap prop and config for flyout

Longer term, we discussed that EUI should probably get rid of all the fixed headers assumptions .

🆗 EuiPageTemplate grow={true} always adds unnecessary scroll

minHeight resolves to 100vh which is too much for new layout causing unnecessary scroll

🆗 Fixed header assumption in EuiPageSidebar

sticky={true} assumption should be re-worked to better suit the new layout.

Currently I hacked it with css overrides