/*
    Mobile and tablet fixes — PRD acceptance criterion 11.

    WHY THIS IS A SEPARATE FILE. The PRD makes "desktop UI unchanged" an invariant. Every rule here
    lives inside a `@media (max-width: …)` block, so the file cannot affect a desktop viewport by
    construction, and a reviewer can verify that by checking the braces rather than by reasoning
    about specificity against the 1067 lines of Site.css. Nothing may be added to this file outside
    a media query.

    WHY NOT THE MEDIA QUERIES ALREADY IN Site.css. Those came from an earlier generation of the
    markup: they target `#logoLeft`, `#logoRight`, `#PoweredBy`, `.navbar-header` and
    `#MainNav .navbar-default ul > li > a`, and none of those elements or class combinations exists
    in the pages this application renders. They are dead, and are left alone rather than repurposed —
    they belong to the legacy tree's history, not to this fix.

    BREAKPOINTS. Almost everything here uses 991.98px, Bootstrap 4's `lg` boundary. That is where
    `navbar-expand-lg` collapses the navigation into the hamburger, which makes it this application's
    own dividing line between "a pointer is driving this" and "a finger is". It also covers the two
    widths the acceptance criterion names: 375px and 768px both fall inside it, and 768px would fall
    outside the `md` boundary (767.98px), which is the obvious-looking choice and the wrong one — a
    tablet in portrait is a touch device. The one exception is section 2's 575.98px (`sm`), where the
    rule is about a 350px panel that fits comfortably at 768px and only fails on a phone.

    HOW THE LIST OF PROBLEMS WAS PRODUCED. Every ported page was rendered with representative data
    and measured in headless Chrome inside an iframe of exactly 375px and exactly 768px: document
    scrollWidth against viewport width, the bounding box of every element, whether the hamburger
    opens the menu, whether a navbar dropdown opens inside the viewport, and the height of every
    interactive control. Each block below names what that measurement found.
*/

/* ==========================================================================================
   1. Author-entered page content
   ==========================================================================================

   THE WORST BREAK FOUND, and it is on the public pages. /home/content, /news/details and
   /event/details all render administrator-authored HTML through Html.Raw into #contentmain. That
   HTML comes out of CKEditor, which writes explicit pixel widths: `<table style="width:620px">`,
   `<img style="width:800px">`, `<iframe width="600">`. Measured on a 375px viewport, a page with a
   pasted table, image and map iframe pushed the document to 815px — the reader has to scroll
   sideways to finish every line of every paragraph.

   Nothing in the views can fix this, because the markup is data. It has to be constrained by CSS
   at the one hook all three views share, #contentmain.

   Constrained up to the `lg` boundary rather than `md`, because an 800px image overflows a tablet
   too. Above it the desktop container is wide enough and the rules do not apply. */
@media (max-width: 991.98px) {
    #contentmain img,
    #contentmain video,
    #contentmain embed,
    #contentmain object {
        max-width: 100% !important;
        height: auto !important;
    }

    /* Height is left alone for iframes: an embedded map or video player with `height="450"` and
       `height: auto` collapses to nothing. Only the width is capped. */
    #contentmain iframe {
        max-width: 100% !important;
    }

    /* `display: block` is what stops a table from forcing the page wide: as a block box it takes the
       width it is given and scrolls its own overflow, while the cells keep the widths the author
       set. This is the same treatment Bootstrap's .table-responsive gives the tables the views
       control — those are already wrapped; these cannot be, because they arrive as stored HTML. */
    #contentmain table {
        display: block;
        width: 100% !important;
        max-width: 100%;
        overflow-x: auto;
    }

    /* A pasted URL is one unbreakable word and will push the page out on its own. */
    #contentmain {
        overflow-wrap: break-word;
    }
}

/* ==========================================================================================
   2. The member forms that ran off the screen
   ==========================================================================================

   /account/registeruser and /account/updateuser were the only two pages whose own markup overflowed:
   measured document scrollWidth 416px against a 375px viewport, with the right-hand edge of every
   input cut off. Both wrap their fields in a panel that asks for a minimum width of 350px, which
   with the surrounding card and column padding does not fit a phone.

   The views carried that as `style="min-width: 350px"`. An inline style cannot be overridden from a
   media query without `!important`, so it moved to the .memberFormPanel class the views now use —
   which keeps the 350px minimum, so the desktop rendering is byte-identical — and the rule below
   drops the minimum on phones only. */
@media (max-width: 575.98px) {
    .memberFormPanel {
        min-width: 0;
    }
}

