/*
Theme Name: PPLS (Weebly port)
Theme URI: https://www.penangproperties.com/
Description: Faithful port of the original Weebly "Edison" theme used by
    penangproperties.com, so the WordPress rebuild launches looking identical
    to the site it replaces. Wraps the original main_style.css unchanged and
    reproduces the header/footer markup its selectors expect. Fonts are
    self-hosted — the originals loaded from cdn2.editmysite.com over plain http.
Version: 0.1.7
Requires at least: 6.0
Tested up to: 7.0
Requires PHP: 8.0
License: GPL-2.0-or-later
Text Domain: ppls
*/

/* Intentionally almost empty: the real styling is assets/main_style.css,
   enqueued from functions.php and kept byte-identical to the Weebly original
   so it can be re-synced. Put overrides below, never in that file. */

/* WordPress core markup that Weebly's stylesheet knows nothing about. */
.wp-caption { max-width: 100%; }
.screen-reader-text {
	border: 0;
	clip-path: inset(50%);
	height: 1px;
	overflow: hidden;
	position: absolute;
	white-space: nowrap;
	width: 1px;
}
.ppls-admin-note {
	background: #fffbe6;
	border-left: 4px solid #f0b429;
	margin: 0 0 1em;
	padding: 12px 16px;
}

/* --- Buttons -------------------------------------------------------------
   main_style.css:207 gives .wsite-button padding, box-sizing and line-height
   but never a display mode, so an <a> falls back to `display: inline` — where
   vertical padding paints without reserving line space. The blue button
   therefore overlapped whatever followed it by 10-13px: "Contact Us" clipped
   the "Enquiry click" line under it, "Back to top" clipped the disclaimer, on
   all 526 pages.

   The rule was never in the export. The archived pages pulled it from
   cdn11.editmysite.com/css/sites.css, Weebly's base stylesheet, which the
   scraper did not capture and which died with the account — the same live-CDN
   dependency that took the fancybox lightbox with it. The only `display`
   main_style.css sets for this class is line 330, scoped to the ecommerce
   checkout wrapper, which never matches here.

   Lives here rather than in main_style.css, which stays byte-identical. */

.wsite-button {
	display: inline-block;
	vertical-align: middle;
}

/* --- Theme-generated listings (search, archives, 404) --------------------
   header.php opens .content-wrap but no .container, and every template emits
   #wsite-content straight into it. That is right for imported pages, which
   bring their own Weebly wrappers and inline column widths — but index.php
   builds its own markup, so its text ran flush to both viewport edges.

   Reuses main_style.css's own container metrics (max-width 1100px, 15px
   gutters) rather than inventing a value, so results sit on the same measure
   as the rest of the site instead of stretching the full window. */

.ppls-index {
	max-width: 1100px;
	margin: 0 auto;
	padding: 0 15px;
	box-sizing: border-box;
}

/* --- WordPress admin bar -------------------------------------------------
   main_style.css pins .edison-header with `position: fixed; top: 0` at every
   width (body.header-sticky, which header.php always sets). Fixed elements are
   positioned against the viewport, so they ignore the
   `html { margin-top: 32px !important }` bump core injects to make room for the
   admin bar. The header therefore stays at viewport top 0 and the bar paints
   over it — z-index 99999 against the header's 15 — hiding its top 32px and
   leaving only the lower strip of #2aa5eb showing. That is the two-tone topbar:
   admin-bar grey above, clipped header blue below.

   .mobile-nav is fixed at top:50px so it sits flush under the header, so it has
   to shift by exactly the same amount or it detaches from it.

   All of this is scoped to body.admin-bar, so logged-out visitors render the
   original theme untouched. */

body.admin-bar .edison-header { top: 32px; }
body.admin-bar .mobile-nav {
	top: 82px;                      /* 32 bar + 50 header */
	max-height: calc(100% - 82px);
}

@media screen and (max-width: 782px) {
	/* Core grows the bar to 46px here and bumps html to match. */
	body.admin-bar .edison-header { top: 46px; }
	body.admin-bar .mobile-nav {
		top: 96px;                  /* 46 bar + 50 header */
		max-height: calc(100% - 96px);
	}
}

