/* ============================================================ wcag-c0051-gs-balcony.css WCAG 2.1 Level AA override for the C0051-GS-Balcony Kentico template (TemplateId 1366). Selectors verified against the live base CSS pulled from https://livethelaurels.com on 2026-05-07. IMPORTANT — this template namespaces all base rules under .template-balcony (set by a wrapper div inside ). All overrides below carry that prefix to match base specificity. Several base rules use !important on outline:none and box-shadow:none, so our focus rules use !important to win. Specificity strategy: Every selector is prefixed with `body #form` (the ASP.NET WebForms page-level form ID, present on every page and wrapping all our target elements). That adds (1, 0, 2) to each rule's specificity, lifting our overrides above the widget-CSS bundles that load via rpWebpartCss_*. Combined with the `.template-balcony` namespace already in each selector, rules sit at (1, 3+, 2+). ============================================================ */ /* ------------------------------------------------------------ WCAG 2.4.7 Focus Visible Base suppresses outlines on: .template-balcony a:hover, .template-balcony a:focus { outline-color:transparent; outline-style:none } .template-balcony .btn-primary:hover ... { outline:none !important } .template-balcony .contact-form ... :focus { outline:none; box-shadow:none !important } .template-balcony .floorplan-search-bar .floorplan-search-moveindate:focus { outline:none } .template-balcony .contact-widget .contactus-float-input-div input:focus { outline:none } .footer-widget footer a:focus { outline:none } Restore visible focus rings. ------------------------------------------------------------ */ body #form .template-balcony a:focus-visible, body #form .template-balcony button:focus-visible, body #form .template-balcony .btn:focus-visible, body #form .template-balcony .btn-primary:focus-visible, body #form .template-balcony input:focus-visible, body #form .template-balcony select:focus-visible, body #form .template-balcony textarea:focus-visible, body #form .template-balcony .navbar-toggle:focus-visible, body #form .template-balcony .dropdown-toggle:focus-visible, body #form .template-balcony .contact-form .form-control:focus-visible, body #form .template-balcony .contact-us-enhanced .form-control:focus-visible, body #form .template-balcony .contact-widget input:focus-visible, body #form .template-balcony .contact-widget textarea:focus-visible, body #form .template-balcony .floorplan-search-bar .floorplan-search-moveindate:focus-visible, body #form .template-balcony [tabindex]:focus-visible, body #form .template-balcony [role="button"]:focus-visible, body #form .footer-widget footer a:focus-visible { /* Webkit-style two-ring halo: blue inner ring + white outer ring gives focus visibility on both light AND dark backgrounds. The `outline` declaration is intentionally omitted — outline paints on top of box-shadow and would cover the white ring. */ outline-offset: 2px !important; box-shadow: 0 0 0 2px #005fcc, 0 0 0 3px #fff !important; } /* WCAG 2.4.13 AAA (Focus Appearance) — PME-507688 rework (Will Sharp, manual scan 2026-08-24): the shared blue+white ring above doesn't reliably clear 3:1 against every property's footer background (footers commonly run darker/branded compared to the form fields and buttons this shared rule also covers). Override just the footer link ring with a white+black double ring — one leg always clears 3:1 against any single backdrop, the same treatment already used for the Floor Plans V4 focus rings. Scoped narrowly to `.footer-widget footer a` so the inputs/selects/tabindex/role=button elements above, which were not flagged, keep their existing ring. */ body #form .footer-widget footer a:focus-visible { box-shadow: 0 0 0 2px #fff, 0 0 0 4px #000 !important; } /* ------------------------------------------------------------ WCAG 2.4.11 Focus Not Obscured Base header is position:fixed with height:84px (.template-balcony header). Reserve scroll space + a small visual buffer. ------------------------------------------------------------ */ html { scroll-padding-top: 100px; } body #form .template-balcony :focus-visible { scroll-margin-top: 100px; } /* ------------------------------------------------------------ WCAG 1.4.11 Non-text Contrast (form controls) Base: .template-balcony .contact-us-enhanced .form-group .form-control { border:2px solid #abaaab; border-width:0 0 2px } #abaaab on white ≈ 3.05:1 — borderline. Bump to #595959 (7:1). ------------------------------------------------------------ */ body #form .template-balcony .contact-us-enhanced .form-group .form-control, body #form .template-balcony .contact-form .form-control, body #form .template-balcony .contact-widget .contactus-float-input-div input, body #form .template-balcony .contact-widget .contactus-float-input-div textarea { border-color: #595959 !important; } /* ------------------------------------------------------------ WCAG 1.4.3 Contrast Minimum (footer disclosure only) The base rule `.template-balcony a { color:#919191 }` technically fails 4.5:1 on white, but we do NOT override the color here. Reason: shared template injection applies to every Greystar property on this template, and properties apply their own brand colors to body links. A blanket `color: #595959` would override per-property branding. If a specific property's brand color fails Silktide, fix it at that property's site-CSS level. We DO bump the footer-disclosure opacity (no brand impact). ------------------------------------------------------------ */ body #form .footer-widget footer .footer-disclosure { opacity: 0.85; } /* ------------------------------------------------------------ WCAG 1.4.1 Use of Color (inline links) Underline inline content links so they're distinguishable without color. Scoped to body-content containers only — bare `p a` / `li a` / `dd a` selectors would bleed into footer nav (which uses `

