/*
 * tab-group.css — the tab group (work package 2, T7 — M11 `tab-group`).
 *
 * Belongs to unit M11 of the Divi Library. Unlike M10 this unit brings NO markup of its own:
 * Divi has a finished module in `divi/tabs` and `divi/tab`, switching behaviour included. What
 * stands here is solely the adjustment of Divi's default to the measured legacy site — the unit
 * itself has remained a Divi module.
 *
 * Why the CSS stands here and not in a global preset (E7 and E16): Divi's tab module offers
 * options for the tab type and for the body, but NONE for the active tab. With this unit that is
 * half the matter — without it nobody sees which panel is open. Spreading the values over two
 * systems would be exactly the source of error that struck three times in E11, E14 and E15: two
 * places that have to stay together and do not.
 *
 * All values come from tokens.css and are measured there on the RENDERED legacy site
 * (`scripts/measure-bestand.sh 1920 reiter`), not read from its stylesheet. With this unit the
 * difference is particularly sharp: the legacy stylesheet lays two generations of Bootstrap on
 * top of each other. The rules for the active tab stand as `.nav-tabs > li.active > a`
 * (Bootstrap 3), while the markup carries the class on the link (`a.nav-link.active`,
 * Bootstrap 4). Whoever reads the rule rebuilds a white tab with a grey frame — in the browser
 * there is no such thing.
 *
 * Two classes in the selector, throughout — `.wi-tabs` plus Divi's own class. Divi's default
 * stands in includes/builder/feature/dynamic-assets/assets/css/tabs.css and is single-class
 * (`.et_pb_tabs`, `ul.et_pb_tabs_controls`, `.et_pb_tab`); a single-class selector of ours would
 * lose against it or win only through load order, which is the same as chance. That is the
 * specificity rule from AI/architecture/divi-fallstricke.md, section 2.
 *
 * The class `wi-tabs` sits on the module and comes from bin/lib/library-units.php. It can NOT
 * come from a preset: a module preset in Divi 5 sets no CSS class (see the head of
 * bin/lib/global-presets.php).
 */

/* ------------------------------------------------------------------ *
 * The shell
 * ------------------------------------------------------------------ */

/* Divi frames the whole group with `1px solid #d9d9d9`. The legacy site has no frame — there the
 * tab bar passes into the white area without an edge. */
.wi-tabs.et_pb_tabs {
  border: 0;
}

/* ------------------------------------------------------------------ *
 * The tab bar
 * ------------------------------------------------------------------ */

/*
 * Divi puts the bar on `#f4f4f4` and draws a 1px line below it with
 * `ul.et_pb_tabs_controls:after`. Both fall away: on the legacy site the bar stands directly on
 * the section colour.
 */
.wi-tabs .et_pb_tabs_controls {
  background-color: transparent;
}

.wi-tabs .et_pb_tabs_controls::after {
  border-top: 0;
}

/*
 * The individual tabs. Divi separates them with `border-right: 1px solid #d9d9d9` and sets
 * `font-weight: 600`; the legacy site knows neither the rule nor the weight.
 *
 * Font size and line height stand at this place and not on the link, and that belongs together:
 * Divi carries the line height on the `li` (`1.7em`) and lets the link follow with
 * `line-height: inherit`. A line height on the link alone would leave Divi's value on the `li`
 * standing, and the tab would be taller than its text.
 *
 * The font size therefore has to stand here as well. The line height is a RATIO (see tokens.css),
 * and a ratio refers to the font size of the element it stands on — with the size on the link and
 * the line height on the `li`, the browser would compute 1.42857 against the 14px of the root and
 * arrive at 20px instead of 28.57px. Measured exactly that way before this line moved here.
 */
.wi-tabs .et_pb_tabs_controls li {
  border-right: 0;
  font-size: var(--wi-tabs-size);
  font-weight: var(--wi-tabs-weight);
  line-height: var(--wi-tabs-line-height);
}

/*
 * The tab text. Divi's default is `color: #666` with `padding: 4px 30px`.
 *
 * `display: table-cell` stays: it is the mechanism with which Divi keeps the text centred when a
 * tab runs to two lines. The legacy site achieves the same through the line height.
 */
.wi-tabs .et_pb_tabs_controls li a {
  color: var(--wi-tabs-color);
  padding: var(--wi-tabs-padding);
}

