/* ==========================================================================
   WHY THIS WHOLE SHEET SITS IN @layer utilities
   ==========================================================================
   Every Tailwind utility in this theme is compiled with !important AND lives
   inside @layer utilities. Read together those two facts are decisive: among
   important declarations, CSS gives a rule inside a layer priority over an
   identical rule outside one, regardless of which stylesheet loads last. So an
   unlayered !important here could never win, and did not.

   Joining the same layer makes these rules the last ones in it, which is an
   ordinary source-order win rather than a specificity fight. Nothing outranks
   the theme's own base or components layers, which is deliberate.

   Proven on /gitelabs/ 2026-09-03: .program-grid computed to three columns of
   103px on a 390px phone with an unlayered !important, and to one column of
   358px once the same rule moved into the layer.
   ========================================================================== */

/* ==========================================================================
   GitelCare · mobile layout floor
   Mobile plan steps 1, 2 and 3. Written 2026-09-03.

   TWO VARIABLES ACCOUNT FOR NEARLY ALL OF IT, both measured rather than
   assumed, both written by The7 into wp-content/uploads/the7-css/ with no
   media query anywhere near them:

     custom.css   #main > .wf-wrap { width: 1250px }   ->  a phone is 390.
                  390 + 860 = 1250, and 860px is exactly the sideways spill
                  measured on 37 of 40 pages.

     css-vars.css --the7-base-font-size: 14px          ->  every paragraph,
                  list item and table cell inherits it. That one line is the
                  685 blocks of undersized text.

   Both of those files are GENERATED by the theme. Editing them directly would
   be silently reverted the next time anyone saves a theme option, so nothing
   here touches them. This sheet is enqueued after them and can be removed in
   one command.

   EVERYTHING IS SCOPED TO 1023px AND NARROWER. The approved desktop layout is
   not altered in any way.
   ========================================================================== */

