...
...), the opposite of the
nesting each site's own style.css's ".teaser-slider--single-image .faux-active .size-wrapper"
centering rule assumes (it centers .size-wrapper's own inline content, which does nothing when
.size-wrapper has no such content of its own). The anchor itself is already the thing that
needs centering here, and its own direct parent is the glide__slide section carrying
"faux-active" (added by teaser-slider.js when there is exactly one slide) — center that
instead, matching live's actual behaviour (verified against meyerwerft.de's own
silver_nova.jsp, 2026-07-31). */
.teaser-slider.teaser-slider--single-image .glide__track .faux-active {
text-align: center;
}
/* text-align is inherited, so the rule above also recentres the slide's own caption
(.text, e.g. "Silver Ray"), which live keeps left-aligned — reset it back explicitly. */
.teaser-slider.teaser-slider--single-image .glide__track .faux-active .text,
.teaser-slider.teaser-slider--single-image .glide__track .faux-active .subtext {
text-align: left;
}
/* Ship List thumbnail (#ship-search .ships .ship a img, ryze_ships' Ship/Search.html): live's own
CSS (Sites/MeyerWerft/style.css, kept in sync with meyerwerft.de's own stylesheet verbatim — do
not edit) only ever sets max-width here and lets the image's own native aspect ratio determine
the rendered height, because live's own backend serves a DIFFERENT, separately pre-cropped image
per breakpoint (640x500 below 1020px, 304x217 at/above it), each already sized so plain
max-width scaling lands on the right proportions with no cropping needed. ryze_ships' own
`list_image` field is deliberately a single image (see docs/DECISIONS.md), sourced from the
640x500 crop — correct as-is at the mobile breakpoint (identical file to live's own, untouched
here), but taller/narrower than live's own 304x217 image once shown at the desktop breakpoint's
width, unless re-cropped here. `width` (not just `max-width`) must be set explicitly alongside
`height` — an ![]()
with only `height` specified and `width: auto` has its box width computed
from that height times the image's own intrinsic ratio, not from `max-width`, so without an
explicit `width` here the box renders narrower than 13.9375rem regardless of `object-fit`.
The extra leading `body` (rather than repeating just `#ship-search .ships .ship a img`) bumps
specificity above style.css's own same-selector rule — needed because, despite custom.css's own
TypoScript key (903) being numerically higher than style.css's (902) in
Configuration/Sets/MeyerWerft/setup.typoscript, custom.css is actually rendered into
BEFORE Sites/MeyerWerft/style.css (verified in the served page's own order), so on equal
specificity style.css's later rule would otherwise win the cascade and silently no-op this. */
@media (min-width: 1020px) {
body #ship-search .ships .ship a img {
width: 13.9375rem;
height: 9.9488rem;
object-fit: cover;
}
}
/* Pressearchiv teaser text (Resources/Private/Extensions/News/Partials/List/Item.html): live's
own markup is a bare ` elements, which is what lets the trailing space in
Sites/MeyerWerft/style.css's own `nav.breadcrumb ul li:after { content: " › "; }` render as a
visible gap before the next 's text - `display: inline-block` siblings only get that
trailing-space rendering treatment when there is *some* whitespace/character at the box boundary
in the source. This project's own News Fluid output has zero inter-tag whitespace (every News
template in this project is written compact, and Extbase's own TemplateView renders it exactly
as authored, unlike the page-level PAGEVIEW/dataProcessing-driven breadcrumb, which keeps the
partial's natural indentation) - so the same " › " content rendered zero visible gap after the
arrow ("Presse ›Presse Detail", verified via a rendered screenshot against live's own, which
shows "Presse › Presse Detail"). Overridden here with non-breaking spaces (\00a0), which are
never subject to that collapsing behavior regardless of surrounding markup whitespace.
Deliberately scoped to `.news-detail-breadcrumb` rather than a sitewide `nav.breadcrumb` - an
earlier version of this rule had no such scope and applied everywhere, which DOUBLED the gap on
every other page's breadcrumb (e.g. the Pressearchiv list page, still page-level-rendered with
its own natural whitespace already providing a correct single gap) - the non-breaking spaces
added their own fixed gap on top of the whitespace-based gap that was already correct there,
reported by the user as "our breadcrumb have more space" (see docs/DECISIONS.md). The extra
class ancestor here already gives this selector more specificity than style.css's own bare
`nav.breadcrumb ul li:after`, so no `body`-prefix/cascade-order trick is needed this time. */
.news-detail-breadcrumb nav.breadcrumb ul li:after {
content: "\00a0›\00a0";
}
/* Press Detail media lightbox arrow centering (#press-media-overlay, News/Detail.html): live's own
per-site style.css (Css/Sites//style.css) positions `.glide--controls` (the prev/next
arrow wrapper) at a fixed `top: 40%` of `.glide`'s own rendered height (image + caption row
combined) - do not edit that
file. That 40% was whatever landed on the image's own vertical center for live's own overlay
images, which (verified via their actual rendered/natural size, not their misleading
"_752x414"-suffixed filename) come out at a live-side-inconsistent aspect per photo - anywhere
from roughly square to ~1.48:1, driven entirely by whichever of a given article's photos happens
to need the least "contain"-fit scaling, not a deliberate design. Our own overlay image
(News/Detail.html's `data-overlay-image`) is instead cropped to a single fixed `752c`x`533c`
aspect - same ratio as the already-correct 480:340 thumbnail crop, just larger, chosen because a
literal 752x414 crop-to-exact-size cut off the subject's own head and torso on portrait photos
(see docs/PROJECT-STATE.md, 2026-08-17) - so every one of our own slides renders at the exact
same height, unlike live's own carousel (confirmed: one outlier photo, closer to a square aspect,
stretches live's ENTIRE carousel height to match it, since Glide's flex-row slide track sizes to
its tallest child regardless of which slide is active - not something to replicate here, since
our own uniform crop means there's no tallest-outlier slide to size against in the first place).
With our own taller/differently-proportioned image, live's 40% now lands visibly above our own
image's actual vertical center (reported by the user as the arrows sitting "a little upper").
Recalculated for our own fixed image aspect: the image always starts exactly at `.glide`'s own
top (confirmed via measurement - the image is the first thing in each slide), so the image's own
vertical center as a fraction of the full `.glide` height (image + margin + caption row) is
(533 / 752 rendered width-relative height) ÷ 2, over that same height plus the caption row -
measured directly against our own rendered layout at 43.8%, replacing live's 40%. The extra
leading `body` bumps specificity above style.css's own same-selector rule - needed because,
despite custom.css's own TypoScript key being numerically higher than style.css's in
Configuration/Sets/MeyerWerft/setup.typoscript, custom.css is actually rendered into
BEFORE Sites/MeyerWerft/style.css (verified in the served page's own order, same
cascade-order quirk documented above for `#ship-search .ships .ship a img`), so on equal
specificity style.css's later rule would otherwise win and silently no-op this. */
body #press-media-overlay .glide .glide--controls {
top: 43.8%;
}
/* Image-Slider: `.image-slider .sections section picture` in Sites//style.css pins a fixed
height (396px from 1020px, 520px from 1200px) with overflow: hidden, but the img in there only
gets `display: block` — no height, no object-fit. So the delivered file's own height leaks into
the layout: whenever it is not exactly the pinned value, a gap opens below the image while the
absolutely positioned `.text` overlay stays glued to the box's bottom: 0.
That happens as soon as an editor crops with an enforced aspect ratio, because the crop wizard
never snaps to the mathematically exact full frame — it insets the frame by one or two pixels
(stored cropArea width 0.996 instead of 1.0), which turns a 1022x520 original into 1018x518 and
leaves a 2px gap. Choosing a "better" ratio value cannot fix that; the box has to win instead.
`.stage .sections section picture img` and `.press-media-pool .medium picture img` already do
exactly this — the slider was the only image wrapper missing the guard.
The leading `body` is needed because custom.css is rendered into BEFORE
Sites//style.css despite its higher TypoScript key (see the ship-search note above), so on
equal specificity the site bundle would win. */
body .image-slider .sections section picture img {
width: 100%;
height: 100%;
object-fit: cover;
}
/* Accordion item image: the image column is `cell col-md-5 col-lg-4` inside the accordion's inner
`text-image page-width--md` container, and nothing in Sites//style.css styles that image.
With only the global `img { max-width: 100% }` it therefore rendered at its intrinsic size, so
its width depended on the aspect ratio: the originals are pre-cut to 270x190, and a 1:1 crop of
one is 166x166, which then sat at 166px in a ~313px column. The image should fill the column
regardless of the ratio, with the height following from it. */
.accordion-wrapper .text-image picture,
.accordion-wrapper .text-image picture img {
display: block;
width: 100%;
height: auto;
}
/* CTA teaser / CTA text-image: the image gets `class="logo"` although it is a normal content image,
and `.contact-teaser .logo` in Sites//style.css pins a fixed width (313px, 225px from
1020px, 223px from 1200px). In the .section-left / .section-right columns of the cta-teaser those
are only about 67 / 60 / 45 percent of the available width, so the image never filled its column
and its rendered size depended on the aspect ratio. It should use the full column width, with the
height following from the ratio; the margins from the site bundle stay untouched.
Leading `body` for the same load-order reason as the rules above. */
body .contact-teaser .logo {
width: 100%;
height: auto;
}
/* CTA teaser, mirrored variant (display_layout = content_right): flex-row-reverse only flips the
visual order, it does not mirror the asymmetric column paddings. In the default order the gutter
between the two columns comes from `.contact-teaser .section-right { padding-left }` — 90px from
1020px, 53px from 1200px — plus a 6px padding-right on .section-left from 1200px. Reversed, that
left padding would sit against the outer page edge and the gap between the columns would vanish,
so both are swapped for this row only. Leading `body` because custom.css is rendered into
BEFORE Sites//style.css despite its higher TypoScript key. */
@media (min-width: 1020px) {
body .contact-teaser .row.flex-row-reverse .section-right {
padding-left: 0;
padding-right: 90px;
}
}
@media (min-width: 1200px) {
body .contact-teaser .row.flex-row-reverse .section-right {
padding-right: 53px;
}
body .contact-teaser .row.flex-row-reverse .section-left {
padding-right: 0;
padding-left: 6px;
}
}
/* Quote teaser: the image field now also accepts a video (mp4/YouTube/Vimeo), rendered via
f:media as a
` (a direct flex child of `.press-teaser a`), styled by Sites/MeyerWerft/style.css's own `.press-teaser .text` rule (flex: 1 1 auto; margin: 0 0 14px; do not edit). Ours renders `
` instead: `f:format.html()` runs
the news item's plain-text teaser through TYPO3's own RTE parseFunc, which always wraps a bare
text block in a `
` - so the "text" class ends up on the outer div while the actual copy sits in a browser-default-margined `
` nested inside it. `.press-teaser .text` still matches (class selector, tag-agnostic) and still sizes the *div* correctly as the flex item, but the nested `
`'s own default user-agent margin (~1em top/bottom) adds extra vertical space inside that div which live's flat, single-element markup never has. Zero it out so the div's own explicit margin is the only spacing in effect, matching live's rendered layout exactly. */ .press-teaser .text p { margin: 0; } /* Press Detail breadcrumb ONLY (News/BreadcrumbViewHelper.php + shared Templates/Partials/ Breadcrumb.html, wrapped in Detail.html's own `.news-detail-breadcrumb` div specifically so this rule can be scoped to just this one rendering path): live's own raw markup always has literal whitespace (newlines/tabs) between its