/** * swiper-small-controls-arrow-offset.css * Page: /de/logistik-als-wachstumstreiber + /en/logistics-as-a-growth-driver-in-ecommerce * QA batch #21, item 1 (second half). * * The white pill tab-bar's nav arrows sit flush at `left:0` / `right:0`, leaving a * 1px sliver of the first/last pill past the white gradient fade. Pull each arrow * 1px outward. * * WHY THIS IS NOT A GLOBAL `.swiper-small-controls` RULE * The first version of this sheet was exactly that: * .swiper-small-controls .swiper-button-prev { left: -1px; } * It was wrong in both directions, and measuring the live DOM is what showed it: * * - It did NOT reach the reported tab bar. `qa16-logistik-praxis-tabbar.css` * already pins `left:0 !important` on * `body.page-id-326672 .kapitel.tabs.tabs-pills .swiper-button-prev` * (specificity 0,5,1 + !important), which beats a bare `.swiper-small-controls` * rule (0,2,0). The tab arrows stayed at 0px. * * - It DID reach every other `.swiper-small-controls` on the site — breadcrumbs * (2 templates), Toc/Standard, Toc/Card, the service-partner results strip, * Tabs/UserSpecific, Tabs/WawiDownload — none of which were reported, and on * most of which the arrows are permanently disabled and invisible anyway. * * So it moved arrows nobody complained about and left alone the ones that were. * * SCOPE * The same two page-ids `qa16-logistik-praxis-tabbar.css` uses: 326672 and 304462. * * qa16's own comment calls these "the same /de/logistik page across envs". That is * NOT what they are, at least in this database — both are published DE pages and * both render their own `.kapitel.tabs.tabs-pills` bar: * * 326672 logistik-als-wachstumstreiber (de) <- the reported page * 304462 logistik-als-wachstumstreiber-im-e-commerce (de) <- older variant * * Carrying both is deliberate: they are two versions of the same whitepaper, qa16 * already styles both bars identically, and leaving 304462 out would make the two * diverge by a pixel. Verified 304462 renders the bar (its page carries * `page-id-304462` and one `tabs-pills`). * * 326672 is the DE ORIGINAL id, which WPML also stamps on the EN twin's * (.claude/rules/css-override.md §3), so that ONE id covers both * /de/logistik-als-wachstumstreiber and /en/logistics-as-a-growth-driver-in-ecommerce. * That is the requested behaviour: apply on the DE page too. * * (The EN clean URL is served by post 326673 through a `custom_permalink`; the * older EN twin 310408 owns the natural slug but redirects to it. Both render the * same body ids, so the scope is unaffected.) * * ONLY WHERE AN ARROW ACTUALLY EXISTS * Swiper marks an arrow `.swiper-button-disabled` at the end of its travel (the * theme fades it to `opacity:0`) and `.swiper-button-lock` when the strip does not * overflow at all, so there is nothing to page. Offsetting an arrow that is not * shown is pointless, so both states are excluded. The `:not()`s also raise * specificity to 0,7,1, which is what lets this beat qa16 — and this sheet loads * after it (the overrides loader enqueues *.css alphabetically: q… then s…). * `!important` is required because qa16's own declarations carry it. * * Verified in-browser on the dev tunnel at 1280px: * before tab-bar next arrow (enabled) right: 0px * after tab-bar next arrow (enabled) right: -1px * tab-bar prev arrow (disabled) left: 0px <- untouched, invisible * breadcrumb arrows (disabled) left: 0px <- no longer moved */ body.page-id-326672 .kapitel.tabs.tabs-pills .swiper-button-prev:not(.swiper-button-disabled):not(.swiper-button-lock), body.page-id-304462 .kapitel.tabs.tabs-pills .swiper-button-prev:not(.swiper-button-disabled):not(.swiper-button-lock) { left: -1px !important; } body.page-id-326672 .kapitel.tabs.tabs-pills .swiper-button-next:not(.swiper-button-disabled):not(.swiper-button-lock), body.page-id-304462 .kapitel.tabs.tabs-pills .swiper-button-next:not(.swiper-button-disabled):not(.swiper-button-lock) { right: -1px !important; } /* --------------------------------------------------------------------------- * Left-align the pill row when it fits inside the white bar. * * app.css centres it: * .swiper-container-free-mode > .swiper-wrapper { margin: 0 auto; } * .tabs-pills .nav-tabs { width: max-content; } * * The row is only as wide as its pills. When it OVERFLOWS the bar, the auto * margins resolve to 0 and it reads as left-aligned; when it FITS, `margin:0 auto` * centres it. So the alignment silently depends on how long the labels are. * * The German labels ("Regelbasierte Steuerung", "Effizienz & Nachhaltigkeit") are * long enough to overflow at every desktop width, so /de/ has always looked * left-aligned. The English labels are shorter: measured at 1920px the row is * 1370px inside a 1450px bar, so it centred with a 40px gap on each side. That * gap appeared only once the EN tab titles were translated in this same batch. * * Pinning the inline margins to 0 makes the alignment a property of the component * rather than of the label lengths, in both languages. On /de/ this is a no-op * today (the auto margins already compute to 0), and it keeps DE left-aligned at * any future width where the German labels would happen to fit. * * Specificity 0,6,1 (body + page-id + kapitel + tabs + tabs-pills + * swiper-container-free-mode + swiper-wrapper) vs app.css's 0,2,0, and this sheet * loads after it, so no !important is needed here -- unlike the arrow rules above, * which must out-shout qa16's own !important. * ------------------------------------------------------------------------ */ body.page-id-326672 .kapitel.tabs.tabs-pills .swiper-container-free-mode > .swiper-wrapper, body.page-id-304462 .kapitel.tabs.tabs-pills .swiper-container-free-mode > .swiper-wrapper { margin-left: 0; margin-right: 0; }