/**
* Print/PDF styling for Workshop pages.
*
* This file has two consumers:
*
* 1. The real browser print stylesheet — enqueued in functions.php with
* `media: 'print'`, so browsers only load/apply it when the user
* actually prints a page (Ctrl+P), same as any other print stylesheet.
* 2. The Workshop "Download overview" PDF — read directly (see
* torii_get_workshop_overview_pdf_css() in inc/workshop-overview-pdf.php)
* and appended after the theme's normal component CSS, then handed to
* Dompdf with Options::setDefaultMediaType('print'). Rules here aren't
* wrapped in @media print because that context is already established by
* each consumer (the attribute for browsers, the
* Dompdf option for the PDF) — the media attribute/option is what gates
* *when* this file's rules apply, not anything inside the file itself.
*
* Component base styles (grid, flexbox, mask-image, clip-path, box-shadow)
* rely on features Dompdf can't render, so most rules below exist to
* simplify a component back down to layout Dompdf handles reliably
* (block flow, floats, borders) rather than to restyle it — the same
* simplification also happens to make sense for a printed page, which has
* no hover/JS interaction either.
*/
/* ---------------------------------------------------------------------
* base.css — global reset + typography baseline
* ------------------------------------------------------------------- */
/*
* Dompdf doesn't support box-shadow, CSS masks, or clip-path reliably —
* left alone they render as stray artifacts (a soft shadow can show up as
* a solid stray curved outline instead of being skipped). Reset them
* globally rather than chasing every component that happens to use one;
* component-specific sections below still layer their own overrides for
* layout (grid/flexbox), this just guarantees no leftover decorative
* effect slips through unnoticed on a newly added component.
*
* The margin/alignment reset in the same rule overrides every component
* rule below (and anything from theme.json's global styles or the
* component CSS this file is appended after) that centres content via
* `margin: 0 auto`/`text-align: center` — e.g. the workshop
* quotation/testimonial carousels, the separator rule below, or any
* block-level "wide"/alignment setting. `!important` is what makes a
* bare `*` selector here win regardless of source order against those
* more specific class selectors — not this rule's position in the file.
* Floats (the header logo/photo row, the options table's two-column
* layout) aren't affected, since they don't position via horizontal
* margins.
*/
* {
box-shadow: none !important;
mask-image: none !important;
-webkit-mask-image: none !important;
clip-path: none !important;
margin-left: 0 !important;
margin-right: 0 !important;
text-align: left !important;
}
/*
* The theme's real fonts (Poppins for body copy, Urbanist for headings —
* see torii_get_workshop_overview_pdf_font_css() in
* inc/workshop-overview-pdf.php, which embeds them as base64 TrueType data
* URIs, the only font format Dompdf's @font-face support accepts) are used
* here to match the live site. 'DejaVu Sans' stays as a final fallback
* (Dompdf's own bundled Unicode-safe sans font, unlike "Helvetica" which
* only covers Latin-1/WinAnsi) in case a character isn't covered by
* Poppins/Urbanist — without it a missing glyph silently renders as a "?"
* box instead of falling through to a font that does have it.
*
* Every font-size in this file (here and on individual components further
* down — .faq-accordion__question, .stat-card__number, etc.) is a `pt`
* value from one deliberate scale: 9/11/12/13/16/22pt. Component sizes
* copied straight from the live site's own `px` values (tuned for
* on-screen viewing, not a printed page) read as wildly inconsistent next
* to each other once printed — most strikingly .stat-card__number at a
* literal 32px worked out to 24pt, bigger than this page's own
* (22pt). Any new font-size added here should fit this same scale rather
* than transplanting a screen pixel value directly.
*/
body {
font-family: Poppins, 'DejaVu Sans', sans-serif;
font-size: 11pt;
line-height: 1.3;
color: #2a2637;
/*
* Global styles (wp_get_global_stylesheet(), included by
* torii_get_workshop_overview_pdf_css()) sets `body { background:
* var(--page-background-color) }`, which theme.json defaults to
* --wp--preset--color--neutral-500 unless the real front-end has
* one of a few page-template classes setting it to white — classes this
* PDF's plain never has. Override back to no fill rather than
* carrying that unintended tint into the printed page.
*/
background: none;
padding-left: 48px;
padding-right: 48px;
}
/*
* Core's own block-library CSS (border/width/spacing for
* .wp-block-separator) isn't part of this PDF's stylesheet at all — only
* theme.json's global styles (color) and this theme's own component CSS
* are concatenated, neither of which carries the separator's base
* structural rules. Without them a plain falls back to Dompdf's own
* UA-default styling (a thick inset 3D groove) instead of the thin
* currentColor rule the site actually shows.
*/
hr,
.wp-block-separator {
border: none;
border-bottom: 1px solid currentcolor;
color: #d9d3c9;
height: 0;
margin: 12pt 0;
}
h1,
h2,
h3,
h4 {
font-family: Urbanist, 'DejaVu Sans', sans-serif;
font-weight: 700;
color: #2a2637;
margin: 0 0 6pt;
}
/*
* Dompdf's own default stylesheet sets `b, strong { font-weight: bolder }` —
* a *relative* keyword, not an absolute weight. Nested inside an
* already-bold ancestor (any of the h1-h4 above at 700, or the many 600
* elements elsewhere in this file — `.stat-card__caption`, tick-list
* `` lead-ins, etc.), "bolder" resolves to a weight one step up
* (900 inside a 700 heading, 700 inside a 600 body element) that this
* file's embedded Urbanist/Poppins @font-face rules
* (torii_get_workshop_overview_pdf_font_css()) don't necessarily define —
* Poppins only embeds 400/600, no 700 at all. Unlike a browser, Dompdf
* doesn't fall through the rest of the `font-family` stack (DejaVu Sans,
* sans-serif) when a requested weight has no match within a family it does
* have *a* registered face for — it drops straight to its own built-in
* default (confirmed via direct Dompdf renders: Times-Bold for a bare
* `strong, b { font-weight: 700 }` inside an h4, Helvetica-Bold for that
* same flat 700 inside Poppins body copy since Poppins has no 700 face
* either) — which is what was actually causing headings like `
* What happens when X
` (a pattern several Workshop
* posts' "outcomes" heading uses, redundantly bolding text already bold via
* the h4 rule above) and bold lead-ins inside tick lists to render in a
* plain serif/sans fallback instead of the theme's own fonts.
*
* Rather than one flat weight, this pins `bolder` to whichever weight is
* actually embedded for the font family in play: 600 as the default
* (matches both Poppins-600 and Urbanist-600, so it's safe anywhere outside
* a heading), overridden to 700 specifically inside h1-h4 (matches
* Urbanist-700, the same weight those headings' own text already renders
* at, so a ``-wrapped heading like the pattern above doesn't end up
* visibly lighter than a plain one). Both tiers confirmed via direct
* Dompdf renders of the real heading and tick-list markup.
*/
strong,
b {
font-weight: 600;
}
h1 strong,
h1 b,
h2 strong,
h2 b,
h3 strong,
h3 b,
h4 strong,
h4 b {
font-weight: 700;
}
h1 {
font-size: 22pt;
line-height: 1.15;
}
h2 {
font-size: 16pt;
line-height: 1.2;
margin-top: 14pt;
}
h3,
h4 {
font-size: 13pt;
line-height: 1.2;
margin-top: 10pt;
}
p {
margin: 0 0 6pt;
}
a {
color: #2a2637;
}
ul,
ol {
margin: 0 0 6pt;
padding-left: 16pt;
}
/* Space consecutive tab-section groups out so sections read as distinct
blocks instead of running straight into each other. */
.workshop-tab-section {
margin-bottom: 12pt;
padding-bottom: 12pt;
border-bottom: 1px solid #eee7df;
}
.workshop-tab-section:last-of-type {
border-bottom: none;
}
/*
* The "Footer" wrapper (patterns/tabs-workshop.php) carries WordPress's own
* `has-neutral-500-background-color has-background` utility classes rather
* than a plain component rule — `wp_get_global_stylesheet()` (included by
* torii_get_workshop_overview_pdf_css()) emits those with `!important`
* (same as the `has-*-font-size` classes handled further down), so a
* non-`!important` override here would lose regardless of source order.
*/
.workshop-section-break-out {
background: none !important;
}
/*
* assets/css/components/workshop-section-break-out.css breaks this section
* out to the true viewport edges on the live site (`width: 100vw;
* margin-left/right: calc(50% - 50vw);`) so its background can bleed full
* width despite being nested several `layout: constrained` groups deep.
* `vw` has no meaningful equivalent on a fixed PDF page — Dompdf resolves
* it against some notion of viewport width that isn't this page's own
* content box, so the section ends up wider than the page and its content
* runs off the edge instead of wrapping to it. That compound selector
* (`.wp-block-group.workshop-section-break-out`) is more specific than a
* bare `.workshop-section-break-out`, so matching it exactly is what
* actually wins here — same specificity trap as `.stat-card__caption`
* further down this file.
*/
.wp-block-group.workshop-section-break-out {
width: auto;
margin-left: 0;
margin-right: 0;
padding-block: 24px;
}
/*
* WordPress's own global styles (wp_get_global_stylesheet(), from
* theme.json's `useRootPaddingAwareAlignments`/layout support) both
* auto-centre *and* cap the width of every non-aligned direct child of a
* `.is-layout-constrained` element via a selector shaped like:
* .is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
* max-width: var(--wp--style--global--content-size);
* margin-left: auto !important;
* margin-right: auto !important;
* }
* `:where()` contributes zero specificity, so that selector's real
* specificity is just the one `.is-layout-constrained` class — higher than
* the bare `*` this file's blanket left-align reset (near the top of this
* file) uses, so it was winning over that reset despite `!important` on
* both sides (equal specificity/`!important` resolves by source order, but
* here the specificities aren't actually equal). Matching the exact
* selector shape is what actually wins the tie. `max-width` isn't
* `!important` on WordPress's side, but overridden here too (also with
* `!important`, for the same specificity-matching reason) so content
* fills the full printable page width instead of clamping to the site's
* `--wp--style--global--content-size` (tuned for a browser viewport, not
* an A4 page).
*/
.is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
max-width: none !important;
margin-left: 0 !important;
margin-right: 0 !important;
}
/*
* A second, separate WordPress global-styles mechanism from the same
* `useRootPaddingAwareAlignments` system: any element WordPress decides
* needs the root inset gets a `has-global-padding` class directly in the
* saved markup, with `wp_get_global_stylesheet()` emitting
* `.has-global-padding { padding-right: var(--wp--style--root--padding-right)
* !important; padding-left: var(--wp--style--root--padding-left) !important; }`
* — 24px a side. Both `.workshop-tab-section` itself *and* nested wrapper
* groups inside it (e.g. patterns/workshop-product-intro.php's
* `.text-component.product-intro__intro`) can carry this class at once,
* stacking to 48px on whichever tab happens to nest one — the actual
* cause of one tab's intro heading/paragraphs sitting more indented than
* every other tab's content, which has no reason to vary tab-to-tab.
*/
.has-global-padding {
padding-left: 0 !important;
padding-right: 0 !important;
}
/* The "Download overview" button lives inside the very PDF it downloads —
showing it in the rendered PDF/print output would be a link to itself.
Same reasoning as .book-a-call/.contact-form-panel further down: hide the
interactive control rather than trying to reproduce it. */
.product-intro__intro .wp-block-buttons {
display: none;
}
/* ---------------------------------------------------------------------
* book-a-call.css
* ------------------------------------------------------------------- */
/* Fixed floating widget, not page content — hide it entirely rather than
trying to reproduce its mask-cutout shape. Never actually part of the
.workshop-tab-section content the PDF renders, but still hidden here for
real browser printing of any page it appears on. */
.book-a-call {
display: none;
}
/* ---------------------------------------------------------------------
* contact-cta-panel.css
* ------------------------------------------------------------------- */
/* Same reasoning as cta-photo-overlay.css below — drop the fillet cutouts
(clip-path / mask-image, unsupported by Dompdf) and the fixed absolute
positioning tuned for the on-screen panel, and fall back to plain
stacked content. */
.contact-cta {
background-color: #b9bdff;
padding: 32px;
display: block;
}
.contact-cta::before {
display: none;
}
.contact-cta__text {
max-width: none;
}
.contact-cta__details {
max-width: none;
padding-top: 16px;
}
/* ---------------------------------------------------------------------
* contact-form.css
* ------------------------------------------------------------------- */
/* An interactive form has nothing useful to show on paper (or in Dompdf,
which doesn't execute the CF7 submit JS anyway). Hide it rather than
trying to reproduce input fields. */
.contact-form-panel {
display: none;
}
/* ---------------------------------------------------------------------
* cta-photo-overlay.css
* ------------------------------------------------------------------- */
/* Keep the circular photo (border-radius + overflow:hidden crops fine
without JS or masks) but drop the decorative white blob and its two
clip-path fillets behind it — Dompdf doesn't rasterize clip-path, so
left alone it would show as a stray unclipped white box. */
.call-to-action {
background-color: #b9bdff;
padding: 32px;
min-height: 0;
}
.call-to-action__overlay,
.call-to-action__overlay::before,
.call-to-action__overlay::after {
display: none;
}
.call-to-action__photo {
position: static;
width: 100px;
height: 100px;
margin-bottom: 16px;
border: 2px solid #2a2637;
}
/* ---------------------------------------------------------------------
* faq.css
* ------------------------------------------------------------------- */
/*
* Answers are normally revealed by faq.js toggling
* .faq-accordion__item--active, which never runs for Dompdf (no JS) and
* isn't useful on a printed page either. Force every panel open and drop
* the grid, mask cutout and absolute-positioned arrow — Dompdf doesn't
* support CSS Grid or mask-image, so this section stays CSS 2.1-safe.
*/
.faq-accordion {
display: block;
}
.faq-accordion__item {
position: static;
background-color: #f8f3ed;
border-radius: 8px 8px 0 8px;
margin-bottom: 8px;
page-break-inside: avoid;
}
.faq-accordion__item::before {
display: none;
}
.faq-accordion__header {
display: block;
padding: 8px 14px;
}
.faq-accordion__question {
font-family: Poppins, 'DejaVu Sans', sans-serif;
font-weight: 600;
font-size: 12pt;
color: #2a2637;
}
.faq-accordion__arrow {
display: none;
}
.faq-accordion__panel {
max-height: none;
overflow: visible;
}
.faq-accordion__answer {
padding: 0 14px 8px;
font-family: Poppins, 'DejaVu Sans', sans-serif;
font-size: 11pt;
color: #2a2637;
}
/* ---------------------------------------------------------------------
* photo-callout.css
* ------------------------------------------------------------------- */
/* Drop the mask-image corner cutout (unsupported by Dompdf, would
otherwise show as an unclipped rectangular photo) in favour of a plain
rounded-corner crop, and let the caption sit below the photo in normal
flow instead of overlaid on top of it. */
.photo-callout__image {
height: auto;
max-height: 320px;
border-radius: 12px;
mask-image: none;
-webkit-mask-image: none;
}
.photo-callout__text {
position: static;
width: auto;
height: auto;
max-width: none;
padding: 12px 0 0;
}
.photo-callout__text p {
font-family: Poppins, 'DejaVu Sans', sans-serif;
font-size: 12pt;
color: #2a2637;
}
/*
* `.text-component` itself is `display: flex` on the live site
* (assets/css/components/workshop-text-component.css) — this file
* previously assumed Dompdf's lack of flexbox support meant it "falls back
* to block" on its own with no override needed, but that's not what
* actually happens: left as `flex`, `.text-component` doesn't reliably
* behave like a block box — most visibly, `clear` on
* `.programme-info > .text-component` below (needed because several
* Workshop posts nest a `.text-component` — e.g. the "What you'll learn &
* do" block — directly *inside* `.programme-info`, beside the floated
* `.programme-info__item`s) silently had no effect until this explicit
* reset was added, confirmed via a direct Dompdf render both ways. Placed
* here, ahead of `.programme-info > .text-component`'s own higher
* specificity further down, to satisfy stylelint's no-descending-specificity
* check.
*/
.text-component {
display: block;
}
/* ---------------------------------------------------------------------
* programme-info.css
* ------------------------------------------------------------------- */
/*
* .programme-info__icon centres its icon with `display:flex;
* align-items:center; justify-content:center;` — unsupported by Dompdf, so
* without an override the icon (converted from inline