/* PinkyDolly V2 · 基础层:令牌 / reset / 排版工具类 / 按钮
 * ⚠️ 这一层的令牌应与 Phase 1 的 pd-v2-tokens.css 合并,不要重复定义。
 */

:root{
  --main1:#F1B1FF; --main2:#FF9DCA;
  --btn1:#C527F3;  --btn2:#FE0373;
  --act:#CB025C;   --act2:#A922D1;
  --mint:#9AF5D8;  --lemon:#FFF14F;
  --bw:#FFF7F1;    --bk:#262026;

  --disp:Fraunces,Georgia,serif;
  /* SPEC-typography.md: exactly two Fraunces styles sitewide, nothing else.
     --fx is kept (unchanged value) only because a few files still reference
     it directly during this migration; new code should reach for
     --fr-display/--fr-text instead. Text = optical size auto for everything
     smaller than 24px. Both get weight from their own font-weight
     declaration (650 / 600) wherever they're applied — never any other
     weight on Fraunces, and never the Display opsz value paired with
     font-optical-sizing:auto on the same element (auto would re-decide the
     optical size itself, fighting the manual value).

     2026-10-11(SPEC-typography-v2-opsz72.md, approved): Display moves from
     opsz 144 to opsz 72, same weight — the team found 144's hairlines too
     thin (stem/hairline contrast 8.5x, dropping to 6x at 72; glyphs ~12%
     wider). This is the ONLY place the number should ever be written —
     every Display rule reads var(--fr-display) instead of repeating the
     literal value, specifically so this one edit is the whole migration
     next time it changes. `grep -rn '"opsz" 144'` across public/css should
     come back empty (comments aside). */
  --fx:"SOFT" 0,"WONK" 0;
  --fr-display:"opsz" 72,"SOFT" 0,"WONK" 0;
  --fr-text:"SOFT" 0,"WONK" 0;
  --ui:"Nunito Sans",system-ui,-apple-system,sans-serif;
  --r:6px; --pill:999px;
  --e:cubic-bezier(.16,1,.3,1);
  --e-in:cubic-bezier(.22,1.14,.36,1);   /* 进场:轻微过冲 */
  --e-out:cubic-bezier(.22,.61,.36,1);   /* 退场:纯缓出,更慢 */
  --gut:clamp(16px,4vw,56px); --maxw:1320px; --navh:62px;
}
html[data-mode="light"]{
  --bg:var(--bw); --surface:#FFFDFA; --raise:#F8EDE8;
  --tx:var(--bk); --tx-dim:#6E626E; --tx-faint:#9A8E9A;
  --line:rgba(38,32,38,.14);
  --navbg:rgba(255,247,241,.88);
  --scrim:linear-gradient(96deg,rgba(255,247,241,.95) 0%,rgba(255,247,241,.8) 36%,transparent 78%);
}
html[data-mode="dark"]{
  /* --surface here is var(--bk) = #262026, not the prototype's #221A21 —
     accepted repo-vs-prototype drift, repo wins (T6/T7 precedent). */
  --bg:#1A1118; --surface:var(--bk); --raise:#332A33;
  --tx:var(--bw); --tx-dim:rgba(255,247,241,.68); --tx-faint:rgba(255,247,241,.38);
  --line:rgba(255,247,241,.14);
  --navbg:rgba(26,17,24,.9);
  --scrim:linear-gradient(96deg,rgba(14,8,13,.86) 0%,rgba(14,8,13,.6) 36%,transparent 78%);
}
*,*::before,*::after{box-sizing:border-box}
/* html itself had no background (only body did) — transparent falls back
   to the browser's white canvas, which shows during iOS overscroll bounce
   in dark mode (SPEC §0.2 / LESSONS L7). */
html{-webkit-text-size-adjust:100%;scroll-behavior:smooth;scroll-padding-top:var(--navh);
  background:var(--bg);font-optical-sizing:auto}
/* SHOPLINE's own outer wrapper (#page.pls-site-wrapper) has a hardcoded
   background-color:#fff in theme.css. Any pd-v2 section with no
   background of its own (or not yet built, on pages still to come) falls
   through to this white, not body's --bg — this is the wrapper SPEC §0.2
   calls out by name ("SHOPLINE 的外层包裹元素"). */