/* ==========================================================================================
   3. The navigation, while it is collapsed into the hamburger
   ==========================================================================================

   The hamburger itself works: measured at 375px it is shown, it is 38px tall, clicking it opens
   #navbarNavDropdown, and a navbar dropdown opens inside the viewport. (Bootstrap 4's dropdown needs
   Popper.js, which this application does not ship — but it skips Popper entirely for dropdowns
   inside a navbar, which is all of them here.)

   What is not usable is the size of the rows once the menu is open: every .dropdown-item measures
   31px. Site.css intends otherwise — `.dropdown-menu > li > a { padding: 10px 10px 10px 10px
   !important }` — but that selector describes Bootstrap 3 markup (`<li><a>`), and both the legacy
   app and this port render Bootstrap 4 markup (`<a class="dropdown-item">` directly inside
   .dropdown-menu). The rule has never matched anything. The padding below is the padding that rule
   asked for, applied to the markup that actually exists, and only where a finger is doing the
   tapping. */
@media (max-width: 991.98px) {
    .navbar-collapse .dropdown-item {
        padding-top: 11px !important;
        padding-bottom: 11px !important;
    }

    .navbar-collapse .nav-link {
        padding-top: 11px;
        padding-bottom: 11px;
    }
}

/* ==========================================================================================
   4. Controls that are smaller than a fingertip
   ==========================================================================================

   Measured at 375px: navigation rows, buttons, form controls, the icon links that are a table row's
   only actions, and the recurring one-link-per-line idiom the views use for "Tilbage til
   administration", "Opret ny sideindhold" and a news headline. A link that sits inside running text
   is left alone — padding it out would change how the paragraph reads. */
@media (max-width: 991.98px) {
    /* The one-link-per-line idiom: a link that is the only thing in its paragraph, div or heading is
       a control, not prose, and measured 14-17px. `:only-child` picks exactly that shape out. The
       exclusions are the anchors the rest of this file sizes deliberately — they need their own
       horizontal padding and display, which a blanket `padding: 10px 0` would flatten. */
    #MidWorper p > a:only-child:not(.btn):not(.dropdown-item):not(.nav-link):not([class^="icon-"]),
    #MidWorper div > a:only-child:not(.btn):not(.dropdown-item):not(.nav-link):not([class^="icon-"]),
    #MidWorper dd > a:only-child:not(.btn),
    #MidWorper h4 > a:only-child:not(.btn) {
        display: inline-block;
        padding-top: 10px;
        padding-bottom: 10px;
    }

    /* A table row's actions — "Rediger", "Update", the album's page numbers — sit next to a sibling
       button, so they are not `:only-child`. They are still controls. */
    #MidWorper .table td a:not([class^="icon-"]) {
        display: inline-block;
        padding: 10px 8px;
    }

    /* The footer bar's account controls measured 12-14px: "Log ind", "Log off", "Hej <navn>" and the
       info@ mailto. */
    #topBar a,
    #footerLeft a {
        display: inline-block;
        padding: 10px 0;
    }

    /* The home page's three panel buttons draw a block the size of a button but only wrap the text
       in the link, so the tappable area was 17-20px inside a 40px button — most of what looks like
       a button did nothing. Making the anchor fill its button fixes the mismatch.

       The id prefix is what makes these win over the `:only-child` rule above, which would otherwise
       flatten them back to inline-block on equal specificity. */
    #MidWorper .orangeHomeButton a,
    #MidWorper .btnBooking a,
    #MidWorper .btnPhotoGallery a {
        display: block;
        padding: 10px 0;
    }

    .btnPhotoGallery p,
    .orangeHomeButton p {
        margin-bottom: 0;
    }

    /* Form controls. /account/register's role picker measured 18px: its <select> is the one control
       in the ported views with no .form-control class, so it renders at the browser's native size.
       Rather than add the class — which would change the desktop rendering — every control in a form
       is given a fingertip-sized minimum here. */
    form select,
    form input[type="text"],
    form input[type="email"],
    form input[type="password"],
    form input[type="tel"],
    form input[type="date"],
    form input[type="number"],
    form input[type="submit"],
    form button,
    .btn {
        min-height: 44px;
    }

    /* Except a .btn-link used as a row action: giving it 44px of height inside a table row would
       stretch the row. It gets its hit area from padding instead. */
    .table .btn-link {
        min-height: 0;
        padding: 10px 8px !important;
    }

    /* The admin row actions are 24x24 background images — "Vis", "Rediger", "Slet" on the photo
       album and page-content tables. The image stays 24px; the hit area around it grows. */
    .icon-details,
    .icon-edit,
    .icon-delete {
        width: 44px;
        height: 44px;
        background-position: center;
    }

    /* The home page carousel's arrows measured 14px. */
    .carousel-control-prev,
    .carousel-control-next {
        min-width: 44px;
    }

    /*
        NOT FIXED HERE, deliberately: #blueimp-gallery's own .prev / .next / .close. They measure
        14-24px in the audit only because it runs offline and the gallery's stylesheet comes from
        //blueimp.github.io — with it loaded they are full-height overlay controls, and the whole
        element is display:none until the lightbox opens. That CDN dependency is worth removing on
        its own terms (if the host is unreachable those three characters render as stray text on the
        gallery page), but that is an asset-hosting change, not a responsive one.
    */
}