/* Hand-written overrides. DELIBERATE DEVIATIONS from the Duda original.
*
* Everything else in this build reproduces the original exactly, including its
* mistakes. Each rule here is a change we were asked to make on purpose, and
* each one records what the original does so the deviation stays visible.
*
* Loaded last, after device-switch.css, so it wins over the ported bundles.
* Nothing content-addressed lives in this file — it is not a ported sheet and
* has no hash name.
*/
/* ── Contact form status messages: white → black ──────────────────────────────
*
* Measured 2026-08-23 on both sides. On /contact the live Duda original AND our
* port render BOTH status blocks at rgba(255,255,255,1), while the backdrop
* painted by .dmInner is rgb(255,255,255). White on white: after submitting,
* the visitor sees nothing at all — neither the confirmation nor, if delivery
* fails, the error telling them the message did not send. The original has the
* same defect, so this is not a port fix; it is a change requested on top of a
* faithful port.
*
* SCOPED TO THE CONTACT PAGE ON PURPOSE, AND THE SCOPING WAS MEASURED, NOT
* ASSUMED. The home page carries both blocks too, and both sit on the dark
* green panel rgb(0,86,33) painted by .dmRespRow.u_1814709518 — success and
* error alike, checked separately rather than inferred from the success block.
* White is correct there. A site-wide rule would make the home messages
* black-on-dark-green, trading two invisible messages for two others.
*
* The ported rules are, per device, in both the -pre and -post sheets, all
* !important:
* *#dm *.dmBody div.u_1819272540 .dmform-success (1,3,1)
* *#dm *.dmBody div.u_1819272540 .dmform-success .rteBlock (1,4,1)
* *#dm *.dmBody div.dmform-error (1,2,1)
* *#dm *.dmBody div.dmform-error .rteBlock (1,3,1)
* The selectors below are (1,3,2) and (1,4,2), so they beat every one of those
* on specificity as well as loading later — no media query needed, all widths.
*
* .rteBlock is listed explicitly because the ported sheets set the colour on
* that child too; overriding only the parent leaves the text white.
*/
body[data-page-alias="contact"] #dm .dmBody div.dmform-success,
body[data-page-alias="contact"] #dm .dmBody div.dmform-error,
body[data-page-alias="contact"] #dm .dmBody div.dmform-success .rteBlock,
body[data-page-alias="contact"] #dm .dmBody div.dmform-error .rteBlock {
color: rgba(0, 0, 0, 1) !important;
}
/* ── One per page: extra s demoted to , typography preserved ─────
*
* The original carries multiple s on five pages — /services (4) and the
* four long-form posts (3 each) — which the port reproduced faithfully. Those
* extras are section headings, not page titles, so each page now keeps exactly
* one and the rest are .
*
* The tag change alone would be visible: inside div.dmContent the ported sheets
* give the two tags different type. Measured from site-{desktop,tablet,mobile}
* .css, last rule wins:
*
* h1 h2
* family Montserrat Poppins
* colour var(--color_1) var(--color_3)
* size 36px / 36px / 30px (d/t/m) 24px / 24px / 24px
*
* These rules restore the h1 side of that table, so the demoted headings render
* exactly as before — the change is semantic only, and the visual-diff gate
* still sees the original pixels.
*
* Specificity: Duda's strongest rule on these is
* *#dm div.dmContent h2, … = (1,1,2)
* and the selectors below are (1,2,2), so they win on specificity as well as on
* load order.
*
* Font-size is deliberately NOT forced. Eight of the nine demoted headings
* carry Duda's own .size-30 / .m-size-24 utilities, which are !important and
* therefore still decide their size exactly as they did as . The rules here
* only matter for the one bare on /services, which had no size class and
* took its size from the tag.
*/
#dm div.dmContent h2.gy-h1-demoted,
#dm div.dmFooter h2.gy-h1-demoted {
font-family: Montserrat, "Montserrat Fallback";
color: var(--color_1);
font-size: 36px;
}
@media (max-width: 767px) {
#dm div.dmContent h2.gy-h1-demoted,
#dm div.dmFooter h2.gy-h1-demoted {
font-size: 30px;
}
}
/* ── Legal pages (/privacy-policy, /terms-conditions) ─────────────────────────
*
* These carry no ported Duda page stylesheet, so they inherit only the site
* defaults. This gives the long-form copy a readable measure and rhythm; it
* matches the type the rest of the site already uses rather than introducing
* any new values.
*
* NOT scoped under .dmContent: that class arrives with the ported page
* fragments, and these two pages have none, so a .dmContent-scoped rule matches
* nothing here. Verified in the browser — the measure was still the full 1200px
* column until this was corrected.
*/
#dm .gy-legal {
max-width: 900px;
margin: 0 auto;
padding: 32px 20px 56px;
text-align: left;
}
#dm .gy-legal h2 {
margin-top: 32px;
margin-bottom: 8px;
}
#dm .gy-legal p {
line-height: 1.7;
margin-bottom: 12px;
}
#dm .gy-legal ul {
margin: 0 0 16px 24px;
list-style: disc;
}
#dm .gy-legal li {
line-height: 1.7;
margin-bottom: 6px;
}
#dm .gy-legal a {
text-decoration: underline;
}
/* ── Footer map: the client's Google Business Profile embed ───────────────────
*
* MIGRATION-NOTES §4 records that Duda's Mapbox widget was replaced with an
* OpenStreetMap iframe, because Duda's shared Mapbox token cannot be used off
* their platform. The client has now supplied their own GBP embed, which is
* what the QA standard asks for, so that is what the footer carries.
*
* The embed is 300px tall — the standard's cap, and the height the client's own
* code specifies. Duda sized this box at 200px for the Mapbox widget:
*
* .inlineMap { height: 200px; width: 100% }
*
* That rule still applies and would crop the embed by 100px, so the footer's
* map box is raised to match. Scoped by the element's own u_ id and to the
* footer container, so the .inlineMap sizing used elsewhere is untouched —
* there is a second map box on the contact section at 173px, and it must keep
* that height.
*
* Width is already 100% of a full-bleed row, so it spans the footer.
*/
#dm .p_hfcontainer div.u_1874139526.inlineMap,
#dm .dmFooter div.u_1874139526.inlineMap {
height: 300px;
width: 100%;
}
#dm .u_1874139526 .mapContainer,
#dm .u_1874139526 .gy-gbp-map {
height: 300px;
max-height: 300px;
width: 100%;
display: block;
border: 0;
}
/* ── Desktop dropdown items sized to match their parent ──────────────────────
*
* Duda gives the desktop nav's TOP items an explicit size but never sizes the
* submenu, so those fall through to
*
* .main-navigation.unifiednav ul { font-size: 1rem }
*
* and render at 16px — larger than the 12.5px parent they hang off. The
* original has the same mismatch; this is a requested change, not a port fix.
*
* Scoped to the standard header's own nav (u_1984095099). The mobile drawer
* (u_1282086909) and the two footer navs are deliberately untouched: the
* drawer's submenu is already smaller than its parent (12.8px under 16px), so
* matching it to the parent would make it bigger, not smaller.
*
* !important and the u_ id are Duda's own pattern for this selector — the rule
* being overridden is itself !important.
*/
#dm .p_hfcontainer nav.u_1984095099.main-navigation.unifiednav
.unifiednav__container[data-depth] .unifiednav__item,
#dm .p_hfcontainer .u_1984095099.main-navigation.unifiednav
.unifiednav__container[data-depth] .unifiednav__item {
font-size: 12.5px !important;
}
/* ── Mobile drawer close (X) is white against the green panel ────────────────
*
* The hamburger sits on a white bar when closed, where Duda's grey
* rgb(120,120,120) is correct. Open, the same button becomes the X and sits on
* the drawer's green rgb(0,132,53) — grey on green, barely visible.
*
* The bars are drawn with `border: 1px solid currentColor`, so colour is what
* moves them. Only the open state is changed; closed keeps Duda's grey.
*/
@media (max-width: 767px) {
body.dmDrawerOpen #layout-drawer-hamburger,
body.dmDrawerOpen #layout-drawer-hamburger .hamburger__slice {
color: #fff;
border-color: #fff;
}
}
/* ── Form legal line: inline with the SEND button ───────────────────────────
*
* The Privacy Policy / Terms line added under both forms inherited the body
* colour rgb(43,43,43). On /contact that is dark on white and reads fine; on
* the home page the form sits on the dark green panel .dmRespRow.u_1814709518,
* so it was dark on dark and effectively invisible.
*
* Layout: .dmformsubmit carries Duda's `R` class, which floats it left, so the
* legal line was flowing AROUND the float — starting 20px above the button's
* top and wrapping down its right-hand side. The two are now wrapped in
* .gy-form-actions (see the fragments) and laid out as one flex row, so the
* line sits on the same line as the button and starts where the button starts.
*
* The wrapper is a real element rather than a :has() rule on the row, because
* the row here IS the