/* Readability/operability override for Django admin, scoped to this project
   only. The real admin user is the 86-year-old artist himself, so this file
   only enlarges text, click targets and input sizing -- it never changes
   colors, contrast, dark-mode variables, or Django's own admin structure.
   Loaded after the default admin stylesheet via templates/admin/base_site.html's
   extrastyle block, so equal-specificity selectors here win the cascade.

   Every selector below is copied from (or matched in specificity to) the
   real rule in staticfiles/admin/css/{base,forms,changelists,responsive,
   login}.css that hardcodes a small size directly on that element -- those
   never inherit the larger `body` size and need at least equal specificity
   to actually change. Elements with no such hardcoded size already inherit
   the bumped `body` size for free and are intentionally left alone. */

body {
    font-size: 16px;
    line-height: 1.5;
}

/* Top bar / breadcrumbs. #site-name (the site header title, restored by
   base_site.html correctly extending admin/base_site.html) is already
   1.5rem/24px by default, so it is intentionally left untouched here. */
#header {
    font-size: 16px;
    padding: 18px 40px;
}
#user-tools, #logout-form button {
    font-size: 15px;
}
/* This used to be enlarged/bolded (18px/600) specifically to compensate
   for the change form's object identity having no element of its own --
   it was only reachable as the breadcrumb's trailing text. That's no
   longer true: admin/includes/title_row_changeform.html now renders
   {{ original }} in its own `.admin-object-title` (18px/600, see below)
   directly under the page heading, so the breadcrumb no longer needs to
   carry that job and can go back to reading as ordinary secondary
   navigation. No color is set here; the existing
   --breadcrumbs-fg/--breadcrumbs-link-fg variables already keep contrast
   correct in both themes. */
div.breadcrumbs {
    padding: 14px 40px;
    font-size: 15px;
    font-weight: 500;
}

/* Left sidebar vs. right content: both default to the same var(--body-bg),
   so the two areas read as one flat surface. #nav-sidebar already has
   `border-right: 1px solid var(--hairline-color)` in Django's own
   nav_sidebar.css -- restated here only so the boundary stays guaranteed
   even if that rule ever changes -- and only its background is actually
   new. var(--darkened-bg) is Django's own "a bit darker than --body-bg"
   panel tone (already used for .module h2, #toolbar, .submit-row, etc.),
   confirmed subtle in both themes: #f8f8f8 on #fff in light mode, and
   #212121 (lighter than the #121212 page background, i.e. a raised panel)
   in dark mode -- never a loud, competing color. --selected-row (the
   active app/model highlight) is #ffc in light mode and #00363a in dark
   mode, both a distinct hue from --darkened-bg, so the current selection
   stays visible without any extra contrast tweak. App section headers
   (font-size, color) and sidebar width are untouched. Each app's own box
   is a `.module` with its own `background: var(--body-bg)` (base.css),
   which would otherwise paint over most of the sidebar and leave only the
   thin gaps between app boxes tinted -- so it's retinted too, scoped to
   the sidebar via the #nav-sidebar ancestor, leaving modules elsewhere
   (e.g. the index page's "Recent actions") unaffected. */
#nav-sidebar {
    background-color: var(--darkened-bg);
    border-right: 1px solid var(--hairline-color);
}
#nav-sidebar .module {
    background-color: var(--darkened-bg);
}
/* Sidebar row height: Django's generic `td, th { padding: 8px; }` already
   gives some breathing room; nudged up by 1px top/bottom only, now that the
   add-link inside is bigger, without letting the sidebar grow much taller. */
#nav-sidebar .module th, #nav-sidebar .module td {
    padding: 9px 8px;
}

