[EuiPageTemplate] Account for new serverless header style

[dominiqueclarke]

I noticed that there's an unnecessary scroll on serverless when the page content does not take up the full page height.

Screen.Recording.2024-05-16.at.10.37.35.AM.mov

Although there is no additional content, the page scrolls due to the specified min-height. I noticed this style applied to the EuiPageTemplate.

min-block-size: calc(100vh - var(--euiFixedHeadersOffset, 0));

This works well for ESS where there is only one fixed header.

However there are two fixed headers in serverless, requiring a different calculation.

[cee-chen]

Minor correction: there are 2 fixed headers on ESS, not 1: the black header and then the white header below that.

As far as --euiFixedHeadersOffset is concerned, Serverless only has 1 fixed header, not 2. Fixed headers are considered full width position: fixed elements that stretch across the entire page, the 2nd one is not a fixed header because it does not supercede the left collapsible nav.

If you want EuiPageTemplate to account for this new "header" type, we likely need a specific EUI component for it, likely an EuiPageTemplate.TopBar element or similar (to mirror EuiPageTemplate.BottomBar).

CC @MichaelMarcialis / @ryankeairns for design input on the above: is the second screenshot part of the official header for serverless?

[paulb-elastic]

Hi EUI Team, do you have a view on when this might be looked into? We are planning where we are with the Observability solution in Kibana for serverless and this is on our radar for elastic/kibana#176177. Thanks.

[cee-chen]

We can look into it now if y'all need - I know serverless work is high priority. What's your preferred timeline on this?

[MichaelMarcialis]

Thanks for the ping, @cee-chen. When we were originally designing the serverless navigation, we consolidated Kibana's then double fixed headers (one dark, one light) down to a single fixed header. However, by reducing the number of fixed headers, we were left with no home for the conditionally appearing action buttons that are present in some Kibana applications (which would typically appear right aligned in the second fixed header). For that reason, we suggested that these action buttons should be housed in a conditionally appearing toolbar container.

This conditionally appearing toolbar was intended to be positioned at the top of the viewport, immediately below the new singular header. It shouldn't scroll with the rest of the page content, allowing it to be visible and within reach at all times (similar to the Kibana header). Unlike the Kibana header however, it would be adjacent to the navigation (rather than above it). As such, the toolbar would need to be treated as part of the flow in regard to the navigation being collapsed or expanded (making the toolbar wider or narrower respectively). Will share some older mockups below that may do a better job conveying this.

Let me know if that makes sense. CCing @ryankeairns to keep me honest.

---

---

---

---

[cee-chen]

This conditionally appearing toolbar was intended to be positioned at the top of the viewport, immediately below the new singular header. It shouldn't scroll with the rest of the page content, allowing it to be visible and within reach at all times (similar to the Kibana header). Unlike the Kibana header however, it would be adjacent to the navigation (rather than above it)

Should flyouts sit above it or below it? Kibana headers are above FWIW

EDIT: Whoops, I see that in the 2nd to last screenshot now - it sits below flyout overlays. Yeah, this is definitely going to need a separate component from EuiHeader.

[cee-chen]

@sebelga Pinging you about this as Tim let me know you're owning the new serverless nav development - would EUI implementing a new EuiPageTemplate.TopBar component work well with your current work? Or would you like to discuss this and #7777 further?

[sebelga]

would EUI implementing a new EuiPageTemplate.TopBar component work well with your current work?

My current work is the stateful side nav 😊 which does not touch the page templates.

I would need to go into the code to see how those serverless actions are rendered in Kibana currently. I would have thought that this could be solved with CSS (some class added to the wrapping div) but I trust your judgment if a component is required 👍

[cee-chen]

Ah okay, @tsullivan informed me you'd taken over ownership of the sticky app bar - maybe he was mistaken? Do you know who on AppEx currently owns it?

If I can't get any clear communication/ownership from either Kibana or the devs who opened this issue, I may end up closing this as a wontfix. To reiterate, the 2nd sticky bar isn't being implemented or created by EUI, it lives in Kibana, so this isn't an EUI bug or issue. We can help resolve it, but not without clearer cooperation from Kibana's side of things.

[sebelga]

I didn't said our team didn't own it, you asked "would implementing a new component work well with your current work ". And I answered that my current work was not related to the sticky app bar.

I just looked now at the code, I don't know why we can't solve this with CSS and why we need a new component.

min-block-size: calc(100vh - var(--euiFixedHeadersOffset, 0));

I see 2 solutions:

• Modify the value of --euiFixedHeadersOffset dynamically. But that might impact other parts of Kibana relying on it
• Overrride the CSS of the page template that sets the min-block-size. I guess it's possible @cee-chen?

@dominiqueclarke, if we have a way to override the css of the page template and we export a CSS var for the app menu bar height, it seems that we should be able to get this issue fixed without EUI

[crespocarlos]

@sebelga @dominiqueclarke page_template_inner.tsx could also consider the --kbnAppHeadersOffset introduced in elastic/kibana#168372 to compute the min-block-size.

min-block-size: calc(100vh - var(--kbnAppHeadersOffset, var(--euiFixedHeadersOffset, 0)));