@layer utilities {
@media screen and (max-width: 1023px) {

  /* ======================================================================
     1 · THE CONTAINER. This is the whole sideways scroll.
     ====================================================================== */
  #main > .wf-wrap,
  #bottom-bar > .wf-wrap,
  #footer > .wf-wrap,
  #header .wf-wrap,
  .page-title .wf-wrap,
  .wf-wrap {
    width: 100% !important;
    max-width: 100% !important;
    box-sizing: border-box !important;
  }

  /* The7 pads the footer 300px a side. On a 390px screen that is -210px of
     usable width. */
  #footer .wf-wrap,
  #bottom-bar .wf-wrap,
  .fancy-header .wf-wrap,
  #main > .wf-wrap,
  .page-title .wf-wrap {
    padding-left: 20px !important;
    padding-right: 20px !important;
  }

  /* the negative margins that pair with those paddings */
  .wf-container,
  .wf-container-main,
  .no-cssgridlegacy.no-cssgrid .wf-container,
  .no-cssgridlegacy.no-cssgrid .wf-container-main {
    margin-left: 0 !important;
    margin-right: 0 !important;
    max-width: 100% !important;
  }

  /* WPBakery rows and columns carry their own widths and negative margins */
  .vc_row, .vc_row-fluid, .vc_column-inner, .wpb_column,
  .vc_col-sm-12, .vc_col-sm-11, .vc_col-sm-10, .vc_col-sm-9,
  .vc_col-sm-8,  .vc_col-sm-7,  .vc_col-sm-6,  .vc_col-sm-5,
  .vc_col-sm-4,  .vc_col-sm-3,  .vc_col-sm-2,  .vc_col-sm-1 {
    max-width: 100% !important;
  }
  .vc_row[data-vc-full-width],
  .vc_row.vc_row-no-padding {
    margin-left: 0 !important;
    margin-right: 0 !important;
  }

  /* anything that can be intrinsically wider than its box */
  img, svg, video, canvas, iframe, embed, object,
  pre, code, textarea, input, select {
    max-width: 100% !important;
  }
  img, svg, video { height: auto; }
  /* a wide table scrolls inside its own box instead of pushing the page */
  table { max-width: 100% !important; display: block; overflow-x: auto; }

  /* ======================================================================
     2 · THE TEXT FLOOR. One variable, then the places that opt out of it.
     ====================================================================== */
  /* 14px is below the point at which phones begin zooming pages by
     themselves. For a practice whose patients skew older than average, this
     matters more here than on most sites. */
  :root, body {
    --the7-base-font-size: 16px;
    --the7-widget-content-font-size: 15px;
  }

  body,
  .wpb_text_column, .wpb_text_column p, .wpb_text_column li,
  .entry-content p, .entry-content li, .entry-content dd,
  .blog-content p, .post-content p, .post-content li,
  .wpb_wrapper > p, .wpb_wrapper > ul > li, .wpb_wrapper > ol > li,
  .uvc-sub-heading, .ult-responsive p,
  td, th, dd {
    font-size: max(1rem, 16px) !important;
    line-height: 1.6 !important;
  }

  /* labels, captions and metadata are scanned rather than read, so they take
     a 13px floor instead of being inflated to 16 */
  small, figcaption, .wp-caption-text, .entry-meta, .entry-meta *,
  .breadcrumbs, .breadcrumbs *, .post-meta, .post-meta * {
    font-size: max(0.8125rem, 13px) !important;
    line-height: 1.5 !important;
  }

  /* the mobile submenu is hard-coded to 14px in the generated stylesheet */
  .mobile-main-nav .sub-nav > .menu-item > a {
    font-size: 15px !important;
  }

  /* ======================================================================
     3 · TAP TARGETS. 44px for a control, per the plan.
     ====================================================================== */
  /* WCAG 2.2 Target Size (Minimum) is 24x24 and explicitly exempts a link
     sitting inside a sentence, so an inline link in body copy is deliberately
     left alone: forcing it to 44px would break the paragraph it lives in.
     Everything a patient taps ON PURPOSE is raised to 44. */

  /* buttons and form controls */
  a.button, .button, button,
  input[type="submit"], input[type="button"], input[type="reset"],
  .wpcf7-submit, .vc_btn3, .dt-btn, .dt-btn-m, .dt-btn-s,
  .wpb_button, [role="button"], .c-button {
    min-height: 44px !important;
    min-width: 44px !important;
    display: inline-flex !important;
    align-items: center;
    justify-content: center;
    padding-top: 10px !important;
    padding-bottom: 10px !important;
  }

  /* the mobile menu, which is the single most tapped thing on the site.
     Measured at 250x30 before this. */
  .mobile-main-nav a,
  .mobile-menu-tree a,
  #mobile-menu a,
  .mini-nav a,
  #main-nav > li > a, .main-nav > li > a,
  .dt-mobile-menu-icon, .mobile-menu-toggle,
  nav ul > li > a {
    min-height: 44px !important;
    display: flex !important;
    align-items: center;
  }

  /* breadcrumbs, measured at 49x21. They are navigation and they are tapped.
     Both dimensions: a "Home" crumb is only 35px wide, so height alone leaves
     it under the minimum on the axis nobody checks.

     The list itself has to become a wrapping row at the same time. Raising the
     links alone left each <li> block-level, which stacked "Home" and "2026"
     onto separate 44px lines and doubled the height of every archive page.
     Caught by rendering it, not by any of the numbers. */
  ol.breadcrumbs, .breadcrumbs {
    display: flex !important;
    flex-wrap: wrap;
    align-items: center;
    justify-content: center;
    gap: 0 2px;
    margin: 0 auto;
    padding: 0;
  }
  .breadcrumbs > li {
    display: inline-flex !important;
    align-items: center;
    float: none !important;
  }
  .breadcrumbs > li > a,
  ol.breadcrumbs a {
    min-height: 44px !important;
    min-width: 44px !important;
    display: inline-flex !important;
    align-items: center;
    justify-content: center;
    padding-left: 4px;
    padding-right: 4px;
  }

  /* social and paging controls, measured at 26x26 in the footer */
  .soc-ico a, .social a,
  .paginate a, .paginate span, .pagination a,
  #footer a, #bottom-bar a, footer a {
    min-height: 44px !important;
    display: inline-flex !important;
    align-items: center;
  }
  /* an icon-only control has no text to give it width */
  #footer a[class*="size-"], #bottom-bar a[class*="size-"], footer a[class*="size-"],
  .soc-ico a, .social a {
    min-width: 44px !important;
    justify-content: center;
  }

  /* the header logo, measured at 152x28 on 39 of 40 pages. It is the home link
     and it is tapped more than anything else in the header. The child theme
     renders it outside #header, so scoping this to #header missed every one. */
  a[class~="shrink-0"],
  .branding a, #site-title a, .logo a {
    min-height: 44px !important;
    display: inline-flex !important;
    align-items: center;
  }

  /* a WordPress menu that is not inside a <nav>. Measured at 137x20 and it is
     real navigation, not a link in a sentence. */
  ul.menu > li > a,
  .widget ul.menu > li > a,
  .menu-item > a {
    min-height: 44px !important;
    display: flex !important;
    align-items: center;
  }

  /* post meta: the category, author and date links under a post title,
     measured at 40x18. They stay on one row and the row becomes 44px tall. */
  .entry-meta {
    display: flex !important;
    flex-wrap: wrap;
    align-items: center;
    gap: 0 8px;
  }
  /* inline-block, not inline-flex. A flex container drops the whitespace
     between its items, and the author link is "By" followed by a <span> with
     the name in it, so inline-flex rendered "ByDr. Dimitri Gitelmaker".
     Padding reaches 44px without touching the text. */
  .entry-meta a,
  .entry-meta > span > a {
    display: inline-block !important;
    padding-top: 13px;
    padding-bottom: 13px;
  }

  /* a link nested inside a heading, measured at 48x24. The earlier rule used a
     direct-child selector and these sit under <strong>.

     Padding, never inline-flex. An inline-flex box sizes to max-content, so a
     three-line post title would stop wrapping and put the sideways scroll
     straight back. The hit area grows, the text still wraps. */
  h1 a, h2 a, h3 a, h4 a, h5 a, h6 a,
  .entry-title a {
    display: inline-block;
    padding-top: 11px;
    padding-bottom: 11px;
  }
  /* an accordion header is a real control and its text is short */
  .wpb_accordion_header a, .ui-accordion-header a {
    min-height: 44px !important;
    display: flex !important;
    align-items: center;
  }

  /* ---- the footer carries the practice's own address and phone number.
     Those are content a patient reads, not decoration, and they were
     rendering at 13 and 14 pixels. Tailwind's own label classes keep their
     smaller sizes so the footer's hierarchy survives. ---- */
  #footer, footer, #bottom-bar,
  #footer p, footer p, #footer span, footer span,
  #footer li, footer li, #footer address, footer address {
    font-size: max(1rem, 16px) !important;
  }
  #footer .text-sm, footer .text-sm, #bottom-bar .text-sm {
    font-size: max(0.875rem, 14px) !important;
  }
  #footer .text-xs, footer .text-xs, #bottom-bar .text-xs {
    font-size: max(0.8125rem, 13px) !important;
  }

  /* ---- the last named offenders, each measured rather than guessed at ---- */

  /* a category chip reached 46px tall but stayed 40px wide. Height alone is
     half a fix. */
  .entry-meta a, .entry-meta > span > a { min-width: 44px !important; }

  /* post tags live in .post-meta, not .entry-meta, so the rule above missed
     them. Measured at 151x18, 60x18 and 40x18. */
  .post-meta a, .entry-tags a {
    display: inline-block !important;
    min-width: 44px !important;
    padding-top: 13px;
    padding-bottom: 13px;
  }

  /* the share row, measured at 350x39 on 17 pages: five pixels short */
  .single-share-box a, .share-buttons a {
    min-height: 44px !important;
    display: inline-flex !important;
    align-items: center;
    justify-content: center;
  }

  /* pagination. The earlier rule used .paginate; this theme writes .paginator
     and the current page number measured 8x19. */
  .paginator a, .paginator span, a.page-numbers, .page-numbers {
    min-width: 44px !important;
    min-height: 44px !important;
    display: inline-flex !important;
    align-items: center;
    justify-content: center;
  }

  /* "read more", and a link inside a table cell or a subheading */
  a.more-link, .more-link, .uvc-sub-heading a {
    min-height: 44px !important;
    display: inline-flex !important;
    align-items: center;
  }
  td a, th a {
    display: inline-block !important;
    padding-top: 11px;
    padding-bottom: 11px;
  }

  /* an inline link inside a sentence stays inline. This undoes any of the
     rules above that would otherwise capture one. */
  p a, li p a, .entry-content p a, .wpb_text_column p a {
    min-height: 0 !important;
    min-width: 0 !important;
    display: inline !important;
    padding-top: 0;
    padding-bottom: 0;
  }
}
}