.pls-site-wrapper{background:var(--bg)}
body{margin:0;background:var(--bg);color:var(--tx);font-family:var(--ui);
  /* 16px, not the prototype's 15px — accepted repo-vs-prototype drift,
     repo wins (T6/T7 precedent). */
  font-size:16px;line-height:1.75;-webkit-font-smoothing:antialiased;overflow-x:hidden;
  transition:background .45s var(--e),color .45s var(--e)}
/* Migrated WordPress rich-text content (blog articles, policy pages — both
   use .rte, confirmed via grep as the only two) bakes hardcoded inline
   color styles directly onto text spans (e.g. <span style="color:
   #000000">), predating dark mode entirely. No stylesheet rule, however
   specific, can win against an inline style without !important — this is
   exactly the case !important exists for: third-party content we don't
   control and aren't rebuilding (item 2 review), not our own CSS fighting
   itself. Scoped to dark mode only — the original light-mode appearance
   (what these inline colors were actually authored for) is untouched. */
html[data-mode="dark"] .rte *{color:var(--tx)!important}
img,svg,video{display:block;max-width:100%}
p{margin:0} a{color:inherit;text-decoration:none}
/* 2026-10-13(反馈:博客文章正文段落之间没有空隙,"字挤在一起不好读"):
   这条全局 p{margin:0} reset 是给 pd-v2-* 组件用的,它们都自己精确控制
   间距。.rte(article-detail、policy-page 两处后台富文本正文的公用类)没有
   自己的段落间距规则,一直靠的是 theme.css 里那条旧的 p{margin:0 0 1.5rem}
   ——全局 reset 比它晚加载、选择器优先级一样,新的会盖掉旧的,.rte 里的
   段落就跟着被拍扁了,从没被 pd-v2 设计过的长文内容不该被这条 reset 波及。
   原样把旧版的 1.5rem 还给 .rte 自己,不影响别处。 */
.rte p{margin:0 0 1.5rem}
/* Safety net for the hover-colour bug the contrast audit (feedback item 5) found
   on three unrelated links (.more, .foot__mail, .side__go — see each file's own
   comment): any <a> with no hover colour of its own falls back to theme.css's
   bare a:hover{color:var(--pls-link-hover-color)}, a darkened pink that fails
   against dark surfaces. Rather than keep finding these one at a time, this
   cancels that fallback for every link in a pd-v2 section by default — hover
   stays the same colour as normal state, same as not having a hover colour rule
   at all, which is always a safe/passing choice since it's just the colour
   already in use. [class*="pd-v2-"] a:hover is (0,2,1) specificity, tied with a
   real component rule like .pd-v2-nav__l a:hover (also class+element+pseudo);
   ties go to source order, and this file loads before every other pd-v2-*.css,
   so a specific later rule still wins — this is strictly a fallback for links
   that don't have one, not an override of ones that do.
   :not(.pd-v2-action) — found the hard way, by re-running the audit after
   adding this: .pd-v2-action is sometimes an <a> (hero CTAs, the cross-collection
   banner's "See what Dolly picked" link, home's "Pick Your Type of Trouble"),
   and this rule's (0,2,1) beat its own (0,1,0) color:#fff with nothing to lose
   to, so the button's hover text silently went dark-on-pink (3.11:1) exactly
   like the earlier color:inherit button bug. .pd-v2-action's own hover state
   only ever changes background (see pd-v2-header.css), never color, so it needs
   this fallback to not apply to it at all, the same way the button color:inherit
   fix above excludes it.
   :not(.side__go) — same bug, same fix, found the same way: pd-v2-twins.css's
   own .side--p/.side--d .side__go:hover rules (0,3,0) lost the colour half of
   their hover state to this rule's (0,3,1), going white-text-on-white-
   background on hover even though their background half applied correctly
   (background isn't touched here, only colour). */