/*
 * The ACTIVE tab — the one place where M11 deliberately does not hit the legacy site (E16).
 *
 * On the downloads page the open tab cannot be told from the closed ones: same colour, same
 * ground, same (invisible) frame — measured, not assumed. That is not a design intent but the
 * consequence of the Bootstrap mixture above. The legacy news overview shows what was meant:
 * there the same intent meets the matching markup, and the active tab stands in the lighter
 * orange on white.
 *
 * Exactly that stands here. The white ground is at the same time the ground of the content area
 * below it — open tab and open panel thereby become one surface.
 *
 * Divi sets `.et_pb_tab_active a { color: #333 !important }`. Against an `!important` only an
 * `!important` helps; the second class in the selector makes sure it also wins at equal order.
 */
.wi-tabs .et_pb_tabs_controls li.et_pb_tab_active {
  background-color: var(--wi-tabs-surface);
}

.wi-tabs .et_pb_tabs_controls li.et_pb_tab_active a {
  color: var(--wi-tabs-color-active) !important;
}

/* ------------------------------------------------------------------ *
 * The content area
 * ------------------------------------------------------------------ */

/*
 * Divi's `.et_pb_all_tabs { background-color: #fff }` already hits the legacy site — the content
 * area of the tabs is white there, on a dark section too. The value stands here nonetheless, and
 * for two reasons: it is measured (it is not to be inherited from Divi's default, which can
 * change with an update), and it is the precondition for the active tab above.
 *
 * That is at the same time the finding which corrects E15: on the legacy site the download list
 * ALWAYS stands inside a tab, so its black description stands on white and not on `#707070`. See
 * E17 of the plan.
 */
.wi-tabs .et_pb_all_tabs {
  background-color: var(--wi-tabs-surface);
}

/*
 * The individual panel. Divi pads it with `24px 30px`; the legacy site holds only 40px at the top
 * and leaves nothing at left and right — the content closes flush with the text column.
 *
 * The text colour is the decisive line of this file, and it is so for the same reason as with M10
 * (E15): a Divi section passes its text colour to everything that has none of its own. In a dark
 * section that is white — and the surface here is white. Without this line every text in the
 * panel would stand white on white. On the LEGACY site that is exactly the case: there the body
 * copy in the panel is invisible, and what remains visible is only what brings a colour of its
 * own (the download list). That is not adopted — an invisible text is not a legacy value but a
 * defect.
 */
/*
 * The mode variables do the same for MODULES in the panel. Since 2026-10-09 the tabs of the
 * library unit carry their text as a text module (bin/lib/library-units.php), and the text,
 * heading and button presets take their colour from `--wi-mode-fg`, which the dark section sets
 * to white (sections.css, farbe-folgt-sektion). The panel is a light surface, so it sets the light
 * mode for whatever stands in it. Measured before this line: the sample text of the tab module
 * white on white, at 1920, 1280 and 375px.
 */
.wi-tabs .et_pb_tab {
  padding: var(--wi-tabs-pane-padding);
  color: var(--wi-color-ink);
  --wi-mode-fg: var(--gcid-wi-ink);
  --wi-mode-bg: var(--gcid-wi-surface);
}

