/*
   VL Styles 
*/

/*a[href^="https://"] {*/
/*    background: url(/img/vl_external.svg) center right no-repeat;*/
/*    padding-right: 13px;*/
/*}*/
/*a[href^="http://"] {*/
/*    background: url(/img/vl_external.svg) center right no-repeat;*/
/*    padding-right: 13px;*/
/*}*/

a.external {
    background: url(/img/vl_external.svg) center right no-repeat;
    padding-right: 13px;
}

.highlight-expiry {
    background-color: #ffcccc !important; /* or any other styling you prefer */
}

.pagination {
    /*text-align: center;*/
    text-align: left;
    margin: 20px 0;
}

.pagination .step-links {
    display: inline-block;
    padding: 10px;
    border: 1px solid #ddd;
    border-radius: 4px;
    background-color: #f5f5f5;
}

.pagination .step-links a {
    margin: 0 5px;
    padding: 5px 10px;
    border-radius: 4px;
    background-color: #e6e6e6;
    color: #333;
    text-decoration: none;
    transition: background-color 0.2s ease;
}

.pagination .step-links a:hover {
    background-color: #ccc;
}

.pagination .step-links .current {
    font-weight: bold;
    margin: 0 5px;
}

/*
   django-admin-interface: give the date/time picker its size back.

   Django builds the picker as `<div class="calendarbox module">` (and
   `<div class="clockbox module">`) in admin/js/admin/DateTimeShortcuts.js, and
   sizes it with `.calendarbox, .clockbox { width: 19em }` in admin/css/widgets.css.

   The theme's modules.css then says `.admin-interface .module { width: 100% }`.
   Two classes against one, so it wins on specificity no matter what order the
   stylesheets load in, and the picker stretches to fill the form column —
   several times its intended width, with the day cells spread across it.

   Nothing here can be fixed by load order, which is why this is a rule rather
   than a reshuffle. Matching the theme's specificity and coming later is what
   settles it. Scoped to `.admin-interface` so a deployment not running the
   theme is untouched.

   Upstream bug, not ours: it lands on any admin page with a date field on any
   deployment with ADMIN_THEME on, which today is move. Remove this block when
   django-admin-interface stops setting a width on `.module` — lib.test_admin_theme
   fails when that happens, rather than leaving it here forever.
*/
.admin-interface .calendarbox,
.admin-interface .clockbox {
    width: 19em;
}

/* The document-batch progress overlay (admin/js/doc_progress.js).

   A native <dialog>, so focus trapping and the backdrop come from the browser
   rather than from a z-index fight with django-admin-interface's sticky header.

   Nothing here names a colour of its own. The overlay borrows the deployment's
   own accent through a fallback chain, because the two deployments do not agree
   on one: move runs django-admin-interface with a lilac theme and publishes
   --admin-interface-save-button-*, Vector runs the stock admin (the theme apps
   are conditional on ADMIN_THEME, so those variables are simply undefined there)
   and publishes Django's --default-button-bg. The literal at the end of the
   chain is only reached if both are missing.

   The progress bar mattered most: a bare <progress> is painted in the operating
   system's accent colour, which is a bright blue on macOS and sits badly against
   Django's slate and worse against move's lilac. `accent-color` retints the
   native widget without reaching for vendor pseudo-elements.

   Declared on `body`, and that is load-bearing rather than arbitrary.
   django-admin-interface writes its variables under `:root .admin-interface`,
   and `admin-interface` is a *body* class — so a custom property declared on
   `:root` resolves its var() against the html element, where those names do not
   exist, and would quietly fall through to the Django default on the one
   deployment that has a theme. The dialog is appended to document.body, so it
   inherits from here. */
body {
    --erp-doc-accent: var(--admin-interface-save-button-background-color,
                      var(--default-button-bg, var(--button-bg, #205067)));
    --erp-doc-accent-fg: var(--admin-interface-save-button-text-color,
                         var(--button-fg, #fff));
}

dialog.erp-doc-dialog {
    border: none;
    border-radius: var(--admin-interface-module-border-radius, 6px);
    padding: 1.6em 2em;
    min-width: 24em;
    max-width: 42em;
    color: var(--body-fg, #333);
    background: var(--body-bg, #fff);
    box-shadow: 0 6px 28px rgba(0, 0, 0, .3);
}

dialog.erp-doc-dialog::backdrop {
    background: rgba(0, 0, 0, .45);
}

.erp-doc-title {
    margin: 0 0 .8em;
    font-size: 1.1em;
    font-weight: 600;
    color: var(--admin-interface-title-color, var(--body-loud-color, #000));
}

.erp-doc-bar {
    width: 100%;
    height: 1em;
    accent-color: var(--erp-doc-accent);
}

.erp-doc-status {
    margin: .5em 0 0;
    font-variant-numeric: tabular-nums;
    color: var(--body-quiet-color, #666);
}

.erp-doc-errors {
    margin: .8em 0 0;
    padding-left: 1.2em;
    max-height: 12em;
    overflow-y: auto;
    color: var(--error-fg, #ba2121);
}

.erp-doc-errors:empty {
    display: none;
}

.erp-doc-actions {
    margin-top: 1.2em;
    display: flex;
    gap: .8em;
    align-items: center;
}

/* The buttons carry the admin's own `button` class, so their shape is whatever
   the deployment gives every other button. Only the primary is repainted, and
   only because Django themes `.default` for the submit row rather than for a
   button standing on its own. */
.erp-doc-actions .default {
    background: var(--erp-doc-accent);
    color: var(--erp-doc-accent-fg);
}