[class*="pd-v2-"] a:hover:not(.pd-v2-action):not(.side__go){color:inherit}
/* Scoped to pd-v2 sections only (not a bare `button{}` reset). A global
   reset here was stripping the background off legacy buttons we haven't
   rebuilt and never touch — confirmed on /cart, /user/signIn and policy
   pages: the legacy newsletter widget's bare <button> (no class of its
   own) lost its background and was left with dark text and nothing to
   contrast against.
   background/border are deliberately NOT reset here: this selector's
   specificity (0,1,2) beats a single class like .pd-v2-action--1 or
   .p__cta button (0,1,0 / 0,1,1), so a blanket background:none/border:0
   was winning over — and silently flattening — buttons that have their
   own real background (confirmed on #mailGo and the product-card
   add-to-cart button, both went transparent). Those two properties are
   set narrowly instead, only on the specific bare icon buttons that
   actually need them (.pd-v2-nav__t button, below).
   Same reasoning applies to `font` here, found later by T6's prototype
   diff: `font:inherit` is shorthand for family+size+weight+style+line-
   height, and at (0,1,2) it was *also* beating .p__cta button's own
   font-size/weight (0,1,1) — the home quick-view's add-to-cart button
   had silently been rendering at the body's 16px/400 instead of its
   intended 13px/700 this whole time, undetected because the old
   class-only scan couldn't see an element-selector collision. Narrowed
   to font-family only, which is the actual UA-default this rule was
   added to fix (a bare legacy <button> rendering in a system font) —
   size/weight/line-height are left for whichever rule is actually most
   specific to decide, same principle as background/border above.
   `color:inherit` hit the exact same class of bug, found by the sitewide
   contrast audit (feedback item 5): #mailGo (the newsletter Join button)
   and every <button>-tag .pd-v2-action — Add to cart, Buy it now, all of
   them — were rendering dark ink text on their own pink/purple
   backgrounds in light mode (2.81:1, nowhere near the 4.5:1 a 14px label
   needs), because this rule's (0,1,2) also beats .pd-v2-action--1's own
   color:#fff (0,1,0), same way it beat .p__cta button's font-size above.
   In dark mode body text happens to be off-white too, so the inherited
   color looked plausible by accident and the bug went unnoticed until a
   real contrast measurement, not a glance, caught it. :not(.pd-v2-action)
   keeps the original fix for whatever bare legacy button still needs it
   (that's what "dark text and nothing to contrast against" above was
   about) without re-touching the one button system that already has its
   own correct, explicit color per variant. */
section[class*="pd-v2-"] button:not(.pd-v2-action){font-family:inherit;color:inherit;cursor:pointer}
section[class*="pd-v2-"] button.pd-v2-action{font-family:inherit;cursor:pointer}
/* Default = Display (every h1-h4 sitewide starts ≥24px unless a page's own
   CSS says otherwise for a specific small heading — see SPEC-typography.md's
   roles table; those overrides set font-variation-settings:var(--fr-text),
   font-optical-sizing:auto and font-weight:600 instead). Tracking stays the
   large-text default (negative) here; the ≤30px roles get +0.02em from
   their own selector, same as the opsz override. */
h1,h2,h3,h4{margin:0;font-family:var(--disp);font-variation-settings:var(--fr-display);
  line-height:1.05;letter-spacing:-.025em;font-weight:650;font-style:normal}
/* Defensive addendum (not part of the deploy package). theme.css has
   h1,h2,h3,h4,h5,h6{color:#1F1F1F} — a direct rule on the element, which
   wins over body's inherited color:var(--tx) regardless of mode, so
   headings stayed near-black and vanished against the dark background. */
h1,h2,h3,h4{color:var(--tx)}
/* h5/h6 weren't covered above — nothing pd-v2 styled used them at the time, but
   the contrast audit (feedback item 5) found a real instance on the legacy
   contact page ("VELOURA INTERNATIONAL TRADE LIMITED" / "Intimate lifestyle
   products", both <h6>): 1.12:1 against dark ink. Color only, not the rest of
   the h1–h4 block above — h5/h6 elsewhere in legacy content aren't meant to
   become Fraunces display headings, just not go invisible in dark mode. */
