.sp-dashboard .noItemsRow .filename {
    width: 100%;
    padding: 44px 20px;
    text-align: center;
    color: var(--sp-text-muted);
    background-color: transparent;
}

/* =============================================
   THE REMAINING BUTTON CLASSES

   Found by enumerating every class containing "btn" across the account templates
   and BaseFileManager, then checking each against these stylesheets. Twenty one
   were uncovered. The brand social buttons are excluded on purpose, because their
   colour is what identifies them, and btn-group and btn-toolbar are layout with no
   colour to fix.

   The one that mattered: bootstrap.css line 2939 gives .btn-white a #ffffff
   background with #303641 text, and BaseFileManager uses `btn btn-white` for the
   reset and refresh controls and for every breadcrumb. Those were white buttons on
   a dark page from the start and I had never looked at the class.

   btn-green at bootstrap.css line 3301 is #00a651, a fixed green that belongs to
   no palette.
   ============================================= */
.sp-dashboard .btn-white,
.file-browse-container-wrapper .btn-white {
    background-color: var(--sp-bg-card-hover);
    border-color: var(--sp-border-color);
    color: var(--sp-text-primary);
}

.sp-dashboard .btn-white:hover,
.sp-dashboard .btn-white:focus,
.sp-dashboard .btn-white:active,
.file-browse-container-wrapper .btn-white:hover {
    background-color: var(--sp-bg-card);
    border-color: var(--sp-accent-primary);
    color: var(--sp-text-primary);
}

.sp-dashboard .btn-green,
.sp-dashboard .btn-secondary,
.sp-dashboard .btn--primary {
    background-color: var(--sp-accent-primary);
    border-color: var(--sp-accent-primary);
    color: #ffffff;
}

.sp-dashboard .btn-green:hover,
.sp-dashboard .btn-secondary:hover,
.sp-dashboard .btn--primary:hover {
    background-color: var(--sp-accent-primary);
    border-color: var(--sp-accent-primary);
    color: #ffffff;
    box-shadow: inset 0 0 0 999px rgba(255, 255, 255, 0.13);
}

/* Breadcrumbs are btn btn-white btn-breadcrumb, so the white rule above already
   carries them. Only the seam between segments needed stating. */
.sp-dashboard .btn-breadcrumb {
    border-color: var(--sp-border-color);
}






/* =============================================
   THE ACCOUNT BODY, GUARDED

   layout_auto loads the public theme.css into the account shell so the nested
   pages get the component rules their markup needs. That file carries
   `body { background: #ffffff }` at line 2729 and `body { color: #444 }` at line
   71, both at a specificity of one.

   Checked what comes after it: dashboard.css only ever styles descendants of
   body, `body.sp-dashboard .sidebar-menu` and `body.sp-dashboard .page-container`,
   and never the body background itself. So nothing was going to stop that white
   from applying, and the whole account page would have gone white behind the
   chrome the moment a nested page was opened.

   Stated here, in the file that loads last, at a specificity of 101 against
   their 1.
   ============================================= */
body.sp-dashboard,
body.page-body.sp-dashboard {
    background-color: var(--sp-bg-primary);
    color: var(--sp-text-primary);
}


/* =============================================
   THE THUMBNAIL PLATE

   custom.css line 379 sets

     .fileManagerIcon .fileListing .fileIconLi .thumbIcon {
         background: #f5f6fa url(../images/loading_small.gif) center center no-repeat;
     }

   at four classes. The rule for this in theme-coverage.css was written at three,
   so it lost, and that near white #f5f6fa stayed as the plate behind every
   thumbnail. It is the pale block visible around each image in the tile view.

   Matched at five classes here so it wins on merit. The loading indicator is kept,
   because it is what tells somebody a thumbnail is still being fetched, and only
   the colour underneath it changes.
   ============================================= */
.sp-dashboard .fileManagerIcon .fileListing .fileIconLi .thumbIcon,
.file-browse-container-wrapper .similar-images .slick-slider .slick-slide .thumbIcon {
    background-color: var(--sp-bg-card-hover);
    background-image: url(../images/loading_small.gif);
    background-position: center center;
    background-repeat: no-repeat;
}

/* Once an image has loaded the indicator underneath it is noise. */
.sp-dashboard .fileManagerIcon .fileListing .fileIconLi .thumbIcon.loaded,
.sp-dashboard .fileManagerIcon .fileListing .fileIconLi .thumbIcon:has(img[src]) {
    background-image: none;
}
/* =============================================
   THE FLYOUTS AT REST

   The pinned rule above only applies while an item is hovered. At rest the
   tooltip and the submenu keep dashboard.css line 488 and line 516, plus
   theme-enhancements.css line 595 and line 633, which place them at
   `left: 100%` with `margin-left: 10px`, outside a seventy pixel column.

   They are hidden at rest by opacity and visibility, and neither of those
   removes an element from layout, so both were still extending the sidebar's
   scrollable width whether or not anything was hovered. That is the sideways
   drag: the column could be pulled across because it genuinely was wider than
   itself.

   Held at the column edge while at rest, which costs nothing because they are
   not visible, and the pinned rule takes over the moment one is hovered. Matched
   at three compounds so it beats the important declaration at
   theme-enhancements.css line 633.
   ============================================= */
.sp-sidebar .sp-sidebar-tooltip:not(.is-pinned),
.sp-sidebar .sp-sidebar-submenu:not(.is-pinned) {
    left: 0 !important;
    margin-left: 0 !important;
}