One small css change does make it all better... e107_themes/bootstrap3/admin_style.css

[Alex-e107nl]

@e107help i really do not know if you can see this but it is so annoying, i did spend ours and ours to change the bootstrap 3 admin theme a few years ago and it got accepted, i completely made it in e107 style but, there was one error in it that irritates me since it was used.... and it was not mine... Please change this in the css:

e107_themes/bootstrap3/admin_style.css starting at line 2117.

   .navbar-nav .open .dropdown-menu {
    position: fixed;
    top:100px;
    left:0;
    right: auto;
    width: calc(100vw);
    background-color: #212121;
    border: 0;
    box-shadow: inherit;
    box-shadow: 0 5px 10px rgba(0, 0, 0, 0.5);

    height: calc(100vh - 105px);
    overflow-y: scroll;
	padding-bottom:15px;
  }

To:

  .navbar-nav .open .dropdown-menu {
    position: fixed;
    top:51px;
    left:0;
    right: auto;
    width: calc(100vw);
    background-color: #212121;
    border-top: 1px solid rgba(255,255,255,.2);
    box-shadow: inherit;
    box-shadow: 0 5px 10px rgba(0, 0, 0, 0.5);
    height: calc(100vh - 105px);
    overflow-y: scroll;
    padding-bottom:15px;
  }

I don't need it myself anymore, but I can imagine that anyone looking at it in the admin screen of a standard e107 thinks, "Couldn't that have been done better?", and the answer is yes :-)

[rica-carv]

@Alex-e107nl Err, where is that css applied?
I'm using the default admn theme and i don't see that css applied anywhere...

[e107help[bot]]

@rica-carv The instinct is right and there is a way to get it, though not by branching. The ask first, since it is the part I cannot do from here: if either of you has the admin open in a narrow window, paste these two rules into devtools and say what you get. If they hold up on a real screen I will write it up.

@media only screen and (max-width : 768px) {
  .navbar-nav .open { position: static; }

  .navbar-nav .open .dropdown-menu {
    position: absolute;
    top: 100%;
    bottom: calc(100% - 100vh + 5px);
    height: auto;
    left: 0;
    width: 100vw;
    /* background-color, border, box-shadow, overflow-y and padding-bottom unchanged */
  }
}

Why that removes the number instead of branching it. I know of nothing in CSS that can see the wrap: no selector for "the icon row went to a second line", no media query for it, and the one feature that comes close, a container query on the header's height, needs container-type: size on the header, which stops the header being sized by its own contents. That is the exact thing being measured, so it cancels itself out. If you know of a way I have missed, I would like to see it.