/* ==========================================================================
   6 · THE COLUMNS THAT NEVER STACKED
   ==========================================================================
   THE CAUSE, and it is the third one-liner on this site.

   The templates already ask for this. They are written as
       class="program-grid grid grid-cols-3 gap-6 max-md:grid-cols-1"
   and .max-md\:grid-cols-1 really is compiled, in custom-dev.css, inside a
   max-width:48rem query. Nothing is missing.

   The problem is the ORDER. Two separate Tailwind builds ship in this theme:

       custom-dev.css     has .grid-cols-3  AND  .max-md\:grid-cols-1
       bundle-style.css   has .grid-cols-3  and  NOT the mobile variant
                          and is enqueued AFTER it, declared as depending on it

   Both selectors are a single class, so they carry identical weight and source
   order decides. bundle-style.css comes last, so plain .grid-cols-3 wins at
   every width, phone included. Measured on a 390px screen: three columns of
   103px each, which is about one word per line.

   The fix is not to reorder the enqueues, which would change the cascade for
   everything else in two large stylesheets. It is to re-assert the intent from
   a sheet that loads last.

   auto-fit rather than a fixed count, so this holds at every width instead of
   trading one hard-coded breakpoint for another: a column is at least 15rem
   wide OR the full container, whichever is smaller. One column fits a phone,
   two fit a tablet, and the desktop layout above 768px is never reached.
   ========================================================================== */
