Possible to make a Service Portal header vertical (sidebar) instead of horizontal?

[Chris Sanford1]

I am trying to create a vertical header menu on the left side of the screen in Service Portal, similar to the left menu on the HI Portal. But I haven't had much luck. If I set the height to 100% and give a fixed width with CSS, the menu will be vertical, but all of the content will fall underneath it, and you'd have to scroll way down to see anything other than the menu. Is there a way to configure a menu such that the rest of the page content will be side by side with the menu, rather than underneath it?

[benjamin_alldri]

The overflow: scroll will always have a sidebar on the element. Try removing that property.

Are you able to show us a screenshot of what's happening so we can see the result you're seeing? It might be easier to diagnose that way.

[Chris Sanford1]

Here you go. This is with the scrolling removed.

If I add a footer, it also seems to go on top of it which is undesirable. So maybe I need to embed the entire body of the page in a parent container, and make my containers rows instead? Hopefully I can come up with a better solution than doing that on every page of my portal..

[benjamin_alldri]

Ha, seeing that immediately made me realise the problem.

position: fixed by design doesn't honour margin properties, so it will need to be replaced with bottom instead. Also, specify a z-index for your footer which is higher, and that will guarantee that the navbar doesn't go over the top of it.

That being said, because the navbar is effectively in the document flow, you'd ideally want it to be specified as a column in the Bootstrap layout, whereby you have it and the main container on the same row, with the footer on a new row, like so:

Excuse the crude drawing (I don't have my normal tools!), but the pink boxes would the a <div class="row"></div> in your code. Not entirely compliant with the SP way of doing things, but still possible.

[Chris Sanford1]

Thanks. When you say 'Not entirely compliant with the SP way of doing things," do you mean that because the portal only lets you modify HTML at the widget level? That seems to be the limitation I'm faced with and the fixed positioning doesn't work since I can only apply that CSS at either the page level on the container class or the widget level.

So for the solution you show in that diagram, you're saying I would have to put the entire page content in one container and one row, put the sidebar on the left column, and put everything else within rows and columns of a second column of the same parent row. And repeat this on every page in my portal?

And that makes sense about not using margin for fixed positioning. I replaced "margin-bottom" with "bottom" and got the following:

Closer, but I now have the problem of it not being within the document flow of either the header or the footer. If I had full control of the page HTML I could put the page content, header and footer in parent classes each with relative positioning, but I don't think portal gives me that level of control. I'm familiar with z-index, but then the header and footer would just cover up my sidebar content.

[benjamin_alldri · Accepted solution]

Thanks. When you say 'Not entirely compliant with the SP way of doing things," do you mean that because the portal only lets you modify HTML at the widget level? That seems to be the limitation I'm faced with and the fixed positioning doesn't work since I can only apply that CSS at either the page level on the container class or the widget level.

So for the solution you show in that diagram, you're saying I would have to put the entire page content in one container and one row, put the sidebar on the left column, and put everything else within rows and columns of a second column of the same parent row. And repeat this on every page in my portal?

Yup, that's the way it'd work in normal HTML. As you mention, SP doesn't seem to give you that level of granularity so it's a bit of a rock and a hard place.

And that makes sense about not using margin for fixed positioning. I replaced "margin-bottom" with "bottom" and got the following:

It surprises me that bottom would still leave you with that result. You could try setting top, bottom, and left explicitly and let the browser determine height dynamically instead of setting it to 100%. Off the top of my head I can't remember which rule takes precedent when both of those are used together (I believe height likely does).