h5,h6{color:var(--tx)}
/* Defensive addendum (not part of the deploy package). Same theme.css rule
   also sets text-transform:capitalize on every heading tag; nothing above
   touched that property, so it kept winning (tied 0,0,1 specificity,
   theme.css simply has no competing text-transform declaration to lose
   to). Found by scripts/pd-v2-verify.mjs's prototype computed-style diff
   on .hero__h and .p__n — the prototype never sets text-transform, so it
   should inherit "none" like everywhere else. */
h1,h2,h3,h4{text-transform:none}
:where(a,button,input,[tabindex]):focus-visible{outline:2px solid var(--act);outline-offset:3px;border-radius:2px}
/* Defensive addendum (not part of the deploy package). theme.css has
   :focus,button:focus{outline:none} — button:focus is (0,1,1), higher
   than :where(...):focus-visible's effective (0,1,0) (:where() con-
   tributes no specificity), so every <button> sitewide lost its focus
   ring while <a> elements (tied specificity, later source order) kept
   theirs. Confirmed via real Tab navigation: a focused <a> showed
   outline-style:solid; the same test on a focused <button> showed
   outline-style:none. Matches LESSONS L28's pattern, on a different
   element. button:focus-visible here is (0,1,1), same as the legacy
   rule — later source order wins it back for buttons specifically. */
/* 2026-10-10: dropped the border-radius:2px this rule used to also set. It wasn't
   needed for the outline (Chromium already follows a focused element's own
   border-radius automatically) and it was overwriting the actual button's shape —
   caught by pd-v2-verify.mjs on the age gate's "Yes" button, which autofocuses on
   open: a 6px pd-v2-action rendered with 2px corners the instant it was focused. */
button:focus-visible{outline:2px solid var(--act);outline-offset:3px}
/* .t1/.t2 were 900/800 — over the new 700 cap (SPEC §0.1: level-1 titles,
   max 700, logo excepted) and their letter-spacing (-.03em/-.025em already
   borderline) is tightened to the -.02~-.028em band the spec now requires
   instead of the old -.035em-style values. */
.t1{font-weight:650;font-size:clamp(34px,6.2vw,64px);letter-spacing:-.025em;line-height:1.02}
.t2{font-weight:650;font-size:clamp(26px,4.4vw,44px);letter-spacing:-.025em;line-height:1.08}
.t3{font-weight:700;font-size:clamp(21px,3.1vw,30px);letter-spacing:-.02em}
/* Text style (not inherited Display from the h1-h4 base rule) + 0.02em
   tracking — both roles on home (SPEC-typography.md). */
.t4{font-variation-settings:var(--fr-text);font-optical-sizing:auto;font-weight:600;
  font-size:clamp(18px,2.4vw,23px);letter-spacing:.02em}
.t5{font-variation-settings:var(--fr-text);font-optical-sizing:auto;font-weight:600;
  font-size:18px;letter-spacing:.02em;line-height:1.3}
/* 13px, not the original 12px floor (rule 17) — Yimei's feedback: labels/tags/
   eyebrows read too small sitewide. This is the shared .cap class every section's
   eyebrow/kicker uses, so bumping it here raises the realized floor everywhere at
   once rather than touching each section's own copy of it. */
.cap{font-family:var(--ui);font-weight:700;font-size:13px;letter-spacing:.22em;text-transform:uppercase}
/* theme.css (the protected normalize layer, rule 29 — never hand-deleted) sets a
   bare b,strong{font-weight:600}. That's wrong for Nunito body copy — bold must be
   700 — found via the approved spec flagging it on account privacy points, the
   contact page's "Email" label and PDP body text (measured: theme.css's 600 was
   winning there, not some other 400). Override sitewide; same (0,0,2) specificity
   as theme.css's rule but pd-v2-base.css loads after it, so source order wins. */
b,strong{font-weight:700}
/* Fraunces auto-bolds a bare <b>/<strong> to 900 inside anything below
   weight 700 (SPEC §0.1) — scoped to pd-v2 sections (via the ancestor
   section's pd-v2-*-section class) so legacy bold text elsewhere isn't
   touched.
   2026-10-10 fix: this used to match ANY <b>/<strong> inside a pd-v2
   section, not just ones inside a Fraunces HEADING — so the 700 override
   right above this comment was itself getting beaten on plain Nunito body
   copy inside a pd-v2 section (account privacy points, contact page's
   "Email" label, PDP body text), inheriting the surrounding paragraph's
   normal 400 instead of staying 700. Per the approved spec, only
   <b>/<strong> inside an actual Fraunces heading (h1–h4 — see the global
   h1,h2,h3,h4 rule below) should inherit the heading's own weight.
   Narrowed to h1–h4 descendants only. */
