/* ========================================================================== share-buttons.css — the product page "JAGA:" row. Enqueued by inc/share-buttons.php, product pages only, after single.css. THIS FILE OWNS: the four buttons. THIS FILE DOES NOT OWN: the row itself. `.ostu-share`, `.ostu-share__label` and `.ostu-share__links` keep their geometry from assets/css/single.css (lines 345-361 + the 767px block at 521), and the transition / press / reduced-motion entries for `.ostu-share__btn` keep coming from assets/css/motion.css. Nothing here duplicates those. -------------------------------------------------------------------------- WHY EVERY SELECTOR BELOW IS THREE CLASSES DEEP, and not one single.css declares the buttons at (0,1,0) and (0,2,0): .ostu-share__btn { color: var(--slate); } 0,1,0 .ostu-share__btn:hover { color: #fff; } 0,2,0 and the SAME file declares, 20 lines earlier: .single-product .product_meta a { color: var(--slate-dark); } 0,2,1 .single-product .product_meta a:hover { color: var(--green); } 0,3,1 The buttons ARE links inside .product_meta, so both of those apply to them and both WIN. Two consequences, live on the site right now: 1. rest colour is --slate-dark (#1e293b), not the --slate the button rule asks for. Cosmetic. 2. HOVER colour is --green (#047857), not the #fff the button rule asks for — while the background turns a per-channel brand colour. Measured contrast of the mark against its own hover background (WCAG 1.4.11 wants 3:1 for a non-text graphic): on Facebook #1877f2 ....... 1,30:1 FAIL — mark disappears on WhatsApp #25d366 ....... 2,77:1 FAIL on X #0f172a ....... 3,26:1 pass, but dark-on-dark That is not a style preference. It is a broken hover shipped in a file that thought it had set color:#fff. So: (0,3,0) for rest and (0,4,0) for hover/focus. Compare class counts — 3 > 2 and 4 > 3 — and the element in the losing selectors (the trailing `a`) never enters into it, because b is compared before c. These win regardless of source order; the dependency on 'ostugrupp-single' in the PHP is intent, not load-bearing. THE BRAND COLOURS ARE GONE ON PURPOSE. Four buttons that each flash their network's own colour is a widget, not this shop. One hover colour, the shop's green: #fff on #047857 = 5,48:1 (tokens.css:11 states 5,00:1 for the same pair; either number clears the 4,5:1 floor with room). ========================================================================== */ /* -------------------------------------------------------------------------- 1 - The button. TAP TARGET: 44px, the measured floor (--tap-min, tokens.css:226). `flex: 0 0 auto` is not decoration — `.ostu-share__links` is a flex row, and a flex item's default `flex-shrink: 1` lets a browser squeeze a 44px button under 44px before it wraps. The floor has to be a floor. -------------------------------------------------------------------------- */ .single-product .ostu-share .ostu-share__btn { flex: 0 0 auto; width: var(--tap-min, 44px); min-width: var(--tap-min, 44px); height: var(--tap-min, 44px); display: inline-flex; align-items: center; justify-content: center; border: 1px solid var(--border, #e2e8f0); border-radius: var(--radius, 12px); background: var(--muted, #f1f5f9); color: var(--slate, #334155); text-decoration: none; } /* The glyph. NO width/height here on purpose: inc/share-buttons.php already emits width="24" height="24" on every one of the four marks, and putting a second number on the same glyph in CSS is the exact trap inc/icons.php documents at lines 60-70. One glyph, one number, in the PHP. */ .single-product .ostu-share .ostu-share__btn svg { display: block; } /* -------------------------------------------------------------------------- 2 - Hover and focus: one state, one colour. Split into two rules rather than one selector list: if a browser ever fails to parse `:focus-visible`, an invalid selector inside a LIST discards the whole rule, and the hover would go down with it. The hover MOVEMENT (translateY(-2px)) stays where it already lives — the theme's lift idiom in single.css plus motion.css's timing. Only the colours are taken over here. -------------------------------------------------------------------------- */ .single-product .ostu-share .ostu-share__btn:hover { background: var(--green, #047857); border-color: var(--green, #047857); color: #fff; } .single-product .ostu-share .ostu-share__btn:focus-visible { background: var(--green, #047857); border-color: var(--green, #047857); color: #fff; /* Same ring a11y.css draws for every link, restated so the row still has a visible focus state when the accessibility module is switched off. Values come from a11y.css's own tokens, so when it IS on there is one ring, not two fighting ones. */ outline: var(--a11y-ring-w, 3px) solid var(--a11y-focus, #047857); outline-offset: var(--a11y-ring-offset, 2px); /* main.css:172 gives every :focus-visible element `border-radius: 4px`, at (0,1,0). On a 44px button with a 12px radius that squares the corners the instant it is focused. Pinned back here at (0,4,0). */ border-radius: var(--radius, 12px); } /* -------------------------------------------------------------------------- 3 - prefers-reduced-motion. The hover lift on this control is NOT covered by either existing guard: motion.css section 5a lists `.ostu-share__btn:active` only (pressed transforms), and a11y.css section 6 cancels five hover lifts by name and this is not one of them. With `transition-duration: .001ms` forced by a11y.css, an uncancelled lift does not soften — it JUMPS 2px, which is the case a11y.css's own comment says it exists to prevent. Cancelled here. (0,4,0) beats single.css's (0,2,0) and motion.css's (0,3,0), so no !important is needed to do it. -------------------------------------------------------------------------- */ @media (prefers-reduced-motion: reduce) { .single-product .ostu-share .ostu-share__btn:hover, .single-product .ostu-share .ostu-share__btn:focus-visible, .single-product .ostu-share .ostu-share__btn:active { transform: none; } } /* -------------------------------------------------------------------------- 4 - Mobile. The row does NOT need a breakpoint, and here is the arithmetic instead of a guess. At a 375px viewport: .container padding-inline is 18px per side below 768px (main.css:494-496) -> 375 - 36 = 339px of content .single-product div.product is `grid-template-columns: 1fr` below 768px (woocommerce.css:451), so .summary is the full 339px .product_meta adds no horizontal padding (single.css:517) The row needs: "JAGA:" 13px DM Sans 700, uppercase, +.06em tracking ~= 43px gap between label and strip (--space-12) 12px 4 buttons x 44px 176px 3 gaps x 8px (--space-8) 24px --------- 255px 255 <= 339. It fits on ONE line with 84px to spare, so the label stays beside the buttons and nothing wraps. Even at 320px (339 -> 284) there is still 29px of slack. The row only wraps below ~291px, and there `flex-wrap: wrap` on .ostu-share drops the button strip to its own line — a fallback, not a break. Nothing here is a media query because nothing here needs one. The label estimate is the one soft number above (advance widths read off DM Sans Bold, +/- ~4px). The margin is 84px; it does not turn on that. -------------------------------------------------------------------------- */