[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 👍