/* ===========================================================================
   Two classes the WordPress content uses that are not defined in any of the
   stylesheets carried over.

   On WordPress they came from the per-page custom CSS the page builder stored
   in postmeta and printed inline. Almost all of that per-page CSS was the
   dark-red boilerplate this project spent its time overriding:

       #header { background-color: #000000 }
       #main   { background: #6e0202 }
       #footer { background: #6e0202 }

   It is deliberately NOT carried over - there is no sense reproducing a
   colour scheme only to override it again. These two rules are the only ones
   from that source with any content meaning left.
   =========================================================================== */

/* Used once, on a heading in the Female Massage page. */
.text-purple { color: var(--spa-purple); }

/* .word_count is NOT a small note. It is <div class="word_count pgtitle">,
   a wrapper around a large block of the Jobs page - headings included. Styling
   it italic cascaded into every heading and paragraph inside it, which is why
   that page rendered slanted while WordPress did not.

   WordPress carries the same class and never styles it, so neither do we. */

/* The site tagline under the page heading ("Exhilirating Massage for Body Mind
   And Soul - California Massage Sanctuary").

   This also came from the per-page custom CSS, and unlike the #main / #footer
   colour rules above it is genuine content styling, not the dark-red scheme -
   so it does belong here. Without it the tagline falls back to the theme
   default (#787878 at 27px) and reads as small grey italic instead of the
   large purple script the site has always used.

   Values are the site's own. WordPress stores this per page and uses 42px
   everywhere except the home page, which is 40px - matched exactly here
   rather than averaged, so a side-by-side comparison shows no difference. */
.border-title .tag-line {
    color: rgb(179, 10, 251);
    display: block;
    font-size: 42px;
    font-style: normal;
    line-height: 30px;
    margin: 0;
}

body.home .border-title .tag-line { font-size: 40px; }

/* Tagline typeface: match what the live site actually renders.
   ---------------------------------------------------------------------------
   Both sites declare  font-family: Tangerine, cursive  for .tag-line, but they
   do not render the same, because they do not load the same fonts:

     WordPress loads : FontAwesome, Playfair Display, Roboto, Lato
     this app loads  : FontAwesome, Playfair Display, Roboto, Tangerine

   WordPress requests Tangerine through the old Google Fonts v1 API with
   URL-encoded pipes (family=Lato:...%20%7C%20Tangerine:400,700), which does not
   resolve - so Tangerine never arrives and the browser falls back to the
   generic `cursive`, i.e. Comic Sans MS on Windows. That rounded look IS the
   live site's appearance.

   This app loads Tangerine correctly through the css2 API and therefore showed
   the real script face - technically more correct, but visibly different.
   Dropping to `cursive` here reproduces the live rendering exactly.

   To go the other way (use the intended Tangerine on both), fix the font URL
   in the WordPress theme instead and delete this rule. */
.border-title .tag-line,
.bbar-text,
.floral-head {
    font-family: cursive;
}