@layer utilities {
@media screen and (max-width: 48rem) {

  .grid-cols-2, .grid-cols-3, .grid-cols-4, .grid-cols-5, .grid-cols-6,
  .sm\:grid-cols-2, .sm\:grid-cols-3, .md\:grid-cols-2, .md\:grid-cols-3,
  .lg\:grid-cols-2, .lg\:grid-cols-3, .lg\:grid-cols-4 {
    grid-template-columns: repeat(auto-fit, minmax(min(100%, 15rem), 1fr)) !important;
  }

  /* short figures can still sit two-up: a stat is a number and a word, not a
     paragraph, and stacking five of them makes a page nobody scrolls */
  .stat-grid {
    grid-template-columns: repeat(auto-fit, minmax(min(100%, 8.5rem), 1fr)) !important;
  }

  /* where the markup asked for exactly one column, give it exactly one */
  .max-md\:grid-cols-1,
  .max-lg\:grid-cols-1,
  .max-sm\:grid-cols-1 {
    grid-template-columns: minmax(0, 1fr) !important;
  }

  /* the named rows from the templates, so intent survives a class rename */
  .program-grid, .process-grid, .benefit-grid, .section-grid, .why__inner,
  .card-grid, .feature-grid, .icon-grid, .grid-cards {
    grid-template-columns: repeat(auto-fit, minmax(min(100%, 15rem), 1fr)) !important;
  }

  /* a flex row of real content, as opposed to a row of icons, wraps rather
     than squeezing. Rows whose children are all small are left alone, because
     those are star ratings and social icons and they are correct as they are. */
  .flex-row-wrap, .items-stretch.flex, .justify-between.flex.gap-6,
  .md\:flex-row, .lg\:flex-row {
    flex-wrap: wrap !important;
  }
}
}


/* ==========================================================================
   7 · FORMS
   ==========================================================================
   Measured on the consultation page at 390px before this: the booking form
   iframe rendered 1,210 pixels wide. A patient sees roughly a third of it and
   cannot reach the rest, on the page whose entire job is taking bookings.

   Section 1 already clamps every iframe to the container. What follows is the
   rest of what a form needs on a phone, which no width fix supplies.
   ========================================================================== */