[class*="pd-v2-"] h1 b,[class*="pd-v2-"] h1 strong,
[class*="pd-v2-"] h2 b,[class*="pd-v2-"] h2 strong,
[class*="pd-v2-"] h3 b,[class*="pd-v2-"] h3 strong,
[class*="pd-v2-"] h4 b,[class*="pd-v2-"] h4 strong{font-weight:inherit}
/* Serious, sitewide contrast bug (found via the PDP accordion's rich-text <b> lead-ins,
   "Never microwave or boil" etc., reading near-invisible in dark mode): theme.css has
   a bare b,strong{color:var(--pls-heading-color)} rule, and pd-v2-tokens.css points
   --pls-heading-color at --pd-ink — a single hardcoded #262026 with no dark-mode
   override anywhere (confirmed: grepped every --pd-ink definition, none are
   conditioned on html[data-mode]). In light mode that's dark text on a light
   background, fine; in dark mode it's near-black text on a near-black background,
   failing contrast outright. This hits every <b>/<strong> coming from settings-driven
   rich text in any pd-v2 section (acc_*_body, trust_*, feel_* — anywhere {{{ }}}
   renders merchant HTML with inline <b> tags), not just this one accordion. Same
   specificity reasoning and same tie-breaking as the font-weight rule above: a
   component with its own explicit <b> color (e.g. .buy__pr b for the price, .p__pr b
   for the collection-card price) is strictly more specific or comes later in source
   order, so it still wins over this inherit. */
[class*="pd-v2-"] b,[class*="pd-v2-"] strong{color:inherit}
/* Same bug, outside any pd-v2 section this time — the contrast audit (feedback
   item 5) also found it on the legacy contact page's "Email" <strong> (1.16:1,
   dark ink on dark ink, in a plain Elementor text block pd-v2 never touches) and
   on blog-article comment-form copy. Sitewide dark mode (item 2 of this project)
   means legacy content renders on a dark background now too, so this isn't
   scoped to pd-v2 markup — it's wherever a bare <b>/<strong> meets dark mode,
   which is everywhere. Bare b,strong{color:var(--pls-heading-color)} in theme.css
   is (0,0,1); this is the same specificity, but pd-v2-base.css loads after
   theme.css, so source order wins it. Light mode is unaffected either way —
   var(--pls-heading-color) and the inherited colour are the same dark ink there,
   so this only changes the dark-mode case that was actually broken. */
b,strong{color:inherit}
/* Legacy Elementor contact-page bug, found by the contrast audit (feedback item 5):
   the "Get in touch!" heading + its privacy paragraph sit in an Elementor
   container (.elementor-element-8fc4891) whose fill comes from an Elementor global
   color variable pd-v2-tokens.css points at --pd-paper (always warm-white, no
   html[data-mode] override) — so this one container stays light regardless of
   mode, while the heading/paragraph text correctly tracks the mode-aware --tx and
   turns off-white in dark mode, landing white-on-white (1.00:1). The text, not the
   background, is what's wrong relative to this container's actual (mode-
   independent) fill — overriding color here is more targeted than trying to make
   that Elementor global-color slot mode-aware, which other Elementor widgets on
   other legacy pages may also read for purposes this session hasn't audited.
   Flagged to Yimei as a pattern that may recur on other Elementor pages/blocks
   this round didn't sample — see the T7 fix-round report. */
.elementor-element-8fc4891 h2,
.elementor-element-8fc4891 p{color:var(--pd-ink)}
/* Same pattern, found on the blog article's comment form: .comment-respond has a
   fixed rgb(255,247,241) (--pd-paper) background with no html[data-mode] override,
   while its own title/notice text correctly tracks mode-aware --tx — "Leave Your
   comment" (<h3>, needs 3:1 at this size) and the "Your email address..." notice
   both measured 1.00:1 in dark mode, white-on-white. Same fix: pin the text to
   this form's one actual (mode-independent) background instead of chasing the
   background's own source into generic WooCommerce comment-form styling other
   legacy pages may also use. */
