/* theme header, custom properties, resets, page shell
Part of the split style.css. inc/enqueue.php enqueues each file as
its own , in filename order -- they are NOT concatenated, so a
comment or a rule cut across the join does not heal at the seam. It
breaks both files, and the browser drops everything it cannot parse
without saying so. Keep every construct whole inside one file.
Source order is still the cascade, so moving a rule between files
can change which one wins. */
/*
Theme Name: Pet Town Child
Template: twentytwentyfour
Version: 0.1.0
*/
@font-face { font-display: swap; font-family: "Manrope"; font-style: normal; font-weight: 400; src: url("../fonts/manrope-0.woff2") format("woff2"); }
@font-face { font-display: swap; font-family: "Manrope"; font-style: normal; font-weight: 600; src: url("../fonts/manrope-1.woff2") format("woff2"); }
@font-face { font-display: swap; font-family: "Manrope"; font-style: normal; font-weight: 700; src: url("../fonts/manrope-2.woff2") format("woff2"); }
@font-face { font-display: swap; font-family: "Manrope"; font-style: normal; font-weight: 800; src: url("../fonts/manrope-3.woff2") format("woff2"); }
@font-face { font-display: swap; font-family: "Noto Sans Hebrew"; font-style: normal; font-weight: 400; src: url("../fonts/noto-sans-hebrew-0.woff2") format("woff2"); }
@font-face { font-display: swap; font-family: "Noto Sans Hebrew"; font-style: normal; font-weight: 600; src: url("../fonts/noto-sans-hebrew-1.woff2") format("woff2"); }
@font-face { font-display: swap; font-family: "Noto Sans Hebrew"; font-style: normal; font-weight: 700; src: url("../fonts/noto-sans-hebrew-2.woff2") format("woff2"); }
@font-face { font-display: swap; font-family: "Noto Sans Hebrew"; font-style: normal; font-weight: 800; src: url("../fonts/noto-sans-hebrew-3.woff2") format("woff2"); }
.pet-wordmark {
align-items: center;
display: inline-block;
height: 82px;
overflow: hidden;
position: relative;
text-decoration: none;
transition: transform .2s;
/* Absolutely centered across the whole header (see .pet-site-header
.pet-wordmark below), so it must stay narrow enough to never reach the
nav on the left or the cart/account/language cluster on the right --
confirmed overlapping both at 1363px window width when this was 380px. */
width: min(20vw, 270px);
}
.pet-wordmark img {
display: block;
height: 100%;
object-fit: contain;
object-position: center;
width: 100%;
}
.pet-wordmark:hover,
.pet-wordmark:focus-visible { transform: translateY(-2px); }
.pet-wordmark:focus { outline: 0; }
.pet-wordmark:focus-visible {
outline: 3px solid var(--pet-focus);
outline-offset: 4px;
}
.wp-block-site-title a {
text-decoration: none;
}
.wp-block-site-title a:hover {
text-decoration: underline;
}
.wp-block-site-logo img {
border-radius: 14px;
}
.has-base-background-color {
border-bottom: 1px solid var(--pet-border);
}
/* The palette. Every ratio quoted below is a measured WCAG 2.x contrast
ratio, not an estimate, and tests/palette-contrast.php re-measures the
whole set on every run -- so a token edited here without re-checking its
pairing fails the build rather than shipping an unreadable page.
The rule that shapes the whole set: a colour used as small text owes
4.5:1 against its ground, a colour used as the boundary of an interface
component (an input's edge, a checkbox, an outline button, a focus ring)
owes 3:1, and a colour used purely as a fill or decoration owes nothing.
Those three jobs need three different tones of the same hue, which is why
the warm accent below is split in two and why the input border is not the
card border. */
:root {
/* Primary action. One green, three states: the deeper two exist so a
hover/press is a real step rather than a barely-visible shift, and all
three carry white text well past AA. */
--pet-primary: #285E57; /* #fff on it 7.42; itself on --pet-background 6.86 */
--pet-primary-hover: #204C47; /* #fff on it 9.61 */
--pet-primary-active: #173B37; /* #fff on it 12.23 */
--pet-primary-soft: #E7F0ED; /* tinted surface; --pet-primary on it 6.39 */
/* Grounds. --pet-background is the page, --pet-surface a card, and
--pet-surface-muted the quieter panel behind a card -- the last one
replaces 16 separate copies of #edf5f0 that had no token at all. */
--pet-background: #F7F6F2;
--pet-surface: #FFFFFF;
--pet-surface-muted: #EEF2EF;
/* Text. --pet-text is the reading colour and nothing else: it used to
share one token with the primary action and the dark surface, which is
why the page had no visible hierarchy between "this is a heading" and
"this is a button". */
--pet-text: #1C2523; /* 15.69 on --pet-surface, 14.51 on --pet-background */
--pet-text-secondary: #56635F; /* 6.28 / 5.80 / 5.55 on surface/background/surface-muted */
/* Kept at its existing value on purpose. The rebrand document proposed
#74807C for this slot; that measures 3.79 on --pet-background and fails
the 4.5:1 small text owes, so it was not adopted. This tone clears 4.93
on --pet-surface and 4.56 on --pet-background -- but only 4.36 on
--pet-surface-muted, so muted text does NOT go on that ground. Use
--pet-text-secondary there instead; it measures 5.55. */
--pet-muted: #60756d;
/* Lines. --pet-border and --pet-border-strong are decoration -- a card
edge, a rule between rows -- and owe nothing, which is just as well
since they measure 1.30 and 1.62 on white.
--pet-border-input is a separate token because an input's edge is not
decoration: it is the boundary of an interface component, and WCAG
1.4.11 asks 3:1 of it. Neither of the two above comes close. This tone
stays in the same desaturated green-grey family so the form still
matches the cards, and measures 3.79 on --pet-surface, 3.51 on
--pet-background, 3.35 on --pet-surface-muted, and no less than 3.11 on
any other ground in this file. It carries checkbox and radio edges and
the resting border of an outline button for the same reason. */
--pet-border: #DCE3E0;
--pet-border-strong: #C3CECA;
--pet-border-input: #758781;
/* Focus ring. This replaces --pet-yellow, which is gone with the rest of
the yellow.
One flat colour cannot do this job, and the arithmetic says so rather
than taste: 3:1 against --pet-surface caps the ring's relative
luminance at 0.30, while 3:1 against --pet-primary -- the footer and
cookie-banner ground, where focus rings genuinely land -- demands
either 0.3745 and up or 0.0022 and down. The second window is darker
than #000, which measures 2.83 against --pet-primary. There is no
value that satisfies both.
So the ring is one token with a scoped override rather than one fixed
colour: dark on every light ground, white inside the dark green blocks.
Custom properties inherit, so the override below reaches every control
in the footer without touching a single focus rule.
--pet-focus on --pet-surface 12.23, --pet-background 11.31,
--pet-surface-muted 10.82, --pet-primary-soft 10.53,
--pet-accent-soft 10.02 (its worst ground).
#fff on --pet-primary 7.42, on --pet-primary-hover 9.61. */
--pet-focus: #173B37;
/* Status. Each soft tone is the ground its own ink is measured against,
so a notice never has to guess which pairing it is allowed to use. */
--pet-success: #357A57; /* 5.16 on --pet-surface, 4.56 on --pet-success-soft */
--pet-success-soft: #E8F3EC;
--pet-danger: #B44743; /* 5.35 on --pet-surface, 4.50 on --pet-danger-soft */
--pet-danger-soft: #F7E8E7;
--pet-info: #3F7086; /* 5.42 on --pet-surface, 4.70 on --pet-info-soft */
--pet-info-soft: #E8F0F4;
/* WhatsApp. Deliberately NOT the #25D366 of the brand guidelines: white
text on that measures 1.98, and the button carries a word, not just a
glyph. This darker green is the shop's own tone for the same brand.
Known gap, recorded rather than hidden: white on the resting tone is
3.46, which clears the 3:1 a large control owes but not the 4.5:1 its
.9rem label owes; the hover tone reaches 4.72. */
--pet-whatsapp: #1f9d63;
--pet-whatsapp-hover: #168451;
/* The warm accent, split in two because one tone cannot cover both jobs.
--pet-accent measures 2.91 on white: below even the 3:1 floor, so it is
a fill and a decoration and never a foreground -- not text, not a
glyph, not an icon that carries meaning. Dark text sits on it happily
(--pet-text on --pet-accent is 5.38).
--pet-accent-text is the tone for anything that is read or means
something -- eyebrow labels, star rows, the text of a warning: 5.99 on
--pet-surface, 5.54 on --pet-background, 5.30 on --pet-surface-muted,
4.91 on --pet-accent-soft.
On the dark green grounds neither works (--pet-accent is 2.55 on
--pet-primary); warm text there uses --pet-accent-soft, at 6.08. */
--pet-accent: #C98A45;
--pet-accent-text: #865A28;
--pet-accent-soft: #F3E7D6;
/* The shadow tint. Every box-shadow on a light ground in this theme was
already cast in this one colour, written out longhand 24 times across
nine stylesheets at eleven different alphas -- so this token names a
tone the site already draws rather than introducing a new one, and
nothing about the rendered page moves by declaring it. It is named
because a shadow is the one property a new component reaches for with
no token to reach for: the next person writing one had to copy an
rgba() out of a neighbouring file or invent a tint, which is exactly
the drift this set exists to make impossible.
It is NOT --pet-primary-active. That token is 23,59,55; this is
23,52,45, and the four-unit difference is invisible on a 6%-alpha
shadow and completely visible to a grep. Folding one into the other
would be a redesign decision rather than a naming one.
An alpha variant is written color-mix(in srgb, var(--pet-shadow-color)
N%, transparent), never as an rgba() of these channels -- see
tools/design-tokens/browser-check.js, which paints both spellings as
adjacent swatches over an opaque backdrop and compares the composited
bytes, because getComputedStyle serialises the two forms differently
and a computed-style diff reports every touched rule as changed when
nothing moved. */
--pet-shadow-color: #17342D;
/* The same job on the dark green grounds, and it is a different colour
for the same reason --pet-focus is: a tint four units off
--pet-primary-active is invisible against --pet-primary, so the four
shadows that land on a green panel are cast in black instead. Declared
as a token rather than left as four rgba(0,0,0) literals so that a
control moving onto a green ground has a name to use. */
--pet-shadow-color-on-dark: #000000;
--pet-font: "Manrope", "Segoe UI", sans-serif;
--pet-radius-lg: 24px;
--pet-shadow: 0 14px 32px color-mix(in srgb, var(--pet-shadow-color) 10%, transparent);
}
/* The other half of the focus ring, per the reasoning in --pet-focus above.
These two are the only grounds on the site where a focus ring is drawn on
top of --pet-primary rather than on a light surface, so they are the only
two that need the light half of the pair. */
.pet-footer,
.pet-cookie-banner { --pet-focus: var(--pet-surface); }
html { scroll-behavior: smooth; }
body, button, input, select, textarea { font-family: var(--pet-font); }
/* Explicit background (was unset, defaulting to the browser/theme grey):
.pet-home/.pet-section-page don't paint their own background, so body's
shows through both in their outer gutters and below a short page's footer
-- most visible as a mismatched grey band during mobile overscroll bounce. */
body { background: var(--pet-background); color: var(--pet-text); font-size: 16px; line-height: 1.6; overflow-x: clip; text-rendering: optimizeLegibility; }
/* Mobile browsers paint the ROOT element's background when the user drags
past the end of the page, which showed a cream slab below the dark
footer. overscroll-behavior stops the stretch on current iOS/Chrome.
Do NOT also darken html as a fallback: html's own background stops body's
cream from propagating to the canvas, so any gap the body does not cover
-- short pages, the moment after an in-page jump -- flashes as a black
band. A cream slab under the footer on stale WebKit is the milder bug.
Do NOT add overflow:hidden to body either -- it breaks scrolling, modals
and the mobile menu. */
html, body { overscroll-behavior-y: none; }
/* Owner's request: visitors dragging out page copy with the mouse. This is
a browser-side inconvenience, not content protection -- devtools, "view
source" and copying from search-result snippets all still work, and it
has to stop short of form fields (a non-selectable input is unusable) and
of the data people actually need to copy to act on it: phone, email,
address/hours and any price, wherever it's rendered. */
body { -webkit-user-select: none; user-select: none; }
input, textarea, [contenteditable],
.pet-contact-panel,
.pet-product-price, .pet-product-detail-price, .pet-legacy-price,
.woocommerce-Price-amount {
-webkit-user-select: text;
user-select: text;
}
[lang="he"], [lang="he"] button, [lang="he"] input, [lang="he"] select, [lang="he"] textarea { font-family: "Noto Sans Hebrew", var(--pet-font); }
h1, h2, h3, p { overflow-wrap: break-word; }
a:focus, button:focus, summary:focus { outline: 0; }
/* Fields are in this list and not in the outline: 0 rule above, so a browser
that does not support :focus-visible still shows its own ring on them
rather than nothing at all. */
a:focus-visible, button:focus-visible, summary:focus-visible,
input:focus-visible, select:focus-visible, textarea:focus-visible { outline: 3px solid var(--pet-focus); outline-offset: 3px; }
/* Checkboxes and radios are drawn by the browser, so their unchecked edge is
not ours to style without rebuilding the control, which this pass is not
doing. What is ours is the checked fill: --pet-primary takes a white tick
at 7.42, and browsers pick the tick's colour from this value's own
luminance. */
input[type="checkbox"], input[type="radio"] { accent-color: var(--pet-primary); }
/* Text for screen readers only. The theme has been relying on WordPress core
and WooCommerce to style this class, which works until a page loads neither
-- and then the word appears in the middle of the header. Clip rather than
display:none or visibility:hidden: those two remove the text from the
accessibility tree as well, which is the opposite of the point. */
.screen-reader-text {
border: 0;
clip-path: inset(50%);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
white-space: nowrap;
width: 1px;
}
/* #top and #pet-main are jump targets, not controls. They carry tabindex="-1"
so that following the wordmark or the skip link moves the reading position
as well as the scroll -- but they are full-width bands, and the browser's
default ring around one reads as a stray dark rule under the header rather
than as a focus indicator. The focus still lands; it just is not drawn. */
#top:focus, #pet-main:focus { outline: 0; }
/* overflow-x: clip, NOT overflow: hidden -- and the difference is a bug that
shipped. `hidden` makes this element a scroll container, which silently
becomes the nearest scrollport for every `position: sticky` descendant on
every page. The shell is not itself scrollable (the document scrolls on the
viewport), so a sticky child had nothing to scroll against and never
floated: it just rendered in place, exactly as if the sticky were ignored.
That is what killed the fish page's floating species filter (85-section-jump.css).
`clip` clips the same overflow -- which is all this rule ever wanted, and
only on the inline axis, where full-bleed sections would otherwise push a
horizontal scrollbar -- without establishing a scroll container, so sticky
descendants resolve against the viewport again. body already uses `clip`
above for the same reason. Do not change this back to `hidden`.
display: flow-root comes with it, and is not decoration. `overflow: hidden`
was doing a second, invisible job here: it established a block formatting
context, which contains floats and stops a first/last child's vertical
margin collapsing out through the shell. `clip` establishes no BFC, so
dropping `hidden` on its own would have changed page spacing everywhere as
a side effect of a fish-page fix. flow-root is the BFC with none of the
scroll-container baggage, so the two lines together are exactly the old
behaviour minus the sticky bug. */
.pet-page-shell { display: flow-root; overflow-x: clip; padding-left: 0 !important; padding-right: 0 !important; }
.pet-page-shell > .wp-block-post-content { box-sizing: border-box; left: auto; margin: 0; max-width: none !important; padding-left: 0 !important; padding-right: 0 !important; position: relative; transform: none; width: 100% !important; }
.pet-home { color: var(--pet-text); margin: 0 auto; max-width: 1280px; width: min(100%, calc(100vw - 48px)); padding: 0 24px; }
.pet-site-header,
.pet-site-header > .wp-block-group { box-sizing: border-box; max-width: none !important; width: 100% !important; }
/* position: relative anchors the hamburger nav panel (60-legal.css,
.pet-nav-is-open .pet-primary-nav): position: absolute; top: 100% inside
it sits flush against this element's own bottom edge, at any header
height, rather than a hardcoded offset that would drift out of sync with
the header's actual (responsive) height. */
.pet-site-header { margin-inline: auto !important; padding-block: 20px; position: relative; }
/* Running text is not a control, so it does not answer the pointer: a click on
a heading or a paragraph passes through to whatever is behind it rather than
landing on the words.
Everything interactive inside that text is put back explicitly. Without the
second rule a link inside a sentence, and every nav item -- which is an
inside an