[IGN-1222] Docked Window Breakpoints

Currently in the BMS Demo there is a main view with breakpoints, and navigation is essentially “hard-coded” into the screen.

If you wanted to re-create the same sidebar navigation with docked views, you can with system.perspective.alterDock. This is great, because it is easier to ensure other people will implement pages that use a shared dock, than it is to ensure they will all be implemented in a way that can wrap into a main view. Only downside with this approach is there isn’t a way to determine the current width of a docked view, only to change it, but that’s a different item.

The other part of navigation, the bottom navigation in smaller form factors, is a great idea. However it is also hardcoded into the screen, so in order to turn it into a docked view it would require having a max-width breakpoint instead of a min-width breakpoint. Currently the breakpoints are all min-width and there isn’t an ability to change it. Could that be added? It would make it much easier to have navigation of a totally different structure on different sized form factors.

I opened a feature request for that a long time ago and have added your interest to the ticket.


One thing that could also make this easier, is by taking the dockId and adding it as a class in the dom. That way you could write CSS against this and potentially do it on your own with CSS magic.

No no no no no.

I did realize as soon as I typed that, that you could use an id selector and affectively grab the container anyway. However I am curious, why is this a bad idea?

To piggyback on this

It would be nice to grab current configuration for a dock, store it in some way, then reset the dock back to it’s old configuration without having to worry about how it was configured.
(or even add a system.perspective.resetDock)

I also wish there was an addDock equivalent. We don’t have a west docked view and I had to add an empty dock so I could have the required dockId parameter for alterDock to function. Seems silly to add a dock to all pages just so I can use a dock to one page
^ I realize this could be done with Page Configuration to add a dock to one page, but we auto-generate nav based on the windows in the project + a window parameter so we only have the one page configuration

There are already loads of classes in play throughout components, themes, and Named Styles; arbitrarily listing dock ids as class names is just asking to force an existing project’s styles onto a docked view just because of an unexpected shared name between the named style and dock id.

Wouldn’t this just be done in a same way to the psc-style scheme? Something like dock-myDockId? That would remove any potential for overlap?

Unfortunately while it looks like this is possible, due to the design and layout of the single page app that its all wrapped in, even if you auto-hide or auto-show the docked view, you just end up with a white box behind it.

And ideas @victordcq?

Breakpoint containers in perspective seem to be coded in js instead of css.
Making it though to edit with css.

But you could do something with @media (breakpoints in css) and the new css feature :has
Relying on :has might be a bit to early to use on the field tho :stuck_out_tongue: Unless you can force your clients to update and use chrome/edga/safari

example where i put a style named hideDockWhenSmall on the docks

@media  (max-width: 750px){
    .client-root:has(.psc-hideDockWhenSmall) .docked-view-left{
        display: none !important;
    .client-root:has(.psc-hideDockWhenSmall) .center.view-parent {
        margin:unset !important;
        max-width:unset !important

@media  (min-width: 750px){
    .client-root:has(.psc-hideDockWhenSmall) .docked-view-bottom{
        display: none !important;
    .client-root:has(.psc-hideDockWhenSmall) .docked-view-left{
        height:100% !important;
    .client-root:has(.psc-hideDockWhenSmall) .center.view-parent {
        margin-bottom: 0 !important;
        max-height:unset !important;

small bp

large bp

and without the css it looked like this

1 Like

Man I bet you were pumped to get to prove out an example with :has :joy:

Question: It is hiding some of the bottom of the main view when the dock is hidden. Any ideas what’s causing this?

Visible (Note trend chart options at bottom of component)

Hidden (Note trend chart options are now hidden/require scrolling)

yes xD

Do you have any other docks? / is that purple a margin?

can i get your setup, to test out

Everyone should find something they love as much as Victor loves css.


No other docks, and the purple is just the background for the responsive design mode in safari (F12 in chrome)

I don’t have my laptop on me but I just took your CSS and put it directly into the light theme (lazily) and then have 2 views. 1 footer view and one main view with the chart, no customizations other than background color and the style class you sent

When I’m at my laptop I can export and share

Here is the project
Testing_20220930151544.zip (12.1 KB)

The css is just in its own file called custom.css and then in the light index I just imported it directly for testing purposes. The CSS is just a copy and paste of what you provided

What's interesting, is that it only happens with an power chart. No other component I have tried has this problem? @cmallonee I know this is likely an unsupported way of hiding the docked view, but any idea why the power chart specifically gets pushed below the bottom of the frame like that?

I'm not able to replicate with just the provided export, which means it's likely due to the CSS you're using. I'm not in a position where I can easily deploy and investigate a scenario which would require modification of the theming files, so all I can point you to over the next several hours is to investigate the DOM in order to see why the Chart is taking up extra vertical space. I might have some time later in the day to investigate further.

1 Like

Interestingly, also only happens in safari. This works as expected in chrome!

I still don't see it in Safari.