@layer utilities {
@media screen and (max-width: 1023px) {

  /* 16px is not a style preference here. Safari on iOS ZOOMS THE WHOLE PAGE
     when a field smaller than 16px receives focus, and it does not zoom back
     out. That single behaviour is why a form can feel broken on an iPhone and
     fine on every desktop it was tested on. */
  input:not([type="checkbox"]):not([type="radio"]):not([type="hidden"]),
  select, textarea {
    font-size: max(1rem, 16px) !important;
    max-width: 100% !important;
    box-sizing: border-box;
  }

  /* a field is a tap target too */
  input:not([type="checkbox"]):not([type="radio"]):not([type="hidden"]),
  select {
    min-height: 44px !important;
  }
  textarea { min-height: 88px !important; }

  /* a checkbox or radio is small by design, so the LABEL carries the target */
  input[type="checkbox"] + label, input[type="radio"] + label,
  label:has(> input[type="checkbox"]), label:has(> input[type="radio"]) {
    min-height: 44px;
    display: inline-flex;
    align-items: center;
  }

  /* full width, because a half-width field on a 390px screen is 175px */
  .wpcf7 input:not([type="checkbox"]):not([type="radio"]):not([type="submit"]),
  .wpcf7 select, .wpcf7 textarea,
  form input:not([type="checkbox"]):not([type="radio"]):not([type="submit"]):not([type="hidden"]),
  form select, form textarea {
    width: 100% !important;
  }

  /* a two-up field row becomes one-up */
  .wpcf7 .row, .form-row, .field-row, .wpcf7-form .grid {
    display: block !important;
  }

  /* the embedded booking forms. Section 1 clamps the width; height has to be
     free to grow, because the same form is far taller at 350px than at 1210
     and a fixed height would clip the submit button out of existence. */
  iframe[src*="leadconnectorhq"],
  iframe[src*="msgsndr"],
  iframe[src*="google.com/maps"] {
    width: 100% !important;
    max-width: 100% !important;
    min-height: 26rem;
  }

  /* the error and success messages, which are worth reading */
  .wpcf7-response-output, .wpcf7-not-valid-tip {
    font-size: max(0.875rem, 14px) !important;
  }
}
}


/* ==========================================================================
   8 · THE STICKY HEADER, AND TAPPING THROUGH TO A SECTION
   ==========================================================================
   The header is 84px tall and sticky at the top of every page. Nothing accounts
   for it when the page jumps to an anchor, so the heading a patient just tapped
   lands underneath it and the section appears to start mid-sentence. That is
   the clipped "How it works" heading.

   scroll-padding-top is the whole fix and it applies at every width, because
   the header is sticky on desktop as well.
   ========================================================================== */
html {
  scroll-padding-top: 6rem;
  scroll-behavior: smooth;
}
@media (prefers-reduced-motion: reduce) {
  html { scroll-behavior: auto; }
}
:target {
  scroll-margin-top: 6rem;
}

/* ==========================================================================
   Reduced motion, honoured at every width. Not part of either plan, but it is
   one line and it is a WCAG requirement the site did not meet.
   ========================================================================== */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.001ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.001ms !important;
    scroll-behavior: auto !important;
  }
}

/* ==========================================================================
   9 · THREE DEFECTS FOUND BY JORDAN ON 3 SEPTEMBER, ALL MEASURED
   ==========================================================================
   Added after he opened staging on a real phone and found things the numbers
   had all reported as clean. Each of these is named with whose fault it is,
   because that is the only way the next one gets caught earlier.
   ========================================================================== */
@layer utilities {
@media screen and (max-width: 1023px) {

  /* ---- 9a · THE GIANT ICONS.  NOT OURS. --------------------------------
     An inline <svg> that carries a viewBox and no width or height fills its
     container: that is the SVG default, not a bug in any stylesheet. The7
     ships several unsized ones, and on the LIVE site they render 1210 x 1210
     pixels. Nobody ever saw them because they sat inside the 860 pixels of
     page that ran off the side of the screen. Fixing the sideways scroll
     pulled them into view, which is why they look new and are not.
     Measured on /what-is-peptide-therapy/: 1210px on live, 350px on staging. */
  .share-link-icon svg,
  .single-share-box svg,
  .share-buttons svg,
  .nav-links a svg,
  a.nav-previous svg,
  a.nav-next svg,
  .searchform a.submit svg,
  .searchform button svg,
  .paginator svg,
  .paginate svg {
    width: 1.5rem !important;
    height: 1.5rem !important;
    flex: 0 0 auto;
  }
  /* a safety net for the same shape elsewhere, scoped to icons inside a
     control so a decorative illustration is never caught by it */
  a > svg:not([width]):not([height]),
  button > svg:not([width]):not([height]) {
    max-width: 2rem;
    max-height: 2rem;
  }

  /* ---- 9b · THE 5 PIXEL OVERHANG.  MINE. -------------------------------
     WPBakery uses a 25px gutter: every row is pulled out by -25px and every
     column pads back in by +25px, so the two cancel. I set the container
     padding to 20px, and 20 - 25 = -5. Every WPBakery section on the site
     therefore started 5 pixels off the left edge, which is the blue panel
     hanging past the black one in the screenshot.

     Rather than tune one number against another and hope, the gutter is
     removed on mobile and everything aligns to the container's own padding.
     One source of truth for the left edge instead of two that must agree. */
  .vc_row,
  .vc_row-fluid {
    margin-left: 0 !important;
    margin-right: 0 !important;
  }
  .vc_row > .vc_column_container > .vc_column-inner,
  .vc_row > .wpb_column > .vc_column-inner {
    padding-left: 0 !important;
    padding-right: 0 !important;
  }

  /* ---- 9c · SECTIONS THAT RUN UNDER THE STICKY HEADER ------------------
     The header is 84px and sticky. A full-bleed coloured section whose first
     line sits at the very top of it loses that line behind the header when a
     visitor arrives mid-page from a menu tap. Section 8 fixes the jump; this
     gives the section itself breathing room so the heading is never flush. */
  .vc_row.vc_row-has-fill > .vc_column_container,
  section[class*="bg-"] > .container,
  .default-hero__container {
    padding-top: max(1.25rem, env(safe-area-inset-top));
  }
}
}