/* "+ 추가" links in the sidebar's per-app model lists. Django's own
   `.addlink { padding-left: 16px; background: url(...) 0 1px no-repeat; }`
   sets no font-size/color/weight of its own, so it was inheriting the
   generic `td, th { font-size: 0.8125rem; }` (13px) -- smaller than this
   project's 16px body text and easy to miss. Left-padding is kept at/above
   the original 16px so the "+" icon still has room; the rest is widened
   for a bigger click target. Color intentionally keeps the existing
   var(--link-fg) (the same blue as every other admin link, not the plus
   icon's own green artwork, which is a background image and can't be
   recolored from here) and leans on weight instead, per "완전히 다른
   색으로 바꿀 필요는 없다". */
#nav-sidebar .addlink {
    display: inline-block;
    font-size: 15px;
    font-weight: 600;
    color: var(--link-fg);
    padding: 6px 10px 6px 20px;
}
#nav-sidebar .addlink:hover, #nav-sidebar .addlink:focus {
    /* Underline as the primary cue (not color/background alone), plus the
       sidebar's own --selected-bg as a subtle secondary highlight. */
    text-decoration: underline;
    background-color: var(--selected-bg);
}

/* Page headings */
.dashboard #content h1, #content > h1,
.change-form #content h1, .change-list #content h1 {
    font-size: 26px;
}
.module h2, .module caption, .inline-group h2 {
    font-size: 20px;
    padding: 10px 12px;
}
#changelist-filter h2 {
    font-size: 16px;
}

/* Form rows, labels, help text. Django's own `.form-row { padding: 10px; }`
   is uniform on all sides, so the override keeps >=10px left/right instead
   of zeroing it -- fields must not sit flush against the fieldset edge. */
.form-row {
    font-size: 16px;
    padding: 8px 10px;
}
.form-row label, fieldset .form-row label, .aligned label, .vCheckboxLabel {
    font-size: 16px;
    line-height: 1.5;
}
.help, p.help, form p.help, div.help, form div.help, div.help li, .helptext {
    font-size: 14px;
}

/* Text/number/date inputs, selects and textareas: the default admin rule
   (input, textarea, select { font-size: 0.8125rem; padding: 2px 3px; })
   packs these very tight, so every real input type is targeted explicitly
   to beat that rule's specificity rather than relying on cascade order. */
input[type="text"], input[type="password"], input[type="email"],
input[type="url"], input[type="number"], input[type="tel"],
input[type="search"], input[type="date"], input[type="datetime-local"],
input[type="time"], textarea, select {
    font-size: 16px;
    padding: 5px 8px;
    min-height: 36px;
}
/* Shorter than the previous 120px so an empty textarea (artwork description,
   biography, ...) doesn't dominate the first screen; still tall enough to
   show several lines up front. Resize is left alone (Django sets none), so
   the field stays user-resizable for genuinely long text. */
textarea {
    min-height: 88px;
}

/* Checkboxes/radios render at the browser's tiny native size by default. */
input[type="checkbox"], input[type="radio"] {
    width: 20px;
    height: 20px;
    vertical-align: middle;
}

/* Buttons and button-styled links */
.button, input[type="submit"], input[type="button"], .submit-row input,
a.button {
    font-size: 16px;
    padding: 8px 14px;
    min-height: 40px;
    line-height: 1.4;
}
.submit-row {
    padding: 16px;
}

/* Object tools ("히스토리" etc., top-right of change/changelist pages).
   Previously folded into the generic button rule above via a plain
   `.object-tools a` selector, but Django's own color/size rule is
   `.object-tools a:link, .object-tools a:visited` -- a pseudo-class counts
   like a class for specificity, so that rule is (0,2,1) versus the generic
   rule's (0,1,1), meaning Django's smaller 0.6875rem/11px text and drab
   var(--close-button-bg) gray were winning regardless of cascade order.
   Only min-height (never set by Django here) was actually taking effect,
   which is exactly the "too-small text inside an odd-sized pill" look
   being fixed now with a selector that actually matches. */
