/**
 * Small additions on top of base.css (pulled from the live pasvalia.lt,
 * see docs/old-cms-schema.md).
 *
 * base.css styles footer/mobile-nav links via a `.item` class on each <li>
 * (e.g. `.nav-footer .item{...}`). That class comes from the *old* CMS's
 * own template loop, which hand-wrote it on every <li>. Omeka's nav-menu
 * helper (Laminas\View\Helper\Navigation\Menu) doesn't add a generic class
 * to every <li> the same way -- only an "active"-state class is automatic,
 * everything else would have to come from per-page data our stored
 * navigation JSON doesn't carry. Rather than fight that, these rules
 * target the plain <li> structure Omeka actually renders, copied straight
 * from base.css's `.item` rules.
 */
.nav-footer-list > li {
    display: block;
    float: left;
    padding: 0 0 8px;
    width: 33%;
}
.nav-footer-list > li > a {
    color: #fff;
    font-size: 13px;
    text-decoration: none;
    white-space: nowrap;
}
.nav-footer-list > li.active > a,
.nav-footer-list > li > a:hover {
    text-decoration: underline;
}

.nav-mobile-list > li {
    border-top: 1px solid #745a3a;
    padding: 20px 30px;
}
.nav-mobile-list > li:hover,
.nav-mobile-list > li.active {
    background-color: #fff;
}
.nav-mobile-list > li > a {
    color: #fff;
    font-size: 18px;
    font-weight: 400;
    text-decoration: none;
}
.nav-mobile-list > li:hover > a,
.nav-mobile-list > li.active > a {
    color: #7d623f;
}

/**
 * REMOVED: this used to force `.block-timeline` into `float:left;width:58%;
 * margin-left:2%`, on the mistaken assumption that base.css never gives it
 * a matching float next to `.block-virtual-exhibition` (its sibling in
 * `.block-bottom`) and so needed one spelled out explicitly. Reported back
 * as a stray left margin on `.block-timeline` -- rereading base.css's own
 * rule for it explains why: `.block-timeline{height:442px;overflow:hidden;
 * width:auto}` already establishes a new block formatting context
 * (`overflow:hidden`), and a BFC'd `width:auto` block automatically shrinks
 * to fit the remaining space beside a *preceding* float with zero extra
 * margin needed -- a real, standard CSS technique, not an accident this
 * theme needed to route around. The `margin-left:2%` here was an invented
 * gap that doesn't exist on the real site at all; removing this whole rule
 * restores the actual real behavior. (Omeka's wrapper divs don't break
 * this either -- `.block-virtual-exhibition` and `.block-timeline` are
 * still plain DOM siblings, both direct children of one `.block-bottom`,
 * which is all this technique needs.)
 */

/**
 * Every homepage section sits inside an Omeka-generated `<div class="block
 * block-<layoutName>">` wrapper (`Omeka\View\Helper\PageLayout::render()`,
 * one per site-page block -- this project's homepage is a real Omeka site
 * page under the hood, blocks and all). Omeka core's own `page-blocks.css`
 * (loaded unconditionally by `omeka/site/page/show.phtml`, confirmed
 * directly: it's the very first stylesheet `<link>` on every page, ahead of
 * this theme's own) gives every one of those wrappers `margin:1rem 0`
 * (`.page-layout-normal .block{...}`) -- 32px of unrequested space above
 * *and* below every single section, stacking on top of this theme's own
 * already-tuned spacing between them (`.block-bottom{margin-bottom:20px}`,
 * `.block-map`'s own border, ...), which was written assuming no such
 * wrapper -- and margin, unlike the wrapper's own `style=""` attribute
 * (checked directly: always empty), Omeka's core CSS doesn't need our
 * markup's cooperation to apply. User-reported as "space that shouldn't be
 * there" around more than one section (the map, and between the
 * exhibitions/timeline block); this single rule was the real, shared cause
 * of all of it, not something specific to any one of them. Reset to 0 here
 * -- same selector, loaded after page-blocks.css (checked the actual
 * `<link>` order directly), so this wins on equal specificity without
 * needing `!important`.
 */
.page-layout-normal .block {
    margin: 0;
}

/**
 * Flash messages (`$this->messages()` in layout.phtml) -- most notably
 * the discussion-comment form's own success/error notices. Not an old
 * CMS feature (that used a redirect-and-inline-flashdata pattern with its
 * own bespoke markup, never a generic list like this), and base.css has
 * no rules for it at all -- styled plainly to fit the rest of the site
 * rather than pulled from a page that doesn't exist on the real site.
 */
.messages {
    list-style: none;
    margin: 0 0 20px;
    padding: 0;
}
.messages li {
    border-radius: 5px;
    font-size: 14px;
    margin-bottom: 10px;
    padding: 12px 16px;
}
.messages li.success {
    background-color: #e6f4ea;
    color: #256029;
}
.messages li.error {
    background-color: #fdecea;
    color: #b3261e;
}
.messages li.warning,
.messages li.notice {
    background-color: #fff8e1;
    color: #7d623f;
}

/**
 * /expo (Virtualios parodos) listing -- see expo/site/index/browse.phtml's
 * own comment for what this reproduces and what it deliberately doesn't.
 * No rules for this anywhere in base.css (checked directly): the real
 * page this reproduces is a separate, older, unstyled sub-app, not part
 * of that stylesheet's own site at all. Colors/spacing follow this
 * theme's own existing conventions instead (`.wysiwyg`'s body-text color,
 * `.block-header.brown`'s brown) rather than the real page's own,
 * unrelated pre-redesign CSS.
 */
.expo-browse {
    padding: 30px;
}
.expo-browse-list {
    float: left;
    width: 58%;
}
.expo-browse-side {
    float: right;
    width: 38%;
}
.expo-browse-side img {
    max-width: 100%;
}
.expo-list {
    list-style: none;
    margin: 0;
    padding: 0;
}
.expo-list li {
    border-bottom: 1px solid #ebebeb;
    padding: 10px 0;
}
.expo-list li:first-child {
    padding-top: 0;
}
.expo-list a {
    color: #595959;
    font-size: 15px;
    text-decoration: none;
}
.expo-list a:hover {
    color: #7d613e;
    text-decoration: underline;
}
.expo-archive-toggle {
    color: #7d613e;
    cursor: pointer;
    display: inline-block;
    font-size: 14px;
    font-weight: 700;
    margin-top: 10px;
    text-decoration: none;
    text-transform: uppercase;
}
.expo-archive-arrow {
    height: 10px;
    margin-left: 4px;
    vertical-align: middle;
}