` for menu links) and footer disclosure (`
`), so we anchor to actual content containers instead. TFS 2985969 — added a parent-agnostic `.template-balcony .callout a`. The homepage welcome-paragraph links were colour-only because their callout hangs off a widget, not off any of the containers above. Confirmed live on estebanpark.com — 3 prose links ("South Mountain Park", "downtown Phoenix, AZ", "one, two, or three-bedroom floor plans") render gray-on-gray with no underline at rest, hover or focus. Chain: main#main-content > .page.page-Home > .gallery-accordion-widget.row > .container-fluid > .col-sm-10.col-sm-offset-1.callout > p.MsoNormal > span > a Note `.container-fluid` WITHOUT `.main`, so `.container-fluid.main a` misses it; there is no `.about-section` or `.neighborhood-widget` ancestor either, so the homepage `.callout a` rules further down miss it too. Matching on `.callout` alone catches this widget-hosted callout and any future one (86 Balcony sites); the base itself treats `.callout` as a content block — it only ever styles `.callout h1/h2/h3`, `.callout p` and `.callout ol/ul` (RPcssMaster_C0051-GS-Balcony.css:238-311, :4297). No !important counter is needed on this template: unlike Jackson-Square and Zen-Garden, the Balcony base contains no `text-decoration ... !important` declaration anywhere, so a rest-state underline holds through hover/focus/active. TFS 2985969 — also added `#contactusPrivacy a`, which the Elan, Jackson-Square and Teracy overrides already carry but this file omitted. Measured colour-only at rest on both estebanpark.com and terrazzoapartments.com. Live chain: .template-balcony > main#main-content > .page.page-Home > .container-fluid > .contact-widget > .box > .col-md-8 > … > div#pnlMobile.mobile.cf-pnlMobile > .contact-mobile-form > div#contactusPrivacy.contactus-float-input-div.privacy > a It is inside `#pnlMobile.mobile`, i.e. the mobile contact form — user-facing at mobile viewports. The wrapper's `timeout-error-contact` class is NOT a hider: it is hardcoded on the always-rendered panel (ContactUsFloating.ascx:223) and only namespaces an optional child `.timeout-message`. The earlier "occluded fallback panel, not confirmed user-facing" caution in the plan misread that state-hook class. ------------------------------------------------------------ */ body #form .template-balcony .container-fluid.main a, body #form .template-balcony .col-sm-12.content a, body #form .template-balcony .main-content-text a, body #form .template-balcony .inner-page-main-content a, body #form .template-balcony .callout a, body #form #contactusPrivacy a { text-decoration: underline; text-underline-offset: 2px; } body #form .template-balcony a.btn, body #form .template-balcony a.button, body #form .template-balcony .btn, body #form .template-balcony .btn-primary, body #form .template-balcony header a, body #form .template-balcony nav a, body #form .template-balcony .navbar a, body #form .template-balcony .navbar-collapse a, body #form .template-balcony .cta-header-btn, body #form .template-balcony .header-CTA-button, body #form .template-balcony .footer-CTA-Button, body #form .template-balcony a.more-link, body #form .template-balcony a.less-link, body #form .footer-widget footer a { text-decoration: none; } /* TFS 2985969 — CTA/heading opt-out for the parent-agnostic `.callout a` coverage above. A callout is frequently used as a standalone call-to-action whose entire heading is the link (e.g. terrazzoapartments.com "LEASE NOW"); the base defines `.callout.cta` and `.callout h1/h2/h3` for exactly that shape. Those are button/heading links, not inline prose, so they must stay un-underlined. Specificity is deliberately kept at the `.callout` level: `.callout h2 a` is (1,2,3), which beats the new `.callout a` (1,2,2) but still loses to the already-shipped TFS 2870264 rules `.about-section .callout a` / `.neighborhood-widget .callout a` (1,3,2). That is intentional — this opt-out guards only the newly-widened coverage and does not change the previously-shipped behaviour in those two scopes. Also re-asserts the shape-based opt-outs from the block above that `.callout a` (1,2,2) would otherwise out-specify: `.btn-primary` / `.cta-header-btn` / `.header-CTA-button` / `.footer-CTA-Button` are only (1,2,1). (`a.btn`, `a.button`, `a.more-link`, `a.less-link`, `.navbar a` and `.navbar-collapse a` are already (1,2,2) and win on source order.) */ body #form .template-balcony .callout h1 a, body #form .template-balcony .callout h2 a, body #form .template-balcony .callout h3 a, body #form .template-balcony .callout h4 a, body #form .template-balcony .callout a.btn, body #form .template-balcony .callout a.button, body #form .template-balcony .callout a.btn-primary, body #form .template-balcony .callout a.cta-header-btn, body #form .template-balcony .callout a.header-CTA-button, body #form .template-balcony .callout a.footer-CTA-Button, body #form .template-balcony .callout a.more-btn, body #form .template-balcony .callout a.more-link, body #form .template-balcony .callout a.less-link { text-decoration: none; } /* TFS 2985969 — PR review follow-up (Amirson Baybin): the parent-agnostic `.callout a` rule above is deliberately unscoped so it reaches any `.callout`-classed container, current or future, across all 86 Balcony sites. Confirmed via repo search that today's only `.callout` usages are content-area (C0051-GS-Balcony-Home.ascx welcome section, the Amenities widget, the contact-form panel) — none inside `
`/`
`/ `.navbar`/`
`. But `.callout` is a generic layout class name used elsewhere in the codebase on chrome (e.g. M0034_Targa.ascx's `
`), so this is a defensive guard, not a response to an observed bug: if a `.callout` div is ever nested inside this template's header/nav/footer, this rule — not the broader `header a`/`nav a`/`footer a` opt-out above — is what would actually win, because `.callout` adds a class to the selector and the existing chrome opt-out (1,1,3) loses to `.callout a`'s (1,2,2) on class-count before element-count is ever compared. This block matches that count and adds the element depth to win outright: `header .callout a` etc. are (1,2,3), beating (1,2,2) on tiebreak. PR review follow-up #2 (Melissa Gibson): the descendant-form guards below only match `.callout` nested INSIDE header/nav/footer — they miss the case where `.callout` sits directly ON the chrome element itself, e.g. `
` (Templates/Shared/M0034_Targa.ascx:41 and RPpage_Ls-Master.ascx:41). Added self-match variants (`footer.callout a`, `header.callout a`, `nav.callout a`) alongside the descendant forms to cover both shapes; specificity is identical either way (1,2,3), still beating (1,2,2). */ body #form .template-balcony header .callout a, body #form .template-balcony header.callout a, body #form .template-balcony nav .callout a, body #form .template-balcony nav.callout a, body #form .template-balcony .navbar .callout a, body #form .template-balcony .navbar-collapse .callout a, body #form .footer-widget footer .callout a, body #form .footer-widget footer.callout a { text-decoration: none; } /* ------------------------------------------------------------ TFS 2870264 — WCAG 1.4.1 (homepage inline links) Balcony's homepage uses `.about-section` (the welcome row with three `.col-md-4` text columns: `
` + `
`) and `.neighborhood-widget` (same pattern). `.callout` holds the section heading; rich-text paragraphs sit in `.col-md-4 > p`. The "more" link uses `` — already opted out via `a.more-link` above; explicit opt-out here for the matching `more-btn` class too. ------------------------------------------------------------ */ body #form .template-balcony .about-section .col-md-4 a, body #form .template-balcony .about-section .col-md-4 p a, body #form .template-balcony .about-section .callout a, body #form .template-balcony .neighborhood-widget .col-md-4 a, body #form .template-balcony .neighborhood-widget .col-md-4 p a, body #form .template-balcony .neighborhood-widget .callout a { text-decoration: underline; text-underline-offset: 2px; } body #form .template-balcony .about-section a.more-btn, body #form .template-balcony .neighborhood-widget a.more-btn, body #form .template-balcony a.more-btn, body #form .template-balcony .more-btn { text-decoration: none; } /* ------------------------------------------------------------ WCAG 2.2 AA 2.5.8 Target Size (Pointer) ------------------------------------------------------------ */ body #form .footer-widget footer a { line-height: 24px; margin: 5px 0; display: inline-block } /* ------------------------------------------------------------ WCAG 1.4.3 Contrast Minimum — "Get Directions" button TFS 2870466 Base: .btn-primary { background:#00A0B0; color:#fff; } White on #00A0B0 ≈ 3.13:1 — fails the 4.5:1 normal-text threshold. At 20px (~15pt) bold, the text qualifies as "large text" per WCAG (14pt+ bold), which only requires 3:1 contrast — so bolding lets the existing palette pass. ------------------------------------------------------------ */ .template-balcony a.btn.btn-primary.btn-lg[href*="maps.google.com"] { font-weight: bold; } /* ------------------------------------------------------------ TFS 2985969 — Google Maps bleed opt-out (measured live) The Maps JS API injects its own colour-only anchors ("Terms", "Report a map error", "Open this area in Google Maps") into `.gm-style` INSIDE our content containers, so a container-scoped underline rule reaches them. Confirmed live on Elan /About.aspx, themckenzieapts.com home, and both Balcony homepages. These are third-party map chrome, not site prose — never underline them. `!important` and the `body #form` prefix are both required so this beats the content-container counters in this file family, including the `underline !important` interaction-state counters on Jackson-Square and Zen-Garden. States are listed explicitly because those counters are state-scoped. ------------------------------------------------------------ */ body #form .gm-style a, body #form .gm-style a:hover, body #form .gm-style a:focus, body #form .gm-style a:active, body #form .google-map-container a, body #form .google-map-container a:hover, body #form .google-map-container a:focus, body #form .google-map-container a:active, body #form .gm-style-cc a, body #form a[href*="maps.google.com/maps?ll="], body #form a[href^="https://www.google.com/maps/@"] { text-decoration: none !important; } /* ------------------------------------------------------------ TFS 2905632 - WCAG 1.4.1 Use of Color (selected state) The Floor Plans bed/bath filter and view-switch tabs mark the selected item with a brand-color background + #fff text only (base rule sets border-color:transparent, no weight/underline). Add an underline so the selection is perceivable in greyscale and for color-blind users. `body #form` prefix keeps specificity above the rpWebpartCss_Floorplan* base bundles. No color changed. ------------------------------------------------------------ */ body #form .fp2-bed-bath ul li.active > a, body #form .FloorPlansV2 .fp-switch-tabs .btn-default.active, body #form .FloorPlansV3 .fp-switch-tabs .btn-default.active { text-decoration: underline; text-underline-offset: 3px; } /* ------------------------------------------------------------ TFS 2905631 - WCAG 1.4.11 Non-text Contrast (form controls) The full-width Neighborhood search input has no perceivable resting border: base CSS (rpWebpartCss_NeighborhoodFullWidth.css) sets `border:none; background:none; color:#fff` on a dark rgba(0,0,0,.83) search overlay. Add a light 1px boundary at #cfcfcf (~9.6:1 on that dark surface; matches the widget's existing placeholder color). All 21 priority templates use this dark default - none override it to a light surface. ------------------------------------------------------------ */ body #form .neighborhood-widget .neighborhood-widget__search .form-group .form-control { border: 1px solid #cfcfcf; } /* WCAG 2.2 AA 2.5.8 Target Size (Pointer) — real fix (native checkbox can't be padded; appearance:none + explicit 24px sizing; :checked::after re-draws the check so consent UX is preserved) */ body .contact-mobile-form input[type="checkbox"], #contactusPrivacy input[type="checkbox"], #privacyDiv input[type="checkbox"], #contactUsV1Privacy input[type="checkbox"] { -webkit-appearance: none; appearance: none; width: 24px; height: 24px; min-width: 24px; min-height: 24px; margin: 4px; padding: 0; border: 2px solid currentColor; border-radius: 3px; background: #fff; cursor: pointer; position: relative; vertical-align: middle; flex: 0 0 auto; } body .contact-mobile-form input[type="checkbox"]:checked::after, #contactusPrivacy input[type="checkbox"]:checked::after, #privacyDiv input[type="checkbox"]:checked::after, #contactUsV1Privacy input[type="checkbox"]:checked::after { content: ""; position: absolute; left: 7px; top: 3px; width: 6px; height: 11px; border: solid #1a1a1a; border-width: 0 2px 2px 0; transform: rotate(45deg); } body .contact-mobile-form input[type="checkbox"]:focus-visible, #contactusPrivacy input[type="checkbox"]:focus-visible, #privacyDiv input[type="checkbox"]:focus-visible, #contactUsV1Privacy input[type="checkbox"]:focus-visible { outline: 2px solid; outline-offset: 2px; } /* ------------------------------------------------------------ TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): grow the hamburger (.navbar-toggle) to a 44×44 hit area. RPcssMaster_C0051-GS-Balcony.css shows/positions this button in TWO separate breakpoint states, both mirrored here at the SAME breakpoints rather than left unconditional: - normal header: `.navbar .navbar-toggle` — shown via `display:block` inside @media(max-width:1450px) - sticky/affixed header: `header.affix .navbar-toggle` — shown via `display:block` inside @media(max-width:991px) Live-verified (TFS 2987209): an earlier, UNCONDITIONAL version of this rule unhid the toggle above its intended breakpoint — a real regression, confirmed live on this same 3-template family (it became an invisible-but-still-hit-testable phantom control past the breakpoint on a sibling template tested the same way). Do not remove these media queries "to simplify" — that reintroduces the bug. The icon is Bootstrap's stacked-`.icon-bar`-span construction (3 bars): `display:inline-flex` alone re-lays them into a horizontal row and breaks the glyph (confirmed live on an earlier pass of this fix); `flex-direction:column` keeps them stacked while centering the enlarged box. `!important` on `display` only — kept for cascade-order robustness; min-width/min-height never need it (base sets no competing width/height). Confirmed live at 375/768/1440: 44×44, glyph intact (3 stacked bars, not re-flowed), no logo overlap, skip-link unaffected. ------------------------------------------------------------ */ @media (max-width: 1450px) { body #form .template-balcony .navbar .navbar-toggle { min-width: 44px; min-height: 44px; display: inline-flex !important; flex-direction: column; align-items: center; justify-content: center; box-sizing: border-box; } } @media (max-width: 991px) { body #form .template-balcony header.affix .navbar-toggle { min-width: 44px; min-height: 44px; display: inline-flex !important; flex-direction: column; align-items: center; justify-content: center; box-sizing: border-box; } } /* TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): expand the consent checkbox's pointer hit-area to 44×44 without changing anything visually (Option B, plan §4.4/§0.5 J). The painted box stays 24×24 (position:relative already set above); this adds a transparent ::before over the box that only widens the clickable/tappable region. Do not touch :checked::after or :focus-visible above, and do not remove min-width/min-height:24px on the box rule above — on ContactUsFloating templates that min-width is the only reason the box is 24px wide at all (rpWebpartCss_ContactUsFloating.css sets width:auto !important, §0.4 D). ASYMMETRIC insets — intentional, do NOT "fix" this to be symmetric. Live click-testing (TFS 2987209) found this template's nearest control below the checkbox (the "privacy policy" link at 375/390px, the Submit button at 768/1440px) sits only ~4px away at every standard viewport. A symmetric 44×44 ring would swallow ~3px of that control's edge and steal its clicks. SC 2.5.5 has no centering requirement, so the shortfall is borrowed from the top side instead, which has ~27px of clearance (no left/right neighbor within 45px either). Net: genuine 44×44 hit area, ~1px buffer on the bottom edge, zero measured click-stealing at 375, 390, 768, and 1440px. */ body .contact-mobile-form input[type="checkbox"]::before, #contactusPrivacy input[type="checkbox"]::before, #privacyDiv input[type="checkbox"]::before, #contactUsV1Privacy input[type="checkbox"]::before { content: ""; position: absolute; top: -19px; right: -12px; bottom: -5px; left: -12px; } /* ------------------------------------------------------------ WCAG 2.2 AA 2.5.8 Target Size (Minimum) — TFS 3040687 Shared-component block. IDENTICAL BYTES in every wcag-*.css — this issue spans 23 templates, so nothing here is template-tuned. Source of truth: Silktide check `ensure-minimum-target-size` pulled from PROD 2026-08-24 — 182 sites / 1,034 flagged elements (test/3040687-target-size/silktide-prod/raw-flagged.json). Every rule cites the bucket and the geometry Silktide reported, and each was measured in headless Chrome before being included. Specificity: `body` prefix + !important rather than this template's own namespace prefix. The namespace would narrow the match and miss elements rendered outside the template wrapper (the decoy anchor is one of those). *** NEVER ADD `display` TO A TEXT-LINK RULE HERE. *** MEASURED, then SEEN in a screenshot: `display:inline-block` on a[href*="greystar.com/privacy"] made that link drop ~9px BELOW its row-mates ("DISCLOSURES & LICENSES", "DMCA AGENT") in the elan08022023 footer — a visible zig-zag, because inline-block turns the link into an atomic box that carries its own padding into the line layout. Vertical padding on a plain INLINE link grows the hit box (what the scanner measures) while the glyphs stay exactly on the baseline. Padding alone is sufficient; `display` is not needed anywhere in this block except the decoy's `display:none`. *** 24.0px IS NOT ENOUGH — read before editing any value below. *** TFS 2955118 established empirically (see the Tableau and Ascension notes earlier in this file) that a target landing on EXACTLY 24.0px is still flagged by the scanner: ".CMSSiteMapLink at 32px passes, footer links at 24.0 do not." So every rule here OVERSHOOTS: - text links -> vertical padding, which composes with any existing padding instead of replacing it, and never caps the box the way line-height does - icon/dots -> 28px, not 24px Do NOT "tidy" these back to min-height:24px / line-height:24px. That reintroduces the 24.0 failure AND, because these rules carry !important, would override the working padding-based rules that some templates (e.g. Ascension) already ship. ------------------------------------------------------------ */ /* 1. Hidden decoy anchor — 85 rows / 29 sites, reported 54x22. Not a real control. Its inline style carries no !important, so this wins and takes it out of hit-testing and the a11y tree. */ body a[aria-hidden="true"][tabindex="-1"][rel="nofollow"] { display: none !important; } /* 2. Site-map page links — 371 rows / 52 sites, the largest bucket. Reported ~71x19, stacked about one line-height apart. NOTE: a.CMSListMenuLink (5 rows) is deliberately EXCLUDED — that is the primary-nav class, and forcing line-height on it across 22 templates risks every page's header for 5 rows. */ body a.CMSSiteMapLink { padding-top: 5px !important; padding-bottom: 5px !important; } /* 3. Social icon links — NOT handled here. 44 rows / 23 sites, flagged at 11.4x24 / 17.2x24 (icon-font glyph on a `display:inline` anchor). MEASURED: every fleet-wide formulation broke something. - `display:inline-flex` + min-28 -> SHRANK compliant icons (balcony 44x44 -> 28x28, slate 33 -> 28) - `display:inline-block` + min-28 -> same shrink (the box comes from the parent's layout; any display override re-computes it) - `padding: 4px 8px` (no shrink) -> the extra width WRAPS the icon row onto a second line: slateqanew UL.header-social 5 icons, vertical centre spread 0px -> 28.6px (visible zig-zag); emerald +8px, balcony +4px. The containers differ per template, so this needs a container-scoped rule, not a fleet-wide one. **TFS 2982346 owns social-icon target size** and has per-template branches for exactly this. Left to that ticket on purpose. Do not re-add a global `a.facebook`-style rule here. */ /* 4. Hero scroll-down affordance — 18 rows / 15 sites, reported 9x16. */ body a#scroll-down { padding: 6px 8px !important; } /* 5. Hamburger / nav toggle — reported 16x6. a.dropdown-toggle is already handled elsewhere in this file; only the button form is new. min-* rather than padding: a