@media screen and (max-width: 600px) {
	/* Core drops #wpadminbar to position:absolute below 600px so it scrolls
	   away with the page. That fights a sticky header both ways: anchor the
	   header at 46px and a 46px gap opens once the bar scrolls off, anchor it
	   at 0 and the bar is covered for good — unreachable on a phone. Holding
	   the bar fixed keeps the 46px offset above correct at every width.
	   Specificity (1,1,1) beats core's (1,0,0), so load order does not matter. */
	body.admin-bar #wpadminbar { position: fixed; }
}

/* --- Password-protected pages (Blocker 4) --------------------------------
   The five staff pages are gated with core's native per-page password, so
   the_content() returns get_the_password_form() and page.php renders it bare
   inside #wsite-content. Weebly's stylesheet has no rules for any of it: the
   result is `Password: [___] [Enter]` on an unstyled white band between the
   themed header and footer, which reads as a broken page rather than a gate.
   The people who meet it are staff — the group least likely to report that as
   a styling problem rather than "the site is down".

   Two specific gaps, both checkable in main_style.css:
     - Its input reset (line 3) covers text, email and textarea but NOT
       password, so the field gets no appearance reset, and the :focus border
       on line 4 never matches it either.
     - .wsite-button (line 207) styles <a> elements. The form's submit is an
       <input type="submit">, so it inherits none of that styling.

   Container metrics reuse main_style.css's own (max-width 1100px, 15px
   gutters) — the same values .ppls-index borrows above — rather than
   inventing a measure. The hover state reuses .wsite-button-highlight's
   declared values (lines 221-222) instead of inventing a darker blue.

   CSS only, deliberately. The markup comes from core, and filtering it via
   the_password_form would add a moving part to five pages whose whole job is
   to be boring. The intro paragraph already picks up site typography, because
   site-styles.css targets `#wsite-content p` — only the controls are adrift,
   since form controls do not inherit font-family. */

.post-password-form {
	max-width: 1100px;
	margin: 0 auto;
	padding: 48px 15px 64px;
	box-sizing: border-box;
}

/* Core nests the password input INSIDE the <label>, with the submit as the
   label's sibling — both inside one <p>. Making the label a block is what puts
   the button on its own line. */
.post-password-form label {
	display: block;
	font-size: 18px;
}

.post-password-form input[type="password"] {
	display: block;
	width: 100%;
	max-width: 320px;
	margin-top: 8px;
	padding: 12px 14px;
	border: 1px solid #cccccc;
	background: #ffffff;
	box-sizing: border-box;
	font-family: 'Karla', sans-serif;
	font-size: 16px;
	line-height: 1.2;
	-webkit-appearance: none;
	appearance: none;
}

.post-password-form input[type="password"]:focus {
	border-color: #2aa5eb;
	outline: 2px solid rgba(42, 165, 235, 0.35);
	outline-offset: 1px;
}

.post-password-form input[type="submit"] {
	display: inline-block;
	margin-top: 20px;
	padding: 0.9375em 2.5625em;
	border: 0;
	background-color: #2aa5eb;
	color: #ffffff;
	font-family: 'Karla', sans-serif;
	font-size: 16px;
	font-weight: 700;
	line-height: 1;
	text-align: center;
	cursor: pointer;
	box-sizing: border-box;
	-webkit-appearance: none;
	appearance: none;
}

.post-password-form input[type="submit"]:hover,
.post-password-form input[type="submit"]:focus {
	background-color: #ffffff;
	color: #2aa5eb;
	box-shadow: 0 0 0 2px #2aa5eb inset;
}

/* --- Enquiry forms (ppls-enquiry.php) ------------------------------------
   Same situation as the password form above: this is markup Weebly's stylesheet
   has never seen. The original forms were Weebly's own, styled by
   .wsite-form-field rules in main_style.css that expect Weebly's exact DOM —
   reusing those class names would have meant reproducing that DOM and
   inheriting its quirks, so these carry their own .ppls-form-* names and
   borrow only the theme's values.

   Metrics and colours come from the same places the password form borrows:
   main_style.css's container (1100px / 15px gutters), #2aa5eb, Karla, and
   .wsite-button-highlight's declared hover pair (lines 221-222).

   The password input note applies here too — main_style.css:3 resets text,
   email and textarea only, so select and the choice controls get nothing. */