/* ==========================================================================
   10 · THE BLACK BANDS ABOVE AND BELOW THE CONSULTATION PANEL
   ==========================================================================
   NOT OURS. Present on the LIVE site, on desktop, right now. Measured on
   /programs/transform360/ at 1440px: black at y=2990, blue at y=3030, black
   again at y=3300. Identical on staging. It has always been there.

   THE CAUSE, and it took four wrong theories to find because every one of them
   was about backgrounds:

       border-top: 40px solid rgb(0, 0, 0)
       border-bottom: 40px solid rgb(0, 0, 0)

   The row has a forty pixel solid BLACK BORDER. Not a background, not an
   overlay, not a pseudo element. Ultimate Addons paints the row's colour with
   an absolutely positioned layer which sits inside the border box, so the blue
   starts exactly forty pixels down and ends forty pixels early, and the border
   paints black in both gaps.

   Almost certainly a width set without a colour: an unstyled border inherits
   the text colour, which here is black. It reads as spacing in the builder and
   renders as two dark bands on the page.

   WHY IT LOOKED NEW ON A PHONE
   The row used to be 1,260 pixels wide starting at -5, running off both sides
   of the screen, so the bands ran off with it. Fixing the sideways scroll
   brought the row onto the screen and the bands came with it.

   THE FIX, and why it is safe
   Surveyed 37 rows across six pages: exactly THREE carry any border at all,
   and all three are this same panel, repeated on the consultation, services
   and membership pages. Every other row on the site has none. Making a row
   border transparent therefore changes nothing else today, and the row's own
   background is clipped to the border box, so the blue simply fills the space
   the border was occupying. Same height, same spacing, no black.

   ⚠ If a row border is ever genuinely wanted later, this rule has to be
   narrowed to the specific class rather than quietly worked around.

   NOT scoped to mobile, because the bug is not scoped to mobile. It is a
   visible change to the approved desktop look, it is on staging only, and it
   is for Jordan and Myron to accept or reject on sight.
   ========================================================================== */
@layer utilities {
  .vc_row {
    border-color: transparent !important;
  }
}

/* --------------------------------------------------------------------------
   10b · and make the band a clean rectangle rather than a stepped one
   --------------------------------------------------------------------------
   Making the border transparent removed the black, but left the panel stepped:
   the two forty pixel ends are 350 wide, the middle is 390, because the colour
   layer is full bleed and the border area is not.

   Converting the border into padding keeps the panel exactly the same height
   and the same internal spacing, and lets the colour layer cover the whole of
   it, because that layer is positioned against the padding box. One solid
   rectangle instead of three stacked widths.

   Targeted at the one class that carries the fault, found by surveying every
   row on six pages, so nothing else on the site can be affected. If the
   practice ever edits this row in the builder the class changes and this rule
   simply stops applying, which is the correct failure.
   -------------------------------------------------------------------------- */
@layer utilities {
  .vc_custom_1685665427188 {
    border-top-width: 0 !important;
    border-bottom-width: 0 !important;
    padding-top: 40px !important;
    padding-bottom: 40px !important;
  }
}