What CSS can do is stop writing the number down at all. Stock Bootstrap 3 already drops a menu at the bottom edge of its containing block (.dropdown-menu{position:absolute;top:100%;left:0}), and .nav>li{position:relative} is what makes that containing block the menu item rather than anything larger, both in bootstrap.min.css. The theme overrides both at this breakpoint and re-anchors the panel to the viewport with position: fixed (admin_style.css#L2117-L2131). Once it is anchored there somebody has to type a number, and 100 is that number.

Take the open item out of the chain with position: static and the containing block becomes .navbar-fixed-top itself, which is position: fixed; left: 0; right: 0, so top: 100% is the bottom edge of the header, one row or two. The bottom line then does the job height: calc(100vh - 105px) was doing: 100% there is the header height again, so the panel still finishes 5px above the bottom of the screen while its top moves with the header. Nothing changes while every menu is shut, because .open is on the item only while it is open.

The caveat, and it is why this is a comment and not a pull request: I traced it in the two stylesheets, I have not rendered it. That bottom leans on a percentage resolving against the header's own height, which I would rather watch happen than assume.

If it does hold up, it ends the disagreement rather than settling it: @Alex-e107nl gets no gap when the header is one row, and @rica-carv the panel never lands on the buttons when it is two. The border-top: 1px solid rgba(255,255,255,.2) is still its own decision, and the last word on a bundled theme is Deltik's whichever way this goes.

[rica-carv]

@e107help I've tested it directly in Firefox, and it's still equal as the original in e107 core....

[e107help[bot]]

@rica-carv "still equal as the original" is the pass, not the failure, and you need not spend another evening on it. Your screenshot from 27 August has top: 100px sitting right there in the styles panel, so you were testing the right stylesheet and the right rule. The menu you opened, the big one under the hamburger, is the one the two rules are meant to leave exactly as it is. My ask was the thing at fault: I never said which menu to open.

The case that changes is one of the small icon dropdowns in the header itself, the avatar or PT or the house, opened with the hamburger closed.

I stopped tracing this time and rendered it. Headless Chrome, a throwaway static page built from master's admin header markup (admin_template.php#L185-L226) with bootstrap, the skin css and admin_style.css at the SHA in those links, viewport 412px wide, measured through getBoundingClientRect() rather than eyeballed:

what is open	header height	panel top now	gap now	panel top with the rules
avatar menu, hamburger closed	52px	100px	48px	51px
main menu, hamburger open	103px	100px	none	102px
avatar menu, hamburger closed, header wrapped to two rows	93px	100px	7px	92px

The first two rows as pictures. Left is master as it ships, right is the same page with the block below; the red band and the green line are drawn from the measured numbers rather than by eye, and the viewport is 412x915 in both, cropped to the top.

@Alex-e107nl's case, a header icon dropdown with the hamburger shut:

@rica-carv's case, the main menu with the hamburger open, which is the one that has to come out unchanged:

Same figures on Modern Dark, and the same at 360px. The panel top lands one pixel under the header height in every row because it anchors inside the header's 1px border; on screen the two edges meet.

That table is also me correcting myself. On 1 September I put the two header heights down to the icon buttons wrapping beside the brand. Wrapping is real, it is the third row, but it is not the main thing. The main thing is the hamburger: the entire admin menu lives in .navbar-collapse, which sits inside .navbar-fixed-top, so opening it makes the header a row taller. @Alex-e107nl opens an icon menu against a 52px header and sees 48px of page showing through. @rica-carv opens the main menu against a 103px header and sees it flush. One stylesheet, one number, two correct observations.

The measured 52px is also one pixel more than the 51 both of us have been quoting. 51 is the theme's own figure, but it is written for min-width: 1101px, and at the width this rule actually applies to, the navbar keeps a border on all four sides that it loses on desktop. Which is the whole argument in miniature: the right number is arguable even between two people reading the same stylesheet, so the fix is to stop writing one down.

@media only screen and (max-width : 768px) {
  .navbar-nav .open { position: static; }

  .navbar-nav .open .dropdown-menu {
    position: absolute;
    top: 100%;
    bottom: calc(100% - 100vh + 5px);
    left: 0;
    right: 0;
    width: auto;
    height: auto;
    /* background-color, box-shadow, overflow-y and padding-bottom unchanged */
  }
}

right: 0 rather than the width: 100vw I posted on 5 September, for that same border: measured against the header instead of the viewport, left: 0 starts a pixel in and 100vw then hangs a pixel off the right edge.

Alex, two things while you look at it. The rule is on master only, it arrived with b4907e53f and never went to release/v2.3.x, so nothing needs porting. And your border-top: 1px solid rgba(255,255,255,.2) is still its own question, worth more now than before: a hairline earns its keep between two touching edges in a way it never did across a 48px gap. Say the word and I will measure that too.

What my page cannot tell me is what a real install renders: which header buttons your sites actually show, what a plugin's admin CSS does to the navbar, what a non-default admin theme does with any of it. If either of you drops the block in and gets something that is not in that table, I would much rather hear it. I will push the branch and open a pull request so there is a diff to argue with, and whether it ships in a bundled theme is Deltik's call either way.

[e107help[bot]]

There is a diff to argue with now: #6284.

@Alex-e107nl, one thing in it is a reversal on my part. I twice called your border-top: 1px solid rgba(255,255,255,.2) a separate question to be decided on its own, and that was wrong. Once the panel meets the header there is nothing between them, and a percentage offset resolves against the navbar's padding box, so the panel's first pixel row lands on the header's own bottom border and repaints it. Five of the six locally shipped admin skins draw a border there, and Modern Dark 2's is a deliberate 2px black rule. Without a hairline the change does not move a seam, it deletes one. So it is in the diff. What the mechanics settle is that there has to be a seam, not that it has to be that one, and dropping the declaration is a clean revert of just that point for anyone who would rather not have a light rule on every skin.

It needed one line more than you asked for. The skins clip the panel's background to its padding box, so a 20% white border composites over whatever lies behind the panel rather than over the panel itself. On kadmin, the only skin whose navbar has no bottom border, that is the page content, and the seam would have changed colour as the page did. background-clip: border-box pins it at 77,77,77 on all nine skins the theme can load.

@rica-carv, the shape of the fix is yours. When you said it could be 51 with no icon row and 100 with one, and that CSS is smart enough to handle that, that is what sent me looking for a rule that stops writing the number down at all. Alex's top: 51px on its own would have broken the case you were defending, and the branch does not, which is why your case is in the pull request as the second screenshot rather than as a footnote.

Both comparisons are now on the 6 September comment as well, so the pictures sit next to the numbers they came from. The red band is the measured gap, not a drawn one.

Something else fell out of the measuring, unrelated to either of you: {ADMIN_UPDATE} ships its dropdown already open, so on a narrow screen a site with a pending core update carries a full-height panel over the admin page from the moment it loads. One tap dismisses it and the next page brings it back. That is #6283, filed separately, because the fix belongs in the shortcode rather than in this stylesheet.

Whether any of it ships in a bundled theme is Deltik's, and the hairline is the part with the widest reach: it changes how the admin looks on every skin, not only where the bug was.