.comment-respond h3,
.comment-respond .comment-notes{color:var(--pd-ink)}
/* Blog article/sidebar: .posted-date a and the categories widget's links had a
   fixed dark colour (1.16:1 against dark-mode's actual off-white ambient text
   colour — confirmed the surrounding .widget already correctly computes
   rgb(255,247,241), it's specifically these <a> tags overriding back to dark).
   inherit, not a hardcoded value, since the right colour is just whatever text
   colour the page already has here — same reasoning as the a:hover safety net
   in this file. */
.posted-date a,
.cat-item a,
.widget a{color:inherit}
/* .cat-item a above still lost to theme.css's
   ".pls-widget-area .widget:not(.pls-posts-lists, .pls-recent-posts, ...) a
   {color:var(--pls-text-color)}" — found by disabling stylesheets one at a
   time and watching getComputedStyle flip. Its specificity is 3 classes +
   1 element, not 2: :not()'s argument counts as a class of its own, on top
   of .pls-widget-area and .widget themselves — (0,3,1), which beats our
   one-class .cat-item a outright regardless of source order. .widget_categories
   isn't in that rule's :not() exclusion list (unlike .pls-recent-posts, which
   is why recent-posts dates never failed). Matched to 4 classes here
   (.pls-widget-area .sidebar-inner .widget .cat-item a) for a real margin
   over (0,3,1) instead of another exact tie. */
.pls-widget-area .sidebar-inner .widget .cat-item a,
.pls-widget-area .sidebar-inner .widget a{color:inherit}
/* "Share:" label on the blog article's social-share widget: --pls-link-color
   (--pd-act) measured 3.26:1 against --bg specifically (darker than the --surface/
   --bk shades the other --pd-act fixes in this project were checked against) —
   --pd-act genuinely doesn't clear 4.5:1 on any of this theme's dark-mode
   backgrounds. Same --main2/--act mode-pairing as .head .cap and .more:hover. */
.pls-social-title{color:var(--act)}
html[data-mode="dark"] .pls-social-title{color:var(--main2)}

/* Blog article, 2026-10-12 Yimei round:

   1. Featured image had no height cap at all (width=1400, height:auto via the
      "fill" object-fit the legacy CSS gives it) — on a 1024x1024 source it
      rendered as a literal 960px-tall square on desktop, pushing the title
      and body off the first screen. First attempt capped the height and
      cropped via object-fit:cover — Yimei caught that this cuts off part of
      a square image that should show in full, and asked for the real fix
      instead: narrow the main column so the (still full, uncropped) square
      scales down with it. Column split changed from 9/3 to 7/5 in
      article-detail.html's own col-lg-*/col-xl-* classes; this rule just
      makes sure the image itself stays uncropped at whatever width that
      column gives it. */
.pinky-article-detail .post-thumbnail img{width:100%;height:auto;object-fit:contain}

/* 2. .comment-respond's fixed --pd-paper background (see the h3/.comment-notes
      fix above this block) was only ever patched for its own text contrast,
      not given a dark-mode background — so it stays a bright warm-white card
      on an otherwise dark page. Same for its three fields and the submit
      button, which all inherit the same fixed light fill. Rather than invent
      a new "card" look this component never had in light mode (where the
      fixed fill happens to match the light-mode page background and so reads
      as invisible, not as a panel), this makes dark mode do the same thing:
      transparent, bordered, blending into the page like light mode already
      effectively does. */
html[data-mode="dark"] .comment-respond{background:transparent}
html[data-mode="dark"] .comment-respond .form_control{background:transparent;color:var(--tx);border-color:var(--line)}
html[data-mode="dark"] .comment-respond input.submit{background:transparent;color:var(--tx);border-color:var(--tx)}
/* 2b. 2026-10-12, Yimei caught this one live: making the background
       transparent above left .comment-notes still using the OLD fix's
       --pd-ink (a flat dark colour, correct only against the fixed light
       background that no longer applies in dark mode) — dark text on a
       dark page, nearly unreadable. Same blind spot for placeholder text,
       which was never styled at all and just inherited the browser's own
       default grey, too faint against dark mode's own page colour. Both
       fixed with mode-aware tokens instead of flat colours this time. */