/*
 * The panel does not leak its trailing margin (F13 of the frontend defect list).
 *
 * The body of a tab is a rich text field: whatever an editor writes ends up in it, and a
 * paragraph brings its own 22px along (E22). The panel has no bottom padding — measured, and the
 * legacy value —, so that margin lands on the OUTER edge of the module. The rule for stacked
 * units then puts its own spacing on top, because it counts the tab group among the units that
 * bring none (sections.css, E26): 22 + 22 = 44px where 22 is due.
 *
 * It is the mechanism of F6 one storey down. There it was a row whose bottom edge is drawn by the
 * unit inside it; here it is a module whose body carries arbitrary rich text. Measured on
 * 2026-09-07 over all 227 published pages and posts, it was the last of 53 unit transitions still
 * fed from two sources.
 *
 * **Why the margin is taken here and not the trigger qualified over there.** E26 could ask what
 * the tab group ends in, the way it asks a row since F6. It would have to ask it of the VISIBLE
 * panel — which changes when a visitor clicks a tab — and it could only guess from the tag name
 * which block carries a margin, where the row question asks for a module class. This rule instead
 * makes true the statement E26 already assumes: the tab group has no trailing space of its own.
 * That holds whatever a panel ends in, and whichever panel is open.
 *
 * **What it changes at the white area, and why that is not new.** The content area ends at the
 * content afterwards instead of 22px below it. That is not a state this rule invents — it is the
 * one the group already stands in wherever its body does not leak. Measured on 2026-09-07:
 *
 *   legacy `/news-media/downloads/`   panel ends 42px below the last text (20px list layout plus
 *                                     the 22px margin of `ul.ce-uploads`), 0px after the group
 *   instance, same page               panel ends 20px below it, 22px after the group (E26)
 *   instance, a body ending in a `<p>` 22px below it AND 22px after the group — the defect
 *
 * The legacy site therefore keeps the trailing 22px INSIDE the white area and holds nothing after
 * the group; E26 moved it outside. The total from text to text is the same 42px on the downloads
 * page, and this rule extends that same arrangement to the body that leaks — the group's white
 * area ends at its content, the spacing stands outside it.
 *
 * To turn the arrangement around instead — leave the margin inside and take the tab group out of
 * E26's trigger list — would hit the legacy site exactly on both pages. It would also re-decide
 * the deviation of E26, which is not this rule's business; the question stands in the plan.
 *
 * The legacy site offers no target value of its own for a body ending in a paragraph: it carries
 * one tab group in the sense of M11, and its panels all end in a download list. The target value
 * for that case therefore comes from E26 — 22px after the group, from 1600px 15px — and not from
 * a measurement that does not exist.
 */
.wi-tabs .et_pb_tab_content > :last-child {
  margin-bottom: 0;
}

/*
 * The same leak one storey further down: when the panel ends in a text module (the library tab
 * since 2026-10-09), the last paragraph sits inside the module and the rule above reaches only the
 * module. Measured before this rule: 22px below the paragraph at 1920px, 15px at 1280 and 375px.
 */
.wi-tabs .et_pb_tab_content > .et_pb_text:last-child .et_pb_text_inner > :last-child {
  margin-bottom: 0;
}

/* ------------------------------------------------------------------ *
 * Narrow windows
 * ------------------------------------------------------------------ */

/*
 * Below 767px Divi stacks the tabs one below the other and separates them with
 * `border-bottom: 1px solid #d9d9d9`. The stacking stays — it is the only way to keep four tabs
 * legible on a phone, and the legacy site cannot do it: its bar stands on `nowrap` and pushes the
 * tabs out of the picture.
 *
 * The divider falls away, as in the line above. Without this rule it stands on narrow windows and
 * nowhere else — the kind of deviation that never shows when checking at 1920px.
 *
 * 767 and 479 are Divi's steps, not those of the legacy site. With M10 it was the other way
 * round, and the difference is not arbitrary: the download list is markup of our own, here Divi's
 * layout applies, and two systems of steps in one module would produce a range in which the tabs
 * are already stacked and our rules do not bite yet.
 */
/*
 * The second leak of F13, and it exists only on narrow windows: from 980px Divi gives every
 * panel `margin-bottom: 30px`. Only one panel is ever visible, so what that margin does is push
 * the group's bottom edge 30px below its content — and the spacing of E26 then lands 30px too
 * low: 45px between the text and the next unit where 15 are due.
 *
 * The legacy site holds `padding: 40px 0 0` and `margin: 0` on its panel at 1920, 768 and 375px
 * alike (measured 2026-09-07 at the snapshot). The 30px are Divi's alone and were never measured
 * against anything.
 *
 * 980 and not 767: the boundary belongs to the value being overridden, and Divi sets this one at
 * its tablet step — a different one from the stacking of the tab bar below. Measured by narrowing
 * in, 981px shows 0 and 980px shows 30.
 */
@media only screen and (max-width: 980px) {
  .wi-tabs .et_pb_tab {
    margin-bottom: 0;
  }
}

@media only screen and (max-width: 767px) {
  .wi-tabs .et_pb_tabs_controls li {
    border-bottom: 0;
  }
}

@media only screen and (max-width: 479px) {
  .wi-tabs .et_pb_tabs_controls li {
    border-bottom: 0;
  }
}