.object-tools a:link, .object-tools a:visited {
    font-size: 16px;
    font-weight: 500;
    padding: 8px 14px;
    min-height: 40px;
    /* Deterministic vertical centering instead of relying on font metrics/
       line-height, so text can't drift up or down as size changes. */
    display: flex;
    align-items: center;
    justify-content: center;
    box-sizing: border-box;
    /* --secondary is the same blue as the header bar and the primary
       save/submit buttons (--button-bg is literally var(--secondary)) --
       reused here instead of the flatter var(--primary) because a quick
       contrast check shows var(--primary) (#79aec8, light blue) is too
       pale under white text to stay reliably readable, while --secondary
       is Django's own already-verified pairing with --button-fg. The
       existing pill shape (border-radius: 15px, from base.css) and this
       toolbar's smaller size/top-right position -- not a different hue --
       are what keep it visually distinct from the full-width save button. */
    background: var(--secondary);
    color: var(--button-fg);
}
.object-tools a:focus, .object-tools a:hover {
    /* var(--button-hover-bg) is --secondary's own existing hover shade, so
       hovering/focusing darkens exactly the way the save button already
       does, rather than introducing a new state color. */
    background-color: var(--button-hover-bg);
}
/* "View on site" / "Add" object-tools buttons reserve extra right-side
   padding in Django's own CSS for their background-image icon; the
   shorthand `padding: 8px 14px` above would otherwise quietly win (same
   0,2,1 specificity, later in the cascade) and shrink that gap to 14px,
   crowding the icon against the text. Restated at Django's own 26px. */
.object-tools a.viewsitelink, .object-tools a.addlink {
    padding-right: 26px;
}
.object-tools li {
    /* Django fixes this at 1rem/16px, shorter than the enlarged link above;
       auto lets the row grow to fit it instead of the link visually
       overflowing its own list item. */
    height: auto;
}
.object-tools {
    /* Compensates for the link's height growing from ~22px (11px text,
       1.5 line-height, 3px+3px padding) to a deterministic 40px -- the
       block needs to sit that much less far above its normal flow position
       to still land beside the (also enlarged, 26px) page heading. This is
       a calculated estimate, not something rendered and checked pixel by
       pixel in a live browser this session; please confirm visually and
       nudge this value if the toolbar reads high/low against the heading. */
    margin-top: -30px;
}

/* changeform "히스토리" position. Earlier rounds tried nudging
   .object-tools sideways with pure CSS (margin-right, then translateX)
   -- both reverted after real-browser regressions, because Django's
   default markup makes <h1> and .object-tools distant relatives, not
   siblings, and a nudge can't fix that. The next round fixed it
   structurally by making them flex siblings in one title row
   (`.admin-page-title-row`, now retired) -- workable, but it put the
   history button beside the *page* title ("소식/전시 변경") rather than
   beside the specific object being edited ("전시 · 테스트 전시"), and
   the object name itself had no visual weight of its own.
   This round drops the title row entirely: <h1> is back to Django's
   plain, unmodified default (no override at all in
   admin/{app_label}/change_form.html any more). Instead,
   admin/includes/title_row_changeform.html now overrides the
   `content_subtitle` block -- Django's own `{% if subtitle %}
   <h2>{{ subtitle }}</h2>{% endif %}`, one level up from #content-main,
   right after <h1> -- reusing Django's own `subtitle` context var
   (str(obj), the same string `original` resolves to) instead of a
   second, separately-sourced element, which is what fixes a real
   duplicate-object-name bug an earlier version of this file had.
   `.admin-object-row` renders there: the object identity on the left,
   the "히스토리" button on the right. #content-main has no narrower
   max-width of its own in this project (checked against forms.css/
   base.css) and neither does #content, so this row's width is identical
   whether it sits one level up (its current position) or inside
   #content-main (its previous one) -- it cannot drift toward the
   viewport edge the way a *page*-width row could either way. */