html[data-mode="dark"] .comment-respond .comment-notes{color:var(--tx-dim)}
.comment-respond .form_control::placeholder{color:var(--tx-faint);opacity:1}

/* 3. .navigation.post-navigation carries a fixed border-top regardless of
      whether it has a real previous/next article to show — on this store
      (one blog, few posts) both links usually stay [hidden] via
      pd-v2-article-navigation.js, leaving a bare divider line with nothing
      under it, right below the share row. Only draw the line when at least
      one real link is visible. */
.navigation.post-navigation{border-top:0}
.navigation.post-navigation:has(.pls-nav-previous:not([hidden])),
.navigation.post-navigation:has(.pls-nav-next:not([hidden])){border-top:1px solid var(--line)}

/* 4. Sidebar should act as a sticky "guide rail" (Yimei's own phrase) rather
      than scrolling away above the much taller main column. #secondary was
      already as tall as #primary purely from the legacy .row's flex default
      (align-items:normal behaves as stretch for a flex row) — sticky on an
      element that's already stretched to its container's full height has no
      visible range to work with, so align-items:flex-start first lets both
      columns size to their own real content before the sidebar is pinned.
      Desktop/tablet only (matches the layout's own md breakpoint, below
      which the columns stack full-width and a stuck sidebar would just be
      in the way). */
@media (min-width:768px){
  .pinky-article-detail .row{align-items:flex-start}
  .pinky-article-detail #secondary{position:sticky;top:calc(var(--navh) + 20px)}
}

/* 5. Comment section moved from the main column into the sidebar as its own
      widget (article-detail.html). Reframed for the sidebar's much narrower
      column instead of the main column's wider one:
      - .comment-form-author/.comment-form-email are 50/50 side-by-side in
        the main column (post-1556.css) — too cramped at sidebar width, so
        full width here instead, stacked.
      - Existing-comments list ("N Comments") reuses the widget's own
        <h3 class="widget-title">, so its own heading drops to h4 and loses
        the (now-duplicate) margin/size the old <h3 id="reply-title"> had. */
.pd-v2-sidebar-comments .comment-form-author,
.pd-v2-sidebar-comments .comment-form-email{flex:1 1 100%!important}
.pd-v2-sidebar-comments .comment-list{padding-left:0;list-style:none}
.pd-v2-sidebar-comments h4{font-size:15px;margin:0 0 14px}

/* 6. 2026-10-13, Yimei caught this one too: the sidebar's "Subscribe For
      Newsletter" widget (.pls-newsletter-widget, legacy Fashion-theme
      markup — same "fixed light fill, never given a dark-mode background"
      issue as the comment form above, just never touched when that one
      was fixed) stayed a bright warm-white card with its own flat-colour
      input in the middle of an otherwise dark page. Same treatment: make
      dark mode transparent/bordered instead of inventing a new card look,
      mode-aware tokens for the input instead of the fixed light fill. */
html[data-mode="dark"] .pls-newsletter-widget .pls-newsletter{background:transparent;color:var(--tx)}
html[data-mode="dark"] .pls-newsletter-widget input[type="email"]{background:transparent;color:var(--tx);border-color:var(--line)}
.pls-newsletter-widget input[type="email"]::placeholder{color:var(--tx-faint);opacity:1}
/* 2026-10-13(反馈,blog 列表页):.pls-newsletter 上的 color:var(--tx) 没能
   救到标题和表单 label——这两个元素各自在旧版 CSS 里还有自己的一条显式
   color 声明(分别约 #1f1f1f 和 #262026),子元素自己的显式声明总是赢过从
   祖先继承来的颜色,跟选择器优先级无关。单独补上这两个才是真的全部盖到。 */
html[data-mode="dark"] .pls-newsletter-widget .subscribe-tagline{color:var(--tx)}
html[data-mode="dark"] .pls-newsletter-widget label{color:var(--tx)}