.ppls-form {
	max-width: 1100px;
	margin: 0 auto;
	padding: 32px 15px 56px;
	box-sizing: border-box;
}

/* ⚠️ Font has to be stated, not inherited.
   site-styles.css sets the site's body font via `#wsite-content p` and
   `#wsite-content .wsite-form-field label` — Weebly's own class names. These
   controls use .ppls-form-* names, match neither selector, and so fall through
   to main_style.css's Roboto Mono default. The symptom is the one § 9 describes:
   body copy rendering in monospace. The .ppls-form-intro paragraph escapes it
   only because it is a real <p> inside #wsite-content.

   Arial matches what site-styles.css sets for body copy AND for Weebly's own
   form labels, so this is the faithful value rather than a new choice. The
   submit button stays Karla, matching .wsite-button. */
.ppls-form,
.ppls-form-label,
.ppls-form-help,
.ppls-form-choice label,
.ppls-form input[type="text"],
.ppls-form input[type="email"],
.ppls-form select,
.ppls-form textarea { font-family: Arial, Helvetica, sans-serif; }

.ppls-form-intro { margin: 0 0 20px; }

.ppls-req { color: #b32d2e; }

.ppls-form-field {
	margin: 0 0 22px;
	padding: 0 0 4px;
}

/* The page heading above a form. Bigger and heavier than the theme's default h2 so it
   reads as the page's subject, and tight underneath — the form's own intro line follows
   immediately and the two belong together. Scoped to its own class: .wsite-content-title
   is Weebly's and is used all over the site. */
/* The page heading above a form.
   ⚠️ It must be an <h1>, and that is not a style preference. site-styles.css targets
   `#wsite-content h2` — an ID selector — with `font-size: 23px !important` and
   `font-weight: 400 !important`, which beats any class rule no matter how many
   !importants it carries, because an ID outranks a class. The same file never
   mentions h1 at all. So the heading dodges the fight instead of losing it, and this
   rule needs no !important. It is also the right element: the theme renders no other
   h1 in the content area. */
.ppls-form-page-title {
	margin: 0 0 10px;
	font-size: 34px;
	font-weight: 700;
	line-height: 1.15;
	text-align: center;
}

@media (max-width: 640px) {
	.ppls-form-page-title { font-size: 26px; }
}

/* ⚠️ The footer's link lists are <p> per line, NOT <br>-separated, and this rule is
   what makes that look the same as before.

   The reason is not styling: TinyMCE converts <br> to newlines when it loads content
   and relies on wpautop to convert them back, which only happens inside paragraph
   context. The footer has no <p> of its own, so every line break was silently lost the
   first time an admin saved the page and the four link columns collapsed into running
   prose. Paragraphs round-trip natively, so they survive.

   The cost is that <p> carries a 10px bottom margin here, which <br> did not. Zeroing
   it restores the original line spacing exactly; .paragraph keeps its own margin, so
   the gaps BETWEEN columns are untouched. */
.wsite-footer .paragraph p {
	margin: 0;
}

/* The courtesy line above the Submit button. Close to the button it belongs to, and
   clear of the last field above it. */
.ppls-form-outro {
	margin: 28px 0 12px;
}

/* Section headings. The admin's design groups the form into named steps rather than
   one long column, and a rule above each is what makes the grouping visible without
   adding a box the Weebly page styles would then have to agree with. Every section
   keeps its rule, the first included — the buy/rent question sits above it and wants
   separating from the property questions it controls. */
.ppls-form-section {
	margin: 34px 0 18px;
	padding: 18px 0 0;
	border-top: 1px solid #d8d8d8;
}

.ppls-form-section-title {
	margin: 0;
	font-size: 20px;
	font-weight: 700;
}

/* A section's help is a subtitle for the group, so it sits under the heading rather
   than above a control the way a field's help does. */
.ppls-form-section .ppls-form-help {
	margin: 6px 0 0;
}

/* Placeholders are examples, not values. Without a weaker colour they read as text
   already typed in, and a visitor tabs past a field they think they answered. */
.ppls-form ::placeholder { color: #8a8a8a; opacity: 1; }

.ppls-form-label {
	display: block;
	margin: 0 0 4px;
	font-size: 18px;
	font-weight: 700;
}

/* Help text sits between the label and the control, which is where the Weebly
   original put it — it is guidance for filling the field in, not a footnote. */
.ppls-form-help {
	display: block;
	margin: 0 0 8px;
	color: #5a5a5a;
	font-size: 15px;
	line-height: 1.4;
}

.ppls-form input[type="text"],
.ppls-form input[type="email"],
.ppls-form select,
.ppls-form textarea {
	display: block;
	width: 100%;
	max-width: 520px;
	padding: 12px 14px;
	border: 1px solid #cccccc;
	background: #ffffff;
	box-sizing: border-box;
	font-size: 16px;
	line-height: 1.3;
	-webkit-appearance: none;
	appearance: none;
}

.ppls-form textarea { max-width: 720px; resize: vertical; }

/* appearance:none strips the native arrow, so put one back or the control reads
   as a text box that mysteriously will not accept typing. */
.ppls-form select {
	background-image: linear-gradient(45deg, transparent 50%, #2aa5eb 50%),
		linear-gradient(135deg, #2aa5eb 50%, transparent 50%);
	background-position: calc(100% - 20px) 50%, calc(100% - 14px) 50%;
	background-size: 6px 6px, 6px 6px;
	background-repeat: no-repeat;
	padding-right: 40px;
}

.ppls-form input[type="text"]:focus,
.ppls-form input[type="email"]:focus,
.ppls-form select:focus,
.ppls-form textarea:focus {
	border-color: #2aa5eb;
	outline: 2px solid rgba(42, 165, 235, 0.35);
	outline-offset: 1px;
}

/* Choices are inline-block so short options sit side by side and long ones wrap
   whole rather than splitting the box from its label. */
.ppls-form-choice {
	display: inline-block;
	margin: 0 18px 8px 0;
	vertical-align: top;
}
.ppls-form-choice input { margin-right: 6px; }
.ppls-form-choice label { font-size: 16px; }

.ppls-form-field-error input,
.ppls-form-field-error select,
.ppls-form-field-error textarea { border-color: #b32d2e; }

.ppls-form-errors,
.ppls-form-done {
	margin: 0 0 24px;
	padding: 14px 18px;
	border-left: 4px solid #2aa5eb;
	background: #f2f9fd;
}
.ppls-form-errors { border-left-color: #b32d2e; background: #fdf3f3; }

/* The honeypot must be unreachable, not merely invisible: display:none is what
   many bots check for, and a plain off-screen field can still be tabbed into.
   aria-hidden and tabindex="-1" on the input handle the rest (see the plugin). */
.ppls-hp {
	position: absolute !important;
	left: -9999px !important;
	width: 1px;
	height: 1px;
	overflow: hidden;
}

.ppls-form-submit {
	display: inline-block;
	margin-top: 8px;
	padding: 0.9375em 2.5625em;
	border: 0;
	background-color: #2aa5eb;
	color: #ffffff;
	font-family: 'Karla', sans-serif;
	font-size: 16px;
	font-weight: 700;
	line-height: 1;
	cursor: pointer;
	box-sizing: border-box;
	-webkit-appearance: none;
	appearance: none;
}

.ppls-form-submit:hover,
.ppls-form-submit:focus {
	background-color: #ffffff;
	color: #2aa5eb;
	box-shadow: 0 0 0 2px #2aa5eb inset;
}

/* Conditional branches (ppls-enquiry.php). The script toggles the `hidden`
   property; this is here because a stylesheet elsewhere setting `display` on
   .ppls-form-field would otherwise beat the browser's default [hidden] rule and
   the branch would stay visible. Server-side scope is unaffected either way —
   ppls_enq_when_met() decides what is validated and stored. */
.ppls-form .ppls-form-field[hidden] { display: none; }
