/* Issue #225: Scroll-Knoepfe unten rechts (Handy + Tablet).

   XenForo hatte sie als `.u-scrollButtons` — zwei runde Pfeil-Knoepfe fix an
   der unteren rechten Ecke. Das kompilierte uix-CSS der XenMaxx-Bundles
   traegt die Klasse zwar noch, aber unbrauchbar: dort steht ein nie
   aufgeloestes LESS `right:(20px) / 2`, die Regel faellt weg und die Knoepfe
   haengen ohne `has-hiddenscroll` irgendwo in der Zeile. Darum eigenes
   Markup, eigene Klasse — und diese Datei statt zweier Theme-Kopien: die
   Knoepfe liegen `position:fixed` ueber allem und haben mit dem Seitenlayout
   des jeweiligen Looks nichts zu tun. Eingebunden von BEIDEN base.html
   (LSMaxx und XenMaxx) ueber /lachschon-assets/, den gemeinsamen
   Asset-Praefix.

   Gegenstueck: 3a7f80d5_scroll.js (schaltet `gwn-scroll--on` und
   `disabled`). Ohne JS bleibt der Block unsichtbar — zwei Knoepfe, die
   nichts tun, waeren schlimmer als keine. ?v=N bei jeder Aenderung
   hochzaehlen (10-Jahre-Cache auf den Asset-Routen). */

#gwn-scroll { display: none; }

/* Bis 1024px: Handy UND Tablet (das Issue nennt beide; iPad quer ist genau
   1024). Darueber ist Maus/Tastatur da — Pos1/Ende tun es dort. Bewusst
   NICHT der 650px-Breakpoint der Mobil-Schicht (4d0b11e5_mobile.css): das
   Tablet faehrt das Desktop-Layout und braucht die Knoepfe trotzdem. */
@media (max-width: 1024px) {

/* z-index 490: ueber dem Seiteninhalt (dort geht nichts ueber 50), aber
   unter JEDER Ueberlagerung beider Looks — XenMaxx' Off-Canvas-Menue liegt
   auf 500, LSMaxx' Overlay/Panel auf 10009/10010, Dialoge ab 1000. Ein
   Knopf, der ueber dem offenen Menue schwebt, waere ein Fehlklick.

   Nebeneinander statt uebereinander (User-Vorgabe; XF stellte sie genauso:
   `.u-scrollButtons .button+.button{margin-left:10px}`) — das Paar baut
   damit 38px hoch statt 84px und braucht die untere rechte Ecke nicht fuer
   sich allein.

   Die drei `bottom`-Zeilen sind eine Kaskade, die letzte unterstuetzte
   gewinnt: nackter Fallback, dann der Auftrieb ueber Shoutbox-/Wochenthema-
   Reiter (--gwn-scroll-lift, gemessen von 3a7f80d5_scroll.js), dann
   zusaetzlich die iPhone-Home-Leiste. Nicht in EINE Zeile ziehen: ohne
   env()-Unterstuetzung fiele sonst auch der Auftrieb weg und die Knoepfe
   lagen wieder hinter den Reitern. */
#gwn-scroll.gwn-scroll--on {
    display: flex;
    flex-direction: row;
    position: fixed;
    right: 12px;
    bottom: 16px;
    bottom: calc(16px + var(--gwn-scroll-lift, 0px));
    bottom: calc(16px + env(safe-area-inset-bottom) + var(--gwn-scroll-lift, 0px));
    z-index: 490;
}
/* Rund statt eckig (XFs Vorbild) und in der Palette des Home-Knopfs
   (#mtoggle/#mhome, 4d0b11e5_mobile.css): dunkelblaue Flaeche, hellblauer
   Rand, weisser Glyph. Der Wert steht fest statt per Custom Property, weil
   er in beiden Looks UND in beiden XenMaxx-Varianten (hell/dunkel) traegt —
   die Flaeche bringt ihren eigenen Kontrast mit, sie erbt keinen. */
#gwn-scroll button {
    display: block;
    width: 38px;
    height: 38px;
    padding: 0;
    background: #1C4284;
    border: 2px solid #98BBE5;
    border-radius: 50%;
    box-shadow: 0 1px 4px rgba(0,0,0,0.3);
    box-sizing: border-box;
    cursor: pointer;
    opacity: 0.85;
    -webkit-appearance: none;
    appearance: none;
    -webkit-tap-highlight-color: rgba(0,0,0,0);
}
/* margin statt gap: `gap` auf Flex ist auf aelteren Mobil-Safaris noch
   nicht ueberall da, und ein zusammengeklebtes Knopfpaar trifft man auf dem
   Handy schlecht. */
#gwn-scroll button + button { margin-left: 8px; }
#gwn-scroll button:active { opacity: 1; }
/* Am Anschlag (ganz oben bzw. ganz unten) bleibt der Knopf stehen statt zu
   verschwinden: ein wanderndes Knopfpaar traefe man nicht zweimal an
   derselben Stelle. Nur blass und tot. */
#gwn-scroll button[disabled] { opacity: 0.3; cursor: default; }
#gwn-scroll svg { display: block; width: 22px; height: 22px; margin: 0 auto; fill: #FFFFFF; }

}