sitting between the consent checkbox and the submit button. Its only child is a span that already clips itself to 1 px, so it LOOKS empty — but the
still opens a 27 px line box, and as a flex item it also collects a row-gap on each side. Measured hole between the checkbox and the button: 44 + 27 + 44 = 115 px. display:contents does NOT fix it (still 88 px): the whitespace text nodes inside the
become anonymous flex items of their own. Taking the
out of flow does — measured 44 px, exactly one row-gap. Out of flow rather than display:none on purpose: the field stays in the DOM and still submits, which is the whole point of a honeypot, and some bots skip anything explicitly hidden. */ /*.br-form-availability .wpcf7 form > p:has(> [data-cf7apps-honeypot]), .br-form-availability .wpcf7 form > p:has(> .cf7apps-honeypot-wrap){ position: absolute; width: 1px; height: 1px; overflow: hidden; margin: 0; }*/ /* .br-form-availability .wpcf7 .column{ padding: 0; margin: 0; } .br-form-availability .wpcf7 .column > p{ margin: 0; } .br-form-availability .wpcf7 .column.one-second{ width: calc((100% - 6.47%) / 2); } */ /*.br-form-availability .wpcf7 .column > p > .wpcf7-form-control-wrap:not([data-name="date"]):not([data-name="aantal"]){ display: block; }*/ /* @media (max-width: 767px){ .br-form-availability .wpcf7 .column.one-second{ width: 100%; } }*/ /* ========================================================================== ADDRESS ON CONTACT PAGE ========================================================================== */ .br-address{ display: flex; align-items: flex-start; /* pin beside the FIRST line */ gap: clamp(14px, 1.3vw, 26px); margin: 0; font-family: var(--br-sans, sans-serif); font-style: normal; /*
italicises by default */ font-size: var(--br-fs-22); line-height: 1.4; color: var(--br-ink, #272727); } .br-address__pin{ flex: 0 0 auto; width: 1.6em; /* height follows the viewBox */ height: auto; color: var(--br-blue, #648CA7); margin-top: -.12em; /* optical align to the cap line */ } .br-address__lines{ display: block; } /* ========================================================================== 11. CUSTOM CSS ========================================================================== */ .header-logo-chateau {width: 530px; margin-left:-112px;} h2.custom {font-size: 2.1rem; line-height:2.1rem;/* border-bottom: solid 1px #fff*/; padding-bottom: 2rem;} div div.custom-001 {padding: 2rem 4rem;} h2.custom-002 { padding-top: 35px; } .ntm .vc_column-inner {padding-top:0 !important; } .ntm .vc_column_container > .vc_column-inner { padding-left: 8px !important; padding-right: 8px !important;} .ntm .wpb_wrapper > div {margin-bottom: 16px !important;} .z-10 {z-index: 10;} .custom-003 {overflow: visible !important;} .br-height-fix .wpb_wrapper {min-height: 100% !important;} .custom-004 h3 { font-weight: 600; font-size: var(--br-fs-28) !important;} .custom-005 h3 {font-size: var(--br-fs-20) !important; font-family: var(--br-sans);} .custom-005 .vc_column-inner {border-left: solid 1.4px var(--br-ink) !important; padding-left: 1.4rem !important;} /* ========================================================================== MOBILE -------------------------------------------------------------------------- This block replaces the four-line "MOBILE CORRECTIONS" that used to sit above the CONTACT FORM section. It lives at the END of the file on purpose: a media query does not raise specificity, so it has to come after the rules it overrides. FIRST, THE THING WORTH KNOWING: the XD has nine artboards and every one is 1920 px wide. Atelier 64 never drew a mobile version. So this is not "rebuilding the design at 390" — it is a set of decisions about a layout that was never designed. The ▲ marks are the places where I decided rather than derived. Those are the ones to put in front of the client. Every number below was measured on the live site at 390 px, and the whole block was injected into all nine pages and re-measured before shipping. WHAT WAS ACTUALLY WRONG ┌────────────────────────────────────────────────────┬─────────┬─────────┐ │ │ before │ after │ ├────────────────────────────────────────────────────┼─────────┼─────────┤ │ distinct left gutters on /gelegenheden/communies │ 5 │ 1 (+1) │ │ (21, 36, 54, 71 and 116 px on one page) │ │ │ │ hero logo on /landingpage │ 530 px │ 300 px │ │ rendered at −112 px: "eau de Braff" │ clipped │ fits │ │ contact form width │ 249 px │ 315 px │ │ photo mosaic height │ 1643 px │ 670 px │ │ form-card overlap swallowing the heading below it │ −240 px │ none │ │ input font-size (under 16 px = iOS zooms the page) │ 15 px │ 16 px │ │ page height, /gelegenheden/trouwfeesten │ 12087 │ 9624 │ └────────────────────────────────────────────────────┴─────────┴─────────┘ The "+1" is deliberate: a column with its own background keeps an inset, so its content sits 20 px further in than everything else. That reads as a card rather than as a misalignment. BREAKPOINTS — three, and each one is somebody else's, on purpose: 1024 where the mosaic and the gelegenheden grid already turn 767 where WPBakery stacks vc_col-sm-* and Betheme narrows its own wrapper. This is THE mobile band, so nothing lands half-stacked. 480 small phones: type and spacing only, never layout Note 767, not the 782 that .br-cols-* uses — 782 is the WordPress admin-bar breakpoint and has nothing to do with this site. Between 768 and 782 the icon grid collapses one step early, which is harmless. ONE RULE OF THUMB FOR EDITING THIS: the gutter group runs first and everything else assumes it. If you change --br-side, change it there. ========================================================================== */ /* ========================================================================== ONE FIX THAT IS NOT A WIDTH QUESTION -------------------------------------------------------------------------- Found while doing the mobile pass, but it is wrong at every width, so it sits outside the media queries. Betheme has .content_wrapper img{ height: auto } at (0,1,1), which beats .br-mosaic__img{ height:100% } at (0,1,0). An absolutely positioned image with top:0, bottom:0 AND a specified height ignores `bottom`, so every mosaic photo renders at its own aspect ratio inside a box sized by the grid — and the difference shows as a cream sliver under the photo. It is 1–2 px on most of them and 16 px on the tall one at desktop; on mobile, where the boxes are a fixed 4:5, it was up to 100 px. Worth copying this line into vc-mosaic.css so the element is correct on its own, rather than depending on this file being loaded. ========================================================================== */ .br-mosaic .br-mosaic__img{ height: 100% !important; } /* ========================================================================== TABLET ≤ 1024 — the layout still works here, this is a nudge ========================================================================== */ @media (max-width: 1024px){ /* Three formule cards get thin before they get stacked (212 px at 768). Buying back the inside padding keeps the list readable. */ .br-formule{ padding-inline: clamp(16px, 2.2vw, 28px); } } /* ========================================================================== PARTNER CARDS ≤ 900 — a Safari-only break, and why it was invisible here -------------------------------------------------------------------------- On an iPhone the "Meer info" button hung out of the bottom of the bordered card and over the top of the next one. In Chrome, at the same width, it sat correctly 23 px inside the border. Same CSS, same markup. The card is a CSS grid, and .br-partner__media carries min-height: 100%. That percentage is measured against the item's grid area — whose size depends on the item. Chrome treats the circular case as auto; Safari resolves it against the container instead, which pins the container's height, which starves the second row. The body's border box then comes out SHORTER than its own content, and the last thing in it — the button — spills out the bottom. I reproduced it exactly by forcing the card 60 px short in Chrome: the button went from 23 px inside the border to 37 px below it. That is the iPhone symptom, and the amount of spill tracks how much text each partner has — which is why card 1 looked fine and card 2 did not. The fix is not to chase Safari. min-height: 100% on the photo only ever had a job in the TWO-column desktop card (make the photo as tall as the text beside it). Once the card stacks there is nothing to match, so the percentage goes — and the card stops being a grid at all, which means there is no row sizing left to get wrong in any engine. Verified: with these rules, forcing the card 60 px short leaves the button 23 px inside the border. It cannot be starved any more. This belongs in braffe-cpt.css next to the rest of the partner CSS. It is here because that is the file you are already uploading; move it when convenient, and drop the doubled class when you do. ========================================================================== */ @media (max-width: 900px){ .br-partner.br-partner{ display: block; } .br-partner.br-partner .br-partner__media{ min-height: 0; } .br-partner.br-partner .br-partner__body{ min-height: 0; height: auto; } /* margin-top:auto pins the button to the bottom of a card that has spare height. A stacked card never does, so give it a real gap instead. */ .br-partner.br-partner .br-partner__address + .br-partner__btn{ margin-top: clamp(18px, 4vw, 28px); } /* see RATIO BOXES below. aspect-ratio has to GO, not just be supplemented — the two mechanisms fight. 16/9 = 56.25%. */ .br-partner .br-partner__media{ aspect-ratio: auto; } .br-partner .br-partner__media::before{ content: ""; display: block; padding-top: 56.25%; } } /* ========================================================================== RATIO BOXES — the systemic version of the partner bug -------------------------------------------------------------------------- Reported as "the Gelegenheden cards are gone on my iPhone": the section rendered its intro text and button, then an empty cream band where four photo cards and the CTA panel should be. THE SHAPE OF THE BUG. Three blocks on this site are built the same way: a box with an aspect-ratio, whose children are ALL absolutely positioned — the photo, the scrim, the label, the CTA panel. Nothing is in normal flow, so the box has no content height at all, and its entire height comes from aspect-ratio. Proved it rather than assumed it: setting aspect-ratio:auto on a .br-gel__card in Chrome takes it from 343 px to 0. Chrome resolves the ratio when sizing an auto grid row. Safari, for a stretched grid item in an auto row, does not — the row comes out 0 and the whole block disappears. Same CSS, same width, different answer. Which is why every one of these looked fine in my browser: .br-gel__card / .br-gel__cta the Gelegenheden grid — reported .br-mosaic__item the photo mosaic on four pages .br-partner__media the partner photos, which is ALSO why cards 2 and 3 had no image in the first iPhone screenshot — not lazy loading THE FIX is the technique aspect-ratio replaced: an empty ::before with a percentage padding-top. Percentage padding resolves against the element's own WIDTH, which is always definite here (it is the grid column), so there is no circular dependency for an engine to disagree about, and it works as a real in-flow box when the row is being sized. Ratios: 491/536 = 91.6045%, 16/9 = 56.25%, 4/5 = 125%, 16/10 = 62.5%. ── THE PART I GOT WRONG THE FIRST TIME ───────────────────────────────── Version one ADDED the spacer and LEFT aspect-ratio in place, on the reasoning that they compute the same height so they cannot conflict. They can. With both set, Safari took the definite height from the spacer and then used aspect-ratio to derive the WIDTH from it, instead of stretching the card to its grid column — so on Safari desktop the cards rendered at roughly 270×250 inside 659 px columns, two of them visible and the rest of the row gone. Worse than the original bug. One mechanism per axis. aspect-ratio is removed on every box that gets a spacer, here and in vc-mosaic.css, which was rewritten for the same reason. Verified in Chrome at 440, 900 and 1440, with aspect-ratio FORCED OFF globally to imitate the engine being defended against: gel cards 343/343/343/343 and mosaic 707 px at 440, mosaic columns 781/781/781 at 1440 — identical either way, at every width. Desktop partner media 459×433 before and after. If you add another ratio box, give it a ::before AND no aspect-ratio. Never both. ========================================================================== */ .br-gel .br-gel__card, .br-gel .br-gel__cta{ aspect-ratio: auto; } .br-gel .br-gel__card::before, .br-gel .br-gel__cta::before{ content: ""; display: block; padding-top: 91.6045%; } /* ========================================================================== MOBILE ≤ 767 ========================================================================== */ @media (max-width: 767px){ /* Same species as the partner card above: a percentage min-height against a parent with no definite height. It exists to equalise columns that sit side by side; once they stack there is nothing to equalise, and leaving it in is an invitation for the same engine disagreement. */ .br-height-fix .wpb_wrapper{ min-height: 0 !important; } /* ------------------------------------------------------------------------ 1. ONE GUTTER Four padding layers stack up and nothing cancels them: Betheme .section_wrapper ............ 33 px WPBakery's JS-written section pad ... 21 px vc_column-gap-35 ....................️ 17.5 px .vc_column-inner default ............ 15 px (theme forces it) …which is how one page ended up with content starting at five different x positions. Fix this group first: most of the "it looks cramped" symptoms are this and nothing else. ------------------------------------------------------------------------ */ :root{ --br-side: 20px; } /* Betheme's content wrapper is ~98% wide, which puts 18 px on the left and 25 on the right and throws off every full-bleed calculation downstream. Square it up before anything measures against it. */ .the_content_wrapper{ width: 100% !important; margin-left: 0 !important; margin-right: 0 !important; } /* Betheme's own wrapper drops to 33 px below 767. Take it over. */ .content_wrapper .section_wrapper, .container{ padding-left: var(--br-side); padding-right: var(--br-side); } /* A "stretch row" section is placed by WPBakery's JAVASCRIPT, which writes an inline style — left:-21.23px; width:390px; padding-left:21.23px — to pull the section to the window edge and push its content back in. Inline styles beat any normal rule, so !important here is the correct tool rather than a shortcut. Only the padding is touched: let the JS keep doing the full-bleed part. Overriding left/width/margin as well was tried and made it WORSE — the JS measures the container, so fixing the container (above) is what makes its numbers come out right. */ .vc_section{ padding-left: var(--br-side) !important; padding-right: var(--br-side) !important; } /* Column gutters separate columns that sit SIDE BY SIDE. From 767 down they are stacked, so the gutter is pure indent. */ .vc_row[class*="vc_column-gap-"] > .wpb_column{ padding-left: 0 !important; padding-right: 0 !important; } /* The row's −15 px margin and the column's 15 px padding are a matched pair in WPBakery. Betheme resets the margin on fluid rows but the theme ALSO re-forces the padding with .hero .vc_column-inner{ padding:15px !important } below 1240 px, so the 15 px survives and compounds at every nesting level. Both halves have to go, together. */ .vc_row.wpb_row.vc_row-fluid, .vc_row.wpb_row.vc_inner, .vc_row.wpb_row[class*="vc_column-gap-"]{ margin-left: 0 !important; margin-right: 0 !important; } .wpb_column:not(.vc_col-has-fill) > .vc_column-inner{ padding-left: 0 !important; padding-right: 0 !important; } /* A column WITH a background is a card and still needs an inset — but not the 2rem/4rem that was typed for a 1640 px canvas. vc_col-has-fill is the class WPBakery puts on exactly those columns, so this splits "layout padding" from "card padding" without touching a single page. */ .wpb_column.vc_col-has-fill > .vc_column-inner{ padding-left: clamp(16px, 5vw, 24px) !important; padding-right: clamp(16px, 5vw, 24px) !important; } /* From the CUSTOM CSS section at the top of this file — a 1920-canvas number: 4rem of side padding is 64 px on a 390 px screen. */ div div.custom-001{ padding: 24px 0; } /* .custom-005 — the three "Architectuur" cards on /over-ons, each a left rule plus the padding that holds the text off it. The blanket kill above stripped that padding and left the rule sitting against the text. NOTE FOR WHOEVER EDITS THIS NEXT: .custom-005 is on the ROW, not on the column, which is why the obvious .custom-005.wpb_column selector matches nothing. Check where a custom class actually lives before writing the restore rule — I got this wrong the first time. */ .custom-005 > .wpb_column > .vc_column-inner{ padding-left: 1.4rem !important; } /* THE GENERAL VERSION of that problem. The blanket kill cannot tell deliberate padding from builder default, so anything it strips by mistake has to be put back. Rather than a one-off rule every time, put br-keep-pad on the ROW or on the COLUMN and it keeps a sane inset. */ .br-keep-pad.wpb_column > .vc_column-inner, .br-keep-pad > .wpb_column > .vc_column-inner{ padding-left: clamp(16px, 5vw, 24px) !important; padding-right: clamp(16px, 5vw, 24px) !important; } /* ------------------------------------------------------------------------ 1b. VERTICAL RHYTHM BETWEEN STACKED COLUMNS Columns only ever had a HORIZONTAL gutter — WPBakery gives them nothing vertical, because at 1920 they never stack. Below 767 every one of them does, and every multi-column row on the site was running together on a 0 px seam: the three Architectuur cards read as one 700 px block of text. Measured on /over-ons before this rule: gap between stacked columns = 0. ------------------------------------------------------------------------ */ .vc_row > .wpb_column + .wpb_column{ margin-top: clamp(20px, 5vw, 32px); } /* ------------------------------------------------------------------------ 2. NO OVERLAPS margin-top: −15rem pulls a card up over the photo above it. At 1920 that reads as depth. At 390 the card is full width, so it simply covers the heading it was meant to sit beside — "Controleer beschikbaarheid" was half-hidden on /contact and on every detail page. ▲ Decision: overlap is a desktop device. Off below 767. Escape hatch: put br-keep-offset in a column's Extra class name. ------------------------------------------------------------------------ */ .wpb_column:not(.br-keep-offset) > .vc_column-inner{ margin-top: 0 !important; } /* ------------------------------------------------------------------------ 3. WIDTH UTILITIES .w-50 on a 390 px screen is a 159 px column — about four words a line. These are desktop measure controls; they have no job here. ------------------------------------------------------------------------ */ .w-50, .w-80, .w-90{ width: 100%; } .br-maxw-720, .br-maxw-880{ max-width: none; } /* ------------------------------------------------------------------------ 4. HERO Heights were 450, 550 and 720 px on different pages — not a decision, just whatever was typed into each row. One height everywhere. svh, not vh: on a phone 1vh means "viewport with the URL bar hidden", so a vh-sized hero jumps ~60 px the first time the user scrolls. ------------------------------------------------------------------------ */ .vc_row.br-overlay-bg-hero{ min-height: min(72svh, 540px) !important; } /* The two overlay bands are 50/50 at desktop. On a tall narrow crop that leaves the middle of the photo bare, and white hero text lands on it. Weight the bottom band, since that is where the text sits. */ .br-overlay-bg-hero{ --br-hero-band-top: 38%; --br-hero-band-bottom: 72%; --br-hero-overlay: .72; } /* ▲ background-position is 50% 50% everywhere. On a portrait crop of a 1920-wide photo that throws the subject away — the trouwfeesten hero becomes a close-up of a wrist. No CSS can know where the subject is: add one of these to the row, per page. */ .br-hero-focus-top { background-position: 50% 20% !important; } .br-hero-focus-bottom { background-position: 50% 85% !important; } .br-hero-focus-left { background-position: 20% 50% !important; } .br-hero-focus-right { background-position: 80% 50% !important; } /* The hero logo lockup — width:530px and margin-left:-112px in CUSTOM CSS above. It rendered from −76 px to 454 px on a 390 px screen. */ .header-logo-chateau{ width: 100%; max-width: 300px; margin-left: 0; } /* Two hero buttons side by side leave ~140 px each and both labels wrap */ .hero-btns .wpb_wrapper{ flex-direction: column; align-items: stretch; } .br-distances{ line-height: 1.8; } /* ------------------------------------------------------------------------ 5. TYPE The fluid clamp() scale already works — every .br-* heading measured at its mobile minimum. What is left is about MEASURE, not size: a line wants 45–75 characters and the big sizes give you five words. ------------------------------------------------------------------------ */ /* ▲ 27 px of pull-quote in a 288 px column is six lines of four words */ .br-testimonial, .br-statement{ font-size: var(--br-fs-25); line-height: 1.35; } .br-script-lg{ font-size: var(--br-fs-45); } /* Headings typed into WPBakery's own heading element carry a hard px size from the builder and do not scale AT ALL — the temporary homepage still renders 50 px and 35 px headings at 390. The real fix is to give them .br-h1-hero / .br-h2 instead; these two catch the ones on that page. */ .vc_custom_heading{ line-height: 1.15; } .wpb_raw_html h1 { font-size: var(--br-fs-45); line-height: 1.1; } .nanum-quote p { font-size: var(--br-fs-60); } /* "Bedrijfsevenementen" and e-mail addresses in a 350 px column */ h1, h2, h3, .br-h1-hero, .br-h2, .br-h3, .br-h2-cta{ overflow-wrap: break-word; } /* ------------------------------------------------------------------------ 6. BUTTONS The pages use WPBakery's vc_btn3, not .br-btn — which is why none of the button CSS in this file was reaching them. Both are covered here. ------------------------------------------------------------------------ */ .br-btn, .br-btn--outline, .vc_btn3-container .vc_btn3, .br-form-availability input[type="submit"]{ width: 100%; } .vc_btn3-container{ width: 100%; } /* vc_btn3 ships a hard 22 px label; the design system's is 18 fluid */ .vc_btn3-container .vc_btn3{ font-size: var(--br-fs-18); letter-spacing: var(--br-ls-wider); } .vc_btn3-container + .vc_btn3-container{ margin-top: 12px; } /* ------------------------------------------------------------------------ 7. FORMS The 16 px is not a style choice. iOS Safari zooms the whole page in when a focused field is under 16 px, and it does not zoom back out. Every field on this site was 15. ------------------------------------------------------------------------ */ .br-form-availability input, .br-form-availability textarea, .br-form-availability select, .wpcf7 input, .wpcf7 textarea, .wpcf7 select{ font-size: 16px !important; } .br-form-availability textarea, .wpcf7 textarea{ min-height: 140px; } /* Checkbox and its label on one line, with a real tap target on the box */ .wpcf7-list-item{ margin-left: 0; } .wpcf7-list-item label{ display: flex; align-items: flex-start; gap: 10px; } .wpcf7-list-item input[type="checkbox"]{ width: 20px; height: 20px; margin-top: 1px; } /* The contact map rendered 307 × 172. That is not a map. */ .wpb_gmaps_widget .wpb_wrapper, .wpb_map_wraper iframe, .wpb_video_wrapper iframe{ width: 100%; min-height: 260px; } /* ------------------------------------------------------------------------ 8. PHOTO MOSAIC vc-mosaic.css drops to ONE column at 640, which turns the block into 1643 px of scrolling — five full-width photos in a row, and the same five on four different pages. Two columns hold up fine at 354 px and the block lands at 670. ▲ The tall 991 photo goes full width as a landscape band rather than leaving a hole in the grid. The doubled class is specificity (0,2,0), so this wins whether vc-mosaic.css is enqueued before or after this file. ------------------------------------------------------------------------ */ .br-mosaic.br-mosaic{ grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 10px; } /* Heights come from the spacer only — see RATIO BOXES above. No aspect-ratio here or anywhere else on these boxes. 4:5 = 125%, 16:10 = 62.5%. One class more specific than vc-mosaic.css, so these win regardless of enqueue order. */ .br-mosaic .br-mosaic__item--617::before, .br-mosaic .br-mosaic__item--358::before, .br-mosaic .br-mosaic__item--381::before, .br-mosaic .br-mosaic__item--594::before{ padding-top: 125%; } .br-mosaic .br-mosaic__item--991::before{ padding-top: 62.5%; } .br-mosaic.br-mosaic .br-mosaic__item--991{ grid-column: 1 / -1; } /* ------------------------------------------------------------------------ 9. ICON BLOCKS (br_icontext) Four of them one per row is 500 px of near-empty column. Two up reads as a set, which is what they are. :has() picks the wrapper that actually contains icon blocks, so no page needs editing. Safari 15.4+ / Chrome 105+ — if a browser does not support it the blocks simply stay one per row, which is the old behaviour, so there is nothing to fall back to. ------------------------------------------------------------------------ */ .wpb_wrapper:has(> .br-it--column){ display: grid !important; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: clamp(20px, 5vw, 32px) 12px; align-items: start; } .wpb_wrapper:has(> .br-it--column) > *:not(.br-it){ grid-column: 1 / -1; } /* Row-direction blocks (icon left of the text) stay one per row */ .br-it--row{ gap: 14px; } /* ------------------------------------------------------------------------ 10. TESTIMONIAL SLIDER — the dots were 24 px; 44 is the smallest reliable tap target. The dot itself does not change size. ------------------------------------------------------------------------ */ .br-testimonials [class*="__dot"]{ padding: 10px; min-width: 44px; min-height: 44px; } /* ------------------------------------------------------------------------ 11. PARTNERS — once the photo and the bordered card stack, the gap between them makes two objects out of one card. ------------------------------------------------------------------------ */ .br-partner{ gap: 0; } .br-partner__body{ padding: clamp(18px, 5vw, 26px); } /* ------------------------------------------------------------------------ 12. SECTION RHYTHM — 120 px between sections is a 1920 number ------------------------------------------------------------------------ */ .br-section { padding-block: 44px; } .br-section-sm { padding-block: 28px; } .br-eq > .vc_row{ display: block; } } /* ========================================================================== SMALL PHONES ≤ 480 — type and spacing only, never layout ========================================================================== */ @media (max-width: 480px){ :root{ --br-side: 18px; } .br-quotemark{ font-size: var(--br-fs-45); } .wpb_wrapper:has(> .br-it--column){ gap: 22px 10px; } .br-mosaic.br-mosaic{ gap: 8px; } } /* ========================================================================== TOUCH — a pointer question, not a width question. A 1024 px tablet gets these; a 700 px desktop window does not. ========================================================================== */ @media (hover: none){ /* Hover transforms never fire on touch but do stick after a tap */ a.br-gel__card:hover .br-gel__img, a.br-gel__card:hover .br-gel__arrow{ transform: none; } /* Height without visual weight on the footer and inline links */ .br-fineprint a, #Footer a{ display: inline-block; padding-block: 6px; } } @media (prefers-reduced-motion: reduce){ .br-btn{ transition: none; } }