.admin-object-row {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 1rem;
    margin-bottom: 14px;
    padding-bottom: 14px;
    border-bottom: 1px solid var(--hairline-color);
}
.admin-object-title {
    font-size: 18px;
    font-weight: 600;
    line-height: 1.4;
    color: var(--body-fg);
}
.admin-object-actions {
    /* Prevents the actions column from being told to shrink below its
       content by justify-content: space-between on narrow flex-basis
       calculations -- keeps the button's own padding/min-height intact
       instead of letting flexbox compress it. */
    flex: 0 0 auto;
}
.admin-object-row .object-tools {
    /* float: right (inert inside a flex item per spec anyway) and this
       file's own margin-top: -30px above (a compensation for Django's
       *default* floated position, meaningless here and enough to pull
       the button visually above the row) are both neutralized so the
       flex row's own alignment is the only thing positioning it. */
    float: none;
    margin: 0;
}
@media (max-width: 1024px) {
    /* Same breakpoint as responsive.css's own tablet cutoff, so this
       stays in lockstep with -- rather than fighting -- Django's
       existing responsive behavior below it. Wrapping instead of
       compressing keeps the object title from being clipped and the
       button at its full 40px/16px size instead of shrinking either to
       fit one line. */
    .admin-object-row {
        flex-wrap: wrap;
    }
}

/* changelist command row: an earlier version of this rule
   (`.admin-list-actions`) gave the "추가" button its own dedicated row
   above the results table -- visually correct but it cost a whole extra
   line versus just sharing the existing bulk-actions row (the one with
   the action <select>, the "실행"/Go button and the selection-count
   text). Replaced: admin/{app_label}/change_list.html now overrides
   `result_list` to render admin/includes/list_command_row.html (see
   that file) instead, which puts Django's own `.actions` div (rendered
   by the public {% admin_actions %} tag, untouched/un-rewritten) and a
   second `<ul class="object-tools">` (rendered by
   {% change_list_object_tools %}, also untouched) as two flex siblings
   on one row. `.admin-list-bulk-actions` is *always* rendered as a real
   element (its {% admin_actions %} call is the only thing gated by
   `actions_on_top`, not the wrapper div itself) specifically so
   `justify-content: space-between` always has two flex children to work
   with -- if the left div vanished whenever a ModelAdmin has
   actions_on_top=False, `space-between` would have only the button left
   and would pin it to the *left* edge instead, the opposite of what is
   wanted. An empty div renders no visible box (no padding/border set on
   it), so nothing looks different when there is nothing to show there.
   This include sits inside `.changelist-form-container`
   (changelists.css), the flex sibling of `#changelist-filter` within
   `#changelist`'s own `display: flex; justify-content: space-between`
   -- so the whole row shares the results table's column width, not the
   page width, and cannot reach into the filter column; they are
   different flex children, not a computed offset. */
.admin-list-command-row {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 1rem;
}
.admin-list-bulk-actions {
    /* Lets Django's own `#changelist .actions { width: 100% }`
       (changelists.css) resolve against this flex item's box rather
       than the whole row, and gives it the row's spare width so the
       button doesn't get pushed around as the selection-count text
       grows/shrinks. */
    flex: 1 1 auto;
    min-width: 0;
}
.admin-list-create-action {
    flex: 0 0 auto;
}
.admin-list-create-action .object-tools {
    /* Same two resets as `.admin-object-row .object-tools` below,
       same reason: Django's own .object-tools ships float: right, and
       this file's margin-top: -30px further up is a float-era
       compensation with no meaning for a flex child here. */
    float: none;
    margin: 0;
}
@media (max-width: 1024px) {
    /* Wrap rather than compress: on a narrow screen the action <select>
       plus the "추가" button can legitimately need more width than the
       viewport gives the row, and shrinking either one (rather than
       letting the row grow to two lines) would either clip the select
       or shrink the add button below its own 40px/16px floor. Stacking
       keeps both at full, correct size; `align-self: flex-start` stops
       the already-block-width bulk-actions item above it from stretching
       the button to match via the row's default `align-items: center`. */
    .admin-list-command-row {
        flex-wrap: wrap;
    }
    .admin-list-create-action {
        align-self: flex-start;
    }
}

/* Changelist result table. A previous version of this comment claimed
   these cells had no hardcoded font-size in Django's own CSS and so
   already inherited the bumped `body` size -- that was never actually
   checked in a browser and was wrong: base.css sets a blanket
   `td, th { font-size: 0.8125rem }` (13px) by tag selector, and nothing
   in this file had contested it for changelist cells specifically, so
   real rendering stayed stuck at 13px. Fixed here with an explicit,
   higher-specificity rule. Header/body links (column sort links, the
   row link to each object) are listed too even though they would
   inherit from their th/td by default, so the size is guaranteed
   regardless of any nesting (Django wraps sortable header text as
   `th .text a`) rather than left to inheritance. Row padding (10px 10px)
   is left as-is per instruction -- only the text is enlarged this
   round. */
#changelist table tbody th, #changelist table tbody td,
#changelist table thead th {
    padding: 10px 10px;
}
#changelist table thead th, #changelist table thead th a {
    font-size: 15px;
    font-weight: 600;
}
#changelist table tbody th, #changelist table tbody td,
#changelist table tbody th a, #changelist table tbody td a {
    font-size: 15px;
}
/* Filter column: #changelist-filter h2/h3/li/a have no hardcoded
   font-size of their own in Django's CSS (unlike the table cells above),
   so they already inherit this file's 16px `body` size -- the one
   exception is the small "Hide/show counts" / "Clear all filters" row,
   which changelists.css pins to 0.8125rem (13px). Nudged to 14px only,
   since this session's actual target is the table, not the filter. */
#changelist-filter #changelist-filter-extra-actions {
    font-size: 14px;
}
#toolbar #searchbar {
    font-size: 16px;
    min-height: 38px;
    padding: 6px 9px;
}
#toolbar form input[type="submit"] {
    font-size: 16px;
    padding: 8px 14px;
    min-height: 40px;
}
#changelist .actions select {
    font-size: 16px;
    min-height: 38px;
}
#changelist .actions .button {
    font-size: 16px;
    padding: 8px 14px;
    min-height: 40px;
    height: auto;
}
.paginator {
    font-size: 15px;
    padding: 12px 0;
}

/* Errors: bumped to match .errornote's existing 0.875rem/14px for a
   consistent, still-legible error message size. */
.errorlist, ul.errorlist li, .errornote {
    font-size: 14px;
}
/* Only the size changes here; padding/background (incl. the status icon's
   fixed 40px offset) stay untouched so the icon keeps lining up with the text. */
ul.messagelist li {
    font-size: 15px;
}

/* Inline formsets (tabular) */
.inline-group .tabular td, .inline-group .tabular th {
    font-size: 15px;
    padding: 8px;
}

/* Login screen: `.login .form-row` and the username/password fields have
   their own hardcoded, smaller rules in login.css, so the desktop rules
   above never reach them. Box structure/width/colors are left untouched. */
.login .form-row {
    padding: 7px 0;
}
.login .form-row #id_username, .login .form-row #id_password {
    font-size: 16px;
    min-height: 36px;
    padding: 5px 8px;
}

/* <=1024px: responsive.css re-shrinks these same inputs to a 2.25rem/36px
   min-height (and drops font-size to 1rem/16px, which already matches
   ours), which now happens to match the desktop floor above -- restated
   here anyway with the same selector so padding also stays 5px 8px instead
   of Django's own 6px 8px at this breakpoint. Textarea is listed separately
   so it follows the 88px desktop value instead of also being pulled to 36px. */
@media (max-width: 1024px) {
    .form-row input[type="text"],
    .form-row input[type="password"],
    .form-row input[type="email"],
    .form-row input[type="url"],
    .form-row input[type="number"],
    .form-row input[type="search"],
    .form-row select {
        min-height: 36px;
        padding: 5px 8px;
    }
    .form-row textarea {
        min-height: 88px;
    }
}