/*
 * gpluo.cn — dark mode: the pieces the theme's dark CSS never reaches.
 *
 * The theme (Sakurairo 2.6.3.1) ships 129 body.dark selectors in style.css plus
 * the 深色模式 block the BT panel writes into <head>, and most of the site
 * does convert: the post cards, the footer, pagination, the cover card, the
 * social icons, the floaters, the skin menu, our omikuji card and the assistant
 * window all measured correct in the dark run. These are the ones that did not.
 *
 * (No close-comment marker appears inside this banner or inside any other comment
 * in the file: CSS comments do not nest, and the two-character sequence that
 * closes one would end the block early and hand the rest of the text to the
 * parser as garbage. That is not hypothetical — the first version of this file
 * wrote that sequence in this very sentence, the garbage it produced contained
 * unterminated quotes, Chrome parsed zero rules out of the whole stylesheet, and
 * dark mode looked completely unchanged while the file served fine at 200.)
 *
 * Everything here is scoped to body.dark, so light mode is byte-for-byte
 * untouched, and the file is the whole feature: delete it and the site is back to
 * the theme's own dark mode.
 *
 * Measured on 2026-10-19 with dark forced on (localStorage.dark='1', which is
 * what the panel's own day/night button writes) — dark_probe.py for computed
 * styles, px.swift for the composited pixels off a screenshot, because on this
 * site a computed colour and the colour you see are not the same number: the
 * surfaces are translucent over a photograph.
 *
 * Loaded by gpluo-dark.php at wp_enqueue_scripts priority 99, after the theme and
 * after the plugins, which is what it needs to be: several of the rules below
 * have to beat an inline style attribute or a theme rule that is already
 * !important.
 */

/* ------------------------------------------------------------------------- 0.
 * The wallpaper, which is where the "严重的色差" actually comes from.
 *
 * The theme writes an inline style on <body>:
 *
 *   background-image: url(".../Sakurairo-child/random_pic.php")   (a random photo,
 *   background-attachment: fixed, background-size: cover, background-color: clear)
 *
 * Dark mode's image dimming (theme_darkmode_img_bright, filter:brightness) only
 * reaches <img>, <iframe>, .highlight-wrap and aplayer — never a background
 * image. So in dark mode the wallpaper stayed at full brightness while every
 * surface on top of it went to rgba(51,51,51,.55), and each of those surfaces
 * picked up the photo's own colour: the article body measured #595451, a muddy
 * brown-grey, because that is 55% of #333 over a warm photograph.
 *
 * background-blend-mode multiplies the photo against the body's own
 * background-color and nothing else — it does not inherit, and it does not touch
 * the images in the post body or the footer's own background. #2e2e2e leaves the
 * wallpaper at roughly a fifth of its brightness, which is what the theme's dark
 * design assumes behind its translucent surfaces.
 *
 * html.gpluo-dark-early is the class gpluo-dark.php adds in <head> before the
 * first paint; body.dark is the theme's own and arrives with js/app.js in the
 * footer. Same declarations, so the canvas is dark either way.
 *
 * UPDATED 2026-10-19 evening, after the owner reported the front-page 大图 too
 * dark: this canvas is also the front cover's brightness, because the cover
 * photograph IS the wallpaper (site_bg_as_cover) and it is the one picture on the
 * site that sits *under* every dark surface instead of above one. Section 11
 * explains the stack and the arithmetic; the short version is that at #2e2e2e the
 * photograph arrives at 18% of itself and the visitor is really looking at the
 * theme's dark board, not at a dimmed picture. So the canvas lifts — but only
 * while there is a photograph to multiply, which the second rule states by
 * matching the inline style app.js writes. Before that moment (and on a site with
 * the wallpaper switched off) the canvas stays #2e2e2e, so there is no grey flash
 * and no light page background.
 */
html.gpluo-dark-early body,
body.dark {
	background-color: #2e2e2e;
	background-blend-mode: multiply;
}

/* (0,3,1) beats the rule above's (0,1,2), and it cannot match until app.js has
 * put the wallpaper on the element: `document.body.style.backgroundImage = ...`
 * serializes to a style attribute containing "background-image". #8c8c8c leaves
 * the photograph at about half brightness, which is what section 11's ramp needs
 * to make the cover read as a photograph; the page background behind the cards
 * picks up only 10% of it through the theme's own rgba(51,51,51,.9) board, which
 * moves the front page from #2E2D2D to #343131 — the same level the article body
 * already measures (#373737), so the two pages agree rather than diverge.
 *
 * Scoped to .home (the front page) as a precaution rather than as a measured fix:
 * an article page's background is not covered by that board the way the front
 * page's is, so a brighter canvas could wash it. Measured with the photograph
 * pinned, the difference is one level (article-page margin #323232 scoped vs
 * #333333 unscoped, and three unpinned runs of the same page all land at
 * #323232-#333333 either way), so the scoping costs nothing and keeps the change
 * to the page that needed it. An earlier reading of #525253 on that page, which
 * looked like a wash, was an artifact: #main-container has
 * `transition: background 0.8s` (style.css:7906) and the harness that took that
 * frame does not kill animations, so it caught the board mid-fade over the
 * brighter canvas.
 */
body.dark.home[style*="background-image"] {
	background-color: #8c8c8c;
}

/* ------------------------------------------------------------------------- 1.
 * The floating header pill — the one bug on every page of the site.
 *
 * style.css gives .site-header `background-color: rgba(255,255,255,.8)` and the
 * scrolled solid state .site-header.yya `rgba(255,255,255,.9)`. The theme's only
 * dark rule for the header is a :hover (background #333333), so in dark mode the
 * bar stayed light while the theme went and recoloured the menu text inside it to
 * #CCCCCC (body.dark .site-top ul li a).
 *
 * Measured in the dark run: bar #E8D0D1 (L=0.84), text #CCCCCC (L=0.80) — a
 * contrast ratio of about 1.06:1. The navigation was effectively invisible, on
 * every page, at the top of the screen.
 *
 * The recipe is the theme's own for dark surfaces (its #changskin / .links ul li /
 * #pagination a rules): rgba(26,26,26,.6) at rest with a #7d7d7d30 hairline and a
 * 20px dark bloom, rgba(26,26,26,.8) plus a --theme-skin-dark glow on hover. The
 * alphas here are a little higher than the theme's .6 because this surface is a
 * full-width bar over a bright cover photo rather than a 45px button, and .6 read
 * as washed-out grey in the screenshots.
 */
body.dark .site-header,
body.dark .site-header.yya {
	background-color: rgba(26, 26, 26, 0.72);
	border-color: #7d7d7d30;
	box-shadow: 0 1px 12px 1px rgba(26, 26, 26, 0.72);   /* section 15's shorter tail */
}

/* style.css has `body.dark .site-header:hover{background:#333333}`; this rule has
   the same specificity and loads later, so the hover keeps the theme's own
   translucent look instead of flipping to opaque #333 mid-hover. */
body.dark .site-header:hover,
body.dark .site-header.yya:hover {
	background-color: rgba(26, 26, 26, 0.86);
	box-shadow: 0 1px 30px -2px var(--theme-skin-dark, #ff8484);
}

/* The search icon and the avatar sit in that bar and are not covered by the
   theme's `body.dark .site-top ul li a` rule, which only reaches anchors. */
body.dark .site-header .searchbox,
body.dark .site-header .searchbox i {
	color: #cccccc;
}

body.dark .site-header .header-user-avatar img {
	border-color: rgba(232, 232, 232, 0.25);
}

/* The dropdowns under the avatar and under a menu item are already dark (the
   theme lists .header-user-menu and .lower li ul in its rgba(51,51,51,alpha)
   rule), but their text was still inheriting the light-mode ink in one state. */
body.dark .lower li ul,
body.dark .header-user-menu {
	color: #cccccc;
}

/* -------------------------------------------------------------------------- 2.
 * Code blocks. The theme has no rule for these at all.
 *
 * style.css darkens its own code wrapper (.highlight-wrap, via
 * filter:brightness on the theme_darkmode_img_bright knob) and styles `code`, but
 * the posts do not use either: 34 of them hold code-block-pro blocks rendered by
 * Shiki with the **rose-pine-dawn** theme, and Shiki bakes the colours in as
 * inline styles — `pre class="shiki rose-pine-dawn" style="background-color:
 * #faf4ed"` and one `style="color: #…"` per token span. (The other 88 code blocks
 * use dark-plus, which is already dark and needs nothing.)
 *
 * So in dark mode a code block was an ivory card in the middle of a dark page:
 * #FAF4ED measured inside a page whose body text sits on #2b2b2b.
 *
 * code-block-pro 1.26.1 has no dark-mode support of any kind — no
 * prefers-color-scheme, no --shiki-dark variables, no second theme — so the
 * colours cannot be swapped by the plugin and there is nothing to re-save. The
 * map below is the fix: rose-pine-dawn's nine token colours to the light,
 * hue-preserving equivalents from the rose-pine dark family, with !important
 * because every one of them is an inline style.
 *
 * The `i` flag on the attribute matches is load-bearing: the baked hexes are
 * mixed case in the post content (#575279 next to #9893A5).
 */
body.dark .wp-block-kevinbatdorf-code-block-pro,
body.dark .wp-block-kevinbatdorf-code-block-pro pre.shiki,
body.dark .wp-block-kevinbatdorf-code-block-pro [style*="#faf4ed" i] {
	background-color: #232122 !important;
	/* rose-pine's own base for the dark variants */
}

body.dark .wp-block-kevinbatdorf-code-block-pro {
	/* The gutter numbers are a custom property set inline, so a plain declaration
	   would lose to the attribute; !important is what beats an inline value. */
	--cbp-line-number-color: #908a92 !important;
	color: #e0def4;
}

/* text */
body.dark .shiki span[style*="#575279" i] { color: #e0def4 !important; }
/* muted / secondary ink */
body.dark .shiki span[style*="#797593" i],
body.dark .shiki span[style*="#9893A5" i] { color: #908a92 !important; }
/* pine (strings) */
body.dark .shiki span[style*="#286983" i] { color: #9bced7 !important; }
/* iris */
body.dark .shiki span[style*="#56949F" i] { color: #7fd0c4 !important; }
/* foam */
body.dark .shiki span[style*="#907AA9" i] { color: #c4a7e7 !important; }
/* rose */
body.dark .shiki span[style*="#D7827E" i] { color: #ebbcba !important; }
/* gold */
body.dark .shiki span[style*="#EA9D34" i] { color: #f6c177 !important; }
/* love */
body.dark .shiki span[style*="#B4637A" i] { color: #eb99b1 !important; }

/* The language chip in the block's own header bar is #625c88 on cream; on the new
   dark base it reads as a smudge, so it gets rose-pine's surface colour instead.
   Its text is #faf4ed, which is already light, and it is not matched by the
   background rule above because that hex is not in the chip's style attribute. */
body.dark .wp-block-kevinbatdorf-code-block-pro [style*="#625c88" i] {
	background-color: #403d52 !important;
}

/* --------------------------------------------------------------------------- 3.
 * The 说说话 timeline cards.
 *
 * Insurance, not a live fix: nothing on gpluo.cn renders .cbp_tmtimeline today.
 * The panel still paints it (its inline CSS sets the card gradient from
 * --shuoshuo_background_color1 #F9D938 and color2 #FCCD00 and hides the pointer),
 * style.css has rules for it, and page-word.php is the template that would print
 * it — but no published page uses that template, widget_shuo is off, and the
 * rendered DOM of /log/, /, /q-and-a/ and the article pages has no such element.
 * An earlier pass of this work read the yellow cards as being on /log/; /log/ is
 * headings, paragraphs, tables and .conversations-code bubbles, and the theme
 * already converts those (body.dark .conversations-code-text is one of its own
 * rules). The site owner chose dark cards for the timeline anyway, so they are
 * dark here in case the page comes back: bright yellow under the theme's
 * #CCCCCC text is about 1.4:1.
 */
body.dark .cbp_tmtimeline > li .cbp_tmlabel,
body.dark .cbp_tmtimeline > li:nth-child(odd) .cbp_tmlabel {
	background: rgba(26, 26, 26, 0.8);
	border: 1.5px solid #7d7d7d30;
	box-shadow: 0 1px 12px 1px rgba(26, 26, 26, 0.72);   /* section 15's shorter tail */
	transition: all 0.8s ease;
}

body.dark .cbp_tmtimeline > li .cbp_tmlabel:hover,
body.dark .cbp_tmtimeline > li:nth-child(odd) .cbp_tmlabel:hover {
	background: rgba(26, 26, 26, 0.9);
	/* was var(--comment_area_matching, #6667ab) — a violet bloom, which section 8's
	 * inventory caught as one of the two dark-mode glows that were not orange. The
	 * variable is also the comment form's focus border, so the shadow is changed
	 * here rather than the variable redefined. */
	box-shadow: 0 1px 30px -2px var(--theme-skin-matching, #b97a57);
}

/* The little pointer on the card is painted with the same yellow variables. The
   theme hides it in dark mode (body.dark li .cbp_tmlabel:after{display:none}), so
   this is only here in case that rule ever stops applying. */
body.dark .cbp_tmtimeline > li .cbp_tmlabel:after,
body.dark .cbp_tmtimeline > li:nth-child(odd) .cbp_tmlabel:after {
	border-right-color: rgba(26, 26, 26, 0.8);
}

/* style.css colours the timeline's centre line under a class the site never sets:
   `body.theme-dark .cbp_tmtimeline::before`. The dark class this theme actually
   adds is body.dark, so the line kept its light-mode paint. */
body.dark .cbp_tmtimeline::before {
	background: rgba(255, 255, 255, 0.08);
}

/* --------------------------------------------------------------------------- 4.
 * The announcement box — also insurance.
 *
 * index.php:24 prints it on the blog index only, and only when the 公告 option
 * has text; the live front page has no .notice element, so that option is empty
 * today. If it is ever filled in, the panel gives the box a light sakura texture
 * (announcement_bg.webp), a #E6E6E6 border and #969696 ink, and the theme's
 * entire dark treatment is `filter: brightness(90%)`, which leaves a pale box in
 * a dark page.
 */
body.dark .notice {
	background-image: none;
	background-color: rgba(26, 26, 26, 0.8);
	border-color: #7d7d7d30;
	color: #999999;
	box-shadow: 0 1px 12px 1px rgba(26, 26, 26, 0.72);   /* section 15's shorter tail */
}

body.dark .notice,
body.dark .notice i,
body.dark .notice p {
	color: #999999;
}

/* ------------------------------------------------------------------------- 5.
 * Screenshots in the post body.
 *
 * The theme dims images in dark mode through the theme_darkmode_img_bright knob,
 * which is set to 0.8 — fine for a photograph, useless for a white-background
 * software screenshot, which is what most of this site's images are. Measured: a
 * screenshot at L=0.78 sitting in a page whose text sits on #2b2b2b.
 *
 * Scoped to the post body so it does not touch the cover art, the avatars or the
 * omikuji strips, which are the product of /jinjya/ and stay bright on purpose
 * (the strips are re-brightened below, after this rule, so the order matters).
 */
body.dark .entry-content img {
	filter: brightness(0.62) contrast(1.03);
}

body.dark .gpluo-omik img {
	filter: brightness(0.92);
}

/* The section divider is three dots painted by hr:before with
   `color: rgba(0,0,0,.8)` (css/theme/sakura.css, the entry-content style the
   panel selects). On a dark page that is a black mark on a black card: not a
   clash, just gone. */
body.dark .entry-content hr:before {
	color: rgba(255, 255, 255, 0.45);
}

/* --------------------------------------------------------------------------- 6.
 * The banner over a single post or a page — the last bright island on the page.
 *
 * The front-page cover is a <figure id="centerbg">, and the theme dims that one
 * by itself: `body.dark .centerbg{background-blend-mode:hard-light;
 * background-color:#333333}`. It works — the cover band of the dark front-page
 * screenshot averages #2E2D2D (L=0.18).
 *
 * A post's or a page's banner is a different element: .pattern-attachment, a
 * 400px div (280px on mobile) whose photo arrives as a background-image through
 * lazyload. style.css has no body.dark rule for it at all, only geometry. The
 * same band on the article page measured #773939 (L=0.27) with a strong red cast
 * against a page body at L=0.18, so the top half of the page still read as the
 * light theme. Same root cause as section 0: the theme's dark dimming reaches
 * <img>, <iframe>, .highlight-wrap and aplayer, and a background-image is none
 * of those.
 *
 * The declaration is the theme's own, copied rather than invented, so both covers
 * darken the same way. The title is not dimmed with the photo because it is a
 * sibling in .pattern-header, and the theme already sets
 * `body.dark .pattern-center h1.entry-title{color:#FFFFFF}`.
 *
 * CORRECTION, 2026-10-19 evening: the sentence above about the front cover is
 * wrong, and the correction matters because it changes what to do here. The front
 * cover is NOT dimmed by the theme's `body.dark .centerbg` rule: the panel writes
 * `#centerbg{background:#0000}` into <head>, an ID selector (1,0,0) that beats
 * `body.dark .centerbg` (0,1,1), so that figure stays transparent in both modes
 * and the photograph — which with site_bg_as_cover on lives on <body>, not on
 * .centerbg at all, `p = _iro.site_bg_as_cover ? e => { document.body.style
 * .backgroundImage = ... }` — shows straight through it. Measured in the probe:
 * #centerbg computed background rgba(0,0,0,0), background-image none, and the
 * whole cover is just the wallpaper under section 0's multiply.
 *
 * So the front cover's brightness is section 0's canvas, and this rule is the only
 * thing standing between the visitor and an undimmed banner on posts and pages.
 * It now uses the same blend and the same grey as section 0 rather than the
 * theme's hard-light, so the two covers are the same picture at the same level —
 * hard-light and multiply darken differently (hard-light crushes the shadows to
 * 2*source*backdrop and leaves the highlights nearly alone), and that difference
 * was itself one of the mismatches the owner reported.
 *
 * SECOND THOUGHT, same evening: the owner accepted these banners at this level and
 * complained only about the front page, so section 11 lifts the front cover and
 * this rule stays where it is. The two are no longer the same recipe, and that is
 * deliberate rather than an oversight — a banner is a 400px strip inside the
 * content column, where a bright photograph is a design element, while the cover
 * is the whole top of the page behind the navigation. If they ever start to look
 * mismatched, the knob is the colour below; nothing else has to move.
 */
body.dark .pattern-attachment {
	background-blend-mode: multiply;
	background-color: #2e2e2e;
}

/* ------------------------------------------------------------------------- 7.
 * Before the first paint: the surfaces that have to be right immediately.
 *
 * Section 0 keys the canvas off both body.dark and html.gpluo-dark-early for
 * exactly this reason, and these are the rest of the above-the-fold surfaces that
 * need the same treatment. The theme's own dark decision is in js/app.js, printed
 * with defer, so it lands after the first paint; until then every `body.dark`
 * rule on the site — the theme's 129 of them, the panel's block, and this file —
 * is inert, and the page shows the light theme. That is the flash the owner
 * reported: "进入新页面的时候，会整体闪一下原始背景再进入黑色".
 *
 * Measured at </body> with dark decided and app.js not yet run (geom_probe.py
 * reports that instant as asParsed; dark_items_probe.py used to): <html> and <body>
 * transparent, .site-header rgba(255,255,255,.8) — the light pill — and the first
 * post card still carrying the light gradient. The header bar and the first card are
 * both on screen at that moment, so both are duplicated here under the early class.
 *
 * That first pass missed the flash, and the owner came back with "暗黑模式进新页面闪
 * 白的问题还是存在". The miss is that the three surfaces above are all small controls
 * sitting on top of one big one: #page.wrapper. style.css gives it
 * rgba(255,255,255,.85) with filter:blur(10px) in the light theme and
 * style.css:10007 flips it to rgba(51,51,51,.9) under body.dark, so for the frame
 * between the first paint and app.js an 85%-white panel covers everything from the
 * header to the footer — 1440x2991 on an article page, 1440x4010 on the front page,
 * measured. Nothing else in the frame is bright enough to matter next to it. The
 * footer gets the same treatment: it is on screen as soon as the visitor scrolls,
 * and pre-app.js it is transparent over that white sheet.
 *
 * Still deliberately not duplicated: .post-list-thumb's opacity-0 entrance, the
 * hover menu, the mobile nav dropdown — nothing paints them before app.js, and every
 * extra selector is one more that can drift from its body.dark twin.
 *
 * The early class is added by gpluo-dark.php from the same options app.js reads, so
 * the two agree; if they ever disagree, app.js wins, because it runs later and
 * removes body.dark. It also hands the class back — gpluo-dark.php drops it at
 * DOMContentLoaded, which is after the deferred app.js has already decided, and
 * before the next paint. Keeping it for the whole visit is what made the panel's sun
 * button leave parts of the page dark ("从暗黑模式切回原始模式时，部分元素没有变色"):
 * the sun removes body.dark, and every rule below would otherwise keep painting.
 */
html.gpluo-dark-early .site-header,
html.gpluo-dark-early .site-header.yya {
	background-color: rgba(26, 26, 26, 0.72);
	border-color: #7d7d7d30;
	box-shadow: 0 1px 12px 1px rgba(26, 26, 26, 0.72);   /* section 15's shorter tail */
}

/* The cards. The panel's dark value is rgba(51,51,51, var
   (--theme-dm-background_transparency)), and the variable is on <body> from the
   first paint, so this follows the owner's setting instead of hard-coding 0.9. */
html.gpluo-dark-early .post-list-thumb {
	background: rgba(51, 51, 51, var(--theme-dm-background_transparency, 0.9));
	box-shadow: 0 1px 22px -8px rgba(26, 26, 26, 0.55);   /* section 15's shorter tail */
}

/* The two floaters in the bottom-right corner, visible from the first frame. */
html.gpluo-dark-early #changskin,
html.gpluo-dark-early #moblieGoTop {
	background-color: rgba(26, 26, 26, 0.6);
	border: 1px solid #7d7d7d30;
}

/* The overscroll area: with the canvas only on <body>, a rubber-band scroll
   reveals <html>, which is transparent until app.js writes #333 on it. */
html.gpluo-dark-early {
	background-color: #2e2e2e;
}

/* The sheet the flash actually is: 85% white over everything from the header to the
   footer, for the frame before app.js turns it dark. !important because
   style.css:10007's own dark value for .wrapper is !important, and importance beats
   specificity — the two values are the same colour, so the tie is harmless, but
   without it the theme's rule would win on every page where body.dark is also on. */
html.gpluo-dark-early #page.wrapper {
	background: rgba(51, 51, 51, var(--theme-dm-background_transparency, 0.9)) !important;
}

/* The footer is on screen as soon as the visitor scrolls, and pre-app.js it paints
   nothing but pic_backup/footerPicTrans.png over that white sheet. Written as the
   shorthand, not background-color, to match style.css:10007, which drops the image
   in dark mode. */
html.gpluo-dark-early .site-footer {
	background: rgba(51, 51, 51, var(--theme-dm-background_transparency, 0.9)) !important;
}

/* ------------------------------------------------------------------------- 8.
 * One accent, not two: every hover glow orange.
 *
 * The site has two accent colours in dark mode and both are the theme's own. The
 * post cards' bloom uses --post_list_matching_color, which the panel fills with
 * #b97a57 — the site's orange, the same one the menu text, the buttons, the date
 * chips and the share icons use. Everything else uses --theme-skin-dark, which the
 * panel fills with #ff8484 — a pink from the theme author's default palette.
 * `body.dark .post-list-thumb:hover{box-shadow:0 1px 20px 0 var
 * (--post_list_matching_color)}` against `body.dark #changskin:hover,
 * body.dark .searchbox:hover, body.dark .entry-title a:hover, body.dark
 * .site-top ul li a:hover …{… var(--theme-skin-dark)}`: 33 rules in style.css,
 * covering the header bar, the floaters, the search icon, the hamburger, the
 * archive, the aplayer, the language menu, the cover's bottom curve and the
 * loading bar.
 *
 * Light mode gets away with it because the two never appear together — an
 * .entry-content link is --theme-skin-matching (orange) and only its :hover goes
 * pink. Dark mode puts the pink on screen next to the orange bloom and the
 * mismatch shows.
 *
 * Redefining the variable on body.dark moves all 33 at once, which is why this is
 * one declaration and not thirty-three: it follows --theme-skin-matching, so if the
 * owner ever changes the skin the accent follows rather than drifting back to the
 * author's pink. Light mode is untouched — the redefinition is scoped to
 * body.dark — and section 1's own hover glow, which was written as
 * var(--theme-skin-dark, #ff8484), turns orange with it.
 */
body.dark,
html.gpluo-dark-early body {
	--theme-skin-dark: var(--theme-skin-matching, #b97a57);
}

/* Two dark-mode hover glows do not go through that variable, and their variables
 * cannot simply be redefined because they also paint non-hover things
 * (--friend-link-title is the friend-link title's ink, --comment_area_matching the
 * comment form's focus border), so these two shadows are overridden where they are
 * written. Inventory of every :hover box-shadow in style.css, by variable:
 * --theme-skin-dark 19 (all follow the redefinition above), --theme-skin-matching
 * 4 and --post_list_matching_color 4 (already orange), --post-list-thumb 2,
 * --friend-link-shadow 1, --comment_area_shadow 3 (all #e8e8e8, and those rules are
 * light-mode-only — the dark variants below are the exceptions), --comment_area_
 * matching 1 and --friend-link-title 1 (the two below). Nothing else glows.
 *
 * Same specificity as the theme's own rules and both !important, so which one wins
 * is settled by print order — gpluo-dark.php enqueues this file at 99, after the
 * theme's style.css, so these do.
 */
body.dark .links ul li:hover {
	box-shadow: 0 1px 30px -2px var(--theme-skin-matching, #b97a57) !important;
}

body.dark .comment-respond:hover,
body.dark .comment .main:hover {
	box-shadow: 0 1px 10px -2px var(--theme-skin-matching, #b97a57) !important;
}

/* ------------------------------------------------------------------------- 9.
 * The click burst, which is the brightest thing on a dark page.
 *
 * Not the theme's: the owner pasted this script into the 页脚添加 theme option, so
 * it lives in iro_options and in no file (footer.php's `echo iro_opt
 * ('footer_addition')` prints it just before </body>). clickEffect() appends a
 * fixed full-viewport <canvas> at z-index 99999 and, on mousedown, throws 10-20
 * balls of light from the cursor — long-press throws up to a hundred more.
 *
 * The colours are hard-coded in the JS: #FDB9C8, #FDD7E4, #FFBE98, #FFFACD,
 * #FF8484. Four of the five are pastel and #FFFACD (lemon chiffon) is 255,250,205
 * — nearly white. On the light theme that reads as confetti; on a page whose body
 * sits at L=0.18 it is a flare, which is the "太亮了，有点晃眼睛".
 *
 * The colours cannot be changed from CSS because they are painted into a canvas,
 * but the canvas element itself can be dimmed, and it is identifiable without
 * touching the JS: the script writes its style with setAttribute, so the style
 * attribute is in the DOM and `z-index: 99999` is in it. brightness() rather than
 * opacity() because the balls overlap inside the canvas — opacity would fade the
 * layer as one and let the overlaps show through each other, brightness darkens
 * each ball where it was drawn.
 *
 * The early-class variant is not paranoia: the script runs as an inline at
 * </body>, so the canvas exists before app.js does, and a visitor who clicks
 * during the flash gets the burst in the light theme's colours.
 */
body.dark > canvas[style*="z-index: 99999"],
html.gpluo-dark-early body > canvas[style*="z-index: 99999"] {
	filter: brightness(0.55) saturate(0.8);
}

/* -------------------------------------------------------------------------- 10.
 * The share row at the end of the post body — the last thing still wearing the
 * light theme.
 *
 * It is Simple Share Buttons Adder, printed inside .entry-content at the_content.
 * The owner's own option CSS (in iro_options, printed as the ssba-inline-css
 * block) already did the colour work: the buttons are `background-color:
 * #ffffff00 !important` — transparent — and the icons are filled #B97A57, the
 * site's orange. Nothing in the plugin or the theme paints a background anywhere
 * in the subtree; measured with dark_items_probe.py, every node from ul.ssbp-list
 * down to the four <a>s computes to rgba(0,0,0,0).
 *
 * What makes it look like a floating glass pill is the shadow. style.css gives the
 * row the site's light-theme card recipe — `border-radius:30px` with
 * `box-shadow:1px 1px 5px rgba(0,0,0,.3)` — and a black blur drawn around a
 * transparent box on a dark page reads as a raised panel: the interior looks
 * lighter than the page around it even though nothing paints it. That recipe is
 * correct on a white theme and wrong on a dark one, which is why this row is the
 * one component the owner called out as still glassy.
 *
 * So it gets the dark recipe the header bar, the floaters and the skin menu use:
 * rgba(26,26,26,.72) with a #7d7d7d30 hairline and a 20px dark bloom, radius left
 * alone at the site's 30px. The icons keep the owner's orange, which section 8 has
 * just made the single accent everywhere else.
 */
body.dark .ssbp-list {
	background: rgba(26, 26, 26, 0.72);
	border: 1px solid #7d7d7d30;
	box-shadow: 0 1px 12px 1px rgba(26, 26, 26, 0.72);   /* section 15's shorter tail */
}

body.dark .ssbp-list li a:hover {
	background-color: rgba(26, 26, 26, 0.86);
}

/* ------------------------------------------------------------------------- 11.
 * The front-page cover: too dark, and wearing a grid (owner, 2026-10-19).
 *
 * cover_layers.py walks every element and pseudo-element whose box overlaps the
 * cover band and prints the ones that paint, in dark mode, with the wallpaper
 * pinned. Three things stand between the visitor and the photograph — and since
 * the photograph is on <body>, all three paint over it:
 *
 *   1. section 0's multiply canvas (#2e2e2e): the picture at 18% of itself.
 *   2. section#main-container, which style.css:10007 gives
 *      `rgba(51,51,51, var(--theme-dm-background_transparency)) !important` in
 *      dark mode — 0.9 on this site. In light mode the element paints nothing at
 *      all, so this lid only exists in dark mode.
 *   3. .headertop.filter-grid::before, which tiles
 *      s.nmxc.ltd/sakurairo_vision/@2.6/basic/grid.png over the cover because the
 *      cover-filter theme option is set to 网格. That is the "栅格".
 *
 * The arithmetic the first experiment produced, and the reason it looked
 * backwards — lowering the board's opacity made the cover DARKER (0.19 → 0.13):
 *
 *     observed = board_alpha * 51 + (1 - board_alpha) * photo * canvas / 255
 *
 * With the photo at 18% the board is not a lid on a visible picture, it IS the
 * colour the visitor sees: 0.9*51 + 0.1*21 = 48, measured #2D2D2D. So neither
 * knob helps alone. The picture has to be lifted (section 0's #8c8c8c) AND the
 * board has to step aside across the cover (the ramp below). Measured on the same
 * pinned photograph: cover band L=0.18 → 0.21, and the band average goes from a
 * neutral #2D2D2D to #3E333A — the sunset's own colour is back, which is what
 * "reads as a photograph" means. The page band below the cover is unchanged
 * (#343131 either way), because the ramp is finished by then.
 *
 * The ramp is scoped to body.dark.home (the front page: `home blog` in the body
 * class list) and anchored to the top of #main-container, which is where the cover
 * is. Everything below it — the cards, the article banners, the footer — keeps the
 * theme's own board colour, which the owner already accepted this round. The
 * article 头图 needs no help from here: .pattern-attachment is a *descendant* of
 * #main-container, so it paints on top of the board instead of under it, which is
 * why only the front page was ever reported as too dark.
 *
 * The grid rule carries an html.gpluo-dark-early variant because the texture is in
 * the markup from the first byte, so a visitor whose first frame is already dark
 * would otherwise see it for the moment before body.dark lands. The ramp needs no
 * such variant: the board it modifies is a dark-theme surface that does not exist
 * before app.js runs, and the first frame is section 7's dark canvas anyway.
 */
body.dark .headertop.filter-grid::before,
html.gpluo-dark-early body .headertop.filter-grid::before {
	background-image: none;
}

/* The cover is not 550px tall in practice. style.css:2553 says 550px and
 * style.css:8344 says 300px under 860px, but js/app.js resizes #centerbg to the
 * viewport before a visitor can react: measured with geom_probe.py, the cover is
 * 757px in a 757px-tall viewport, 1297px in a 1297px-tall one, and 757px at 500px
 * wide — 100vh at every width. The 550px figure is only what the page looks like for
 * the moment before app.js runs, which is what made the first version of this ramp
 * wrong: it finished at 640px while the cover went on for another 117-657px.
 *
 * Where the seam is, and what the eye does there. #page.wrapper — the panel that
 * carries the GUIDE row, the cards and everything below — begins at the cover's
 * bottom edge: geom_probe.py reports the cover at 100vh and the wrapper's box top
 * at the same row (1297 in a 1297px-tall harness). The wrapper paints
 * rgba(51,51,51,.9) of its own (style.css:10007), so below the seam the photograph
 * contributes 0.9*0.9 = 1% of its light and above it 10%. That step lands exactly
 * where the GUIDE feature row starts: h1.fes-title sits at 100vh-25px, straddling
 * the seam. That is the "最下面和guide栏的过渡部分存在灰度不连续" the owner
 * reported. The light theme hides the same seam with #banner_wave_1 and
 * #banner_wave_2, two PNG waves at 0.85 and 1.0 opacity laid across the edge; a
 * wave in dark mode would read as a lit outline, so this is the same idea done as
 * a gradient.
 *
 * How bright the bottom row of the wallpaper is: seam_rows.py measures all 15
 * images in the pool under cover + center + fixed. Every one of them is wider than
 * 1.6, so cover height-fits them and the seam row IS the photo's last row — there
 * is no cropped margin to hide behind. L there runs from 0.54 (7.jpg) down to
 * 0.02 (10.jpg), which is why the owner sees the line only sometimes: on a dark
 * wallpaper the seam is invisible, on a bright one it is a line.
 *
 * The version deployed 2026-10-19 closed the board at alpha 1 twelve px above the
 * seam, on the theory that a composite of 51 on both sides of the line is smooth.
 * It is not, and seam_profile.py says why — the metric is levels per pixel, since
 * the same total spread over 200px is invisible and across 2px is a line. Pinned
 * to the brightest wallpaper (7.jpg), production geometry lifted into the frame
 * with SEAM_OFF=300, sampled in the page margin where nothing but background
 * paints:
 *
 *   board as shipped, no ramp:     0.50 levels/px at the seam  (47 -> 50)
 *   ramp ending at 100vh-12px:     2.64 levels/px at the seam  (38 -> 45 in 2px, 49 after)
 *   this rule:                     1.22 levels/px, mid-cover, not at the seam
 *
 * Ending at alpha 1 above the seam keeps the photograph at ~14% right up to the
 * edge and then cuts it off in one row, because the wrapper's own 0.9 board takes
 * over there: the ramp moved the step, it did not spread it. The fix is to let the
 * board hold the photograph *through* the seam and close below it, so the picture
 * carries on past the cover's bottom edge and dissolves into the panel over 240px.
 * That needs the wrapper's own board to fade in too, or the two 0.9 layers still
 * meet at the same row — hence the second rule, which starts #page.wrapper
 * transparent at its own box top (which is the seam) and reaches the theme's 0.9
 * 220px later. The alphas then add smoothly: 14% of the photograph at the seam,
 * 5% at +60px, 1% at +160px, none at +240px, and the steepest slope left anywhere
 * on the page is 1.22 levels/px in the middle of the cover, where nothing is
 * straight enough to read as a line. c_live.png / c_fade.png are the two states.
 *
 * Why the wrapper rule is anchored in px and the ramp in vh: the wrapper's box top
 * is the seam by construction, whatever app.js does to the cover's height, so 0 is
 * always the line. The ramp is measured against 100vh because the element it
 * paints on spans the whole document. On a phone the two disagree — js/app.js
 * sizes the cover from window.innerHeight, which is smaller than 100vh while the
 * address bar is showing — and the disagreement goes the safe way: the seam lands
 * above 100vh, so the board is still holding the photograph at 0.86 there and the
 * closing happens later and slower. The old "end 12px short of 100vh" trick was
 * tuned for the opposite direction, the one that never happens.
 *
 * The wrapper selector is doubled up as `#page.wrapper.wrapper` to out-specify
 * style.css:10007's `body.dark .wrapper{...!important}`, and both rules are scoped
 * to body.dark.home so that every other page keeps the theme's flat board: only
 * the front page has a cover ending underneath it.
 *
 * The banding fix (owner, 2026-10-20, item 6). This ramp is a 5-level climb spread
 * over ~700px — 0.06 levels per pixel, so every grey level owns a 17px-wide
 * stripe. On any pipeline that outputs 8 bits a ramp like that reads as bands
 * rather than as a gradient, and shortening it only makes the bands narrower. What
 * actually fixes it is breaking the flat runs, which is what the feTurbulence tile
 * below does: a 180px seamless noise tile (stitchTiles) at 5% over the ramp gives
 * the eye ±1-2 levels of jitter inside each stripe, so the stripe stops being an
 * edge. Sampling a column in the page margin (dither_test2.png, px.swift):
 *
 *   ramp alone:       7 distinct levels, runs of 30 samples identical, mean 46.1
 *   ramp + this tile: 8 distinct levels, no run longer than 3, mean 49.9
 *
 * The tile is not zero-mean — a 5% mid-grey overlay lifts a #333 base by about 4
 * levels — so every colour stop here is written 4 lower than the value the owner
 * accepted (46 → 42, 51 → 47) and the composite lands back where it was. The
 * spread is unchanged, so the 1.22 levels/px figure recorded in section 21 still
 * holds. The tile repeats down the whole element, including the flat board below
 * the seam; there it costs nothing (a flat colour cannot band) and the cards sit
 * over it either way.
 *
 * Every longhand carries `!important` on its own. style.css:10007 sets these same
 * properties through a `background` shorthand that is itself `!important`, and a
 * shorthand expands to exactly the longhands it names — so all four have to be
 * marked important separately, not just the gradient.
 */
body.dark.home #main-container {
	background-image:
		url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='180' height='180'%3E%3Cfilter id='g'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='0.85' numOctaves='3' stitchTiles='stitch'/%3E%3CfeColorMatrix type='saturate' values='0'/%3E%3C/filter%3E%3Crect width='180' height='180' filter='url(%23g)' opacity='.05'/%3E%3C/svg%3E"),
		linear-gradient(to bottom,
			rgba(42, 42, 42, 0.20) 0,
			rgba(42, 42, 42, 0.20) calc(100vh - 380px),
			rgba(42, 42, 42, 0.34) calc(100vh - 300px),
			rgba(42, 42, 42, 0.52) calc(100vh - 220px),
			rgba(42, 42, 42, 0.70) calc(100vh - 140px),
			rgba(42, 42, 42, 0.86) calc(100vh - 40px),
			rgba(47, 47, 47, 0.93) calc(100vh + 60px),
			rgba(47, 47, 47, 0.97) calc(100vh + 160px),
			rgb(47, 47, 47) calc(100vh + 240px)) !important;
	background-size: 180px 180px, 100% 100% !important;
	background-repeat: repeat, no-repeat !important;
	background-position: 0 0, 0 0 !important;
}

body.dark.home #page.wrapper.wrapper {
	background: linear-gradient(to bottom,
			rgba(51, 51, 51, 0) 0,
			rgba(51, 51, 51, 0.30) 60px,
			rgba(51, 51, 51, 0.62) 130px,
			rgba(51, 51, 51, 0.9) 220px)
		!important;
}

/* ------------------------------------------------------------------------- 12.
 * The lazyload placeholder is orange on every image that has not arrived yet
 * (owner, 2026-10-20: "用于过渡的图背景颜色是橙色的，这个和其余黑色背景部分的色差
 * 比较大…你看看能不能重做一个适用于暗黑模式的过渡图像（包括文章卡片的过渡图也是这样）").
 *
 * The placeholder is a file on the theme author's CDN:
 * s.nmxc.ltd/sakurairo_vision/@2.6/load_svg/outload.svg — an 80x80 SVG whose own
 * style attribute says `background: #FEE2D5` (cream), filled with a pattern of
 * #FE8C5B/#FEE2D5 stripes rotated 20° and animated sideways, plus a rounded
 * loading bar stroked #FE8C5B. It is used two ways and both need a dark twin:
 *
 *   1. The article 头图: `<div class="pattern-attachment bg lazyload"
 *      style="background-image: url(…outload.svg)" data-src="…jpg">`. The
 *      placeholder is an inline background, so it is on screen from the first byte
 *      and stays until lazysizes rewrites that style for the real picture. Read
 *      off the live pages: /article/function/ and /?p=2554 both carry it, and
 *      nothing else on the site uses pattern-attachment this way.
 *   2. The front-page cards: `<img class="lazyload" src="…outload.svg
 *      #lazyload-blur" data-src="…webp">` — nine of them. The #lazyload-blur
 *      fragment is what triggers style.css:7868's `filter:saturate(.5)
 *      blur(10px)`, so a card shows a blurred orange block before its thumbnail
 *      arrives.
 *
 * For the background case the answer is a second asset, gpluo-load-dark.svg: the
 * same file with the cream moved to #2e2e2e, the stripes to #3a3a3a/#2e2e2e and
 * the loading bar to #454545. The url is relative so it resolves against
 * /wp-content/mu-plugins/, where this stylesheet lives. `[style*="outload"]` is
 * what makes the rule self-resolving — it matches only while the inline style
 * still names the placeholder, and lazysizes rewrites that style when the picture
 * loads, so the rule retires itself: no script, no class, and no chance of
 * painting over a loaded image. !important because the value it replaces is an
 * inline style.
 *
 * For the <img> case there is no second asset to point at — content:url() swaps an
 * image in Chrome and Safari but not in Firefox — so the placeholder is
 * recoloured with a filter instead, and the theme's blur is re-declared in the
 * same chain because filter is one property and this replaces style.css:7868's.
 * The recipe was chosen by measurement, not by eye: the real placeholder on a #333
 * page, read back with px.swift (ph_test.png, ph_test2.png).
 *
 *   no filter:                          #FDE1D4  L=0.90   the orange reported
 *   invert + brightness(.52):           #110C09  L=0.05   darker than the page
 *   invert + grayscale + brightness1.9: #2F2F2F  L=0.18   chosen
 *   the dark asset:                     #2F2F2F  L=0.18   (the board is #333, L=0.20)
 *
 * so both placeholder paths land on the same grey as each other, four levels under
 * the surface they sit on — visible as a shape, invisible as a colour.
 *
 * The same CDN serves ball.svg, the red-and-cream spinning disk behind "load the
 * next page" (#pagination .loading, #bangumi-pagination .loading) and behind the
 * comment-submit spinner (#loading-comments). A saturated red disk on a dark board
 * is the same class of clash, and invert+grayscale puts the disk at L≈0.63 and the
 * notch at L≈0.11, which reads as a spinner rather than as a signal. The owner did
 * not report it; it is the same three lines of CSS, so it comes along.
 */
body.dark .pattern-attachment[style*="outload"] {
	background-image: url("gpluo-load-dark.svg") !important;
}

body.dark img.lazyload[src*="outload"] {
	filter: invert(1) grayscale(1) brightness(1.9) blur(10px);
}

body.dark #pagination .loading,
body.dark #bangumi-pagination .loading,
body.dark #loading-comments {
	filter: invert(1) grayscale(1);
}

/* ------------------------------------------------------------------------- 13.
 * The page-turn at the bottom-right of a card thumbnail stays white in dark mode
 * (owner, item 2: "鼠标hover文章卡片的图，右下角有一个书页翻起的动效还是白色的").
 *
 * The divs are created by the owner's own footer script (initCategoryIcons, which
 * also makes the .category-icon and watches for AJAX-loaded cards); the styling is
 * the theme's: `.page-flip{background:#fff}` and `.page-flip::before{background:
 * linear-gradient(135deg,transparent 50%,rgba(230,230,230,.9) 51%)}`. The near
 * half of the diagonal is the page and the far half is its crease, which is what
 * makes the light version read as paper lifting off the corner. Neither has a dark
 * variant, so on a #333 card the flipped corner is a white flag.
 *
 * The dark twin keeps the geometry and swaps the two surfaces: the page becomes
 * #4d4d4d, a little lighter than the card so the corner catches light, and the
 * crease becomes rgba(26,26,26,.9), which composites to about #1f1f1f over it —
 * darker than the page, which is what a fold looks like. body.dark .page-flip is
 * (0,2,1) against the theme's (0,1,0) and the ::before variant (0,2,2) against
 * (0,1,1), so neither rule needs !important.
 */
body.dark .page-flip {
	background: #4d4d4d;
}

body.dark .page-flip::before {
	background: linear-gradient(135deg, transparent 50%, rgba(26, 26, 26, 0.9) 51%);
}

/* ------------------------------------------------------------------------- 14.
 * The password gate is a white box in the middle of a dark page (owner, item 4:
 * "暗黑模式下，密码保护文章的输入密码框也是白色的").
 *
 * The markup is core's: .post-password-form with a paragraph, a label around an
 * input[type=password] and an input[type=submit]. The theme only centres the form
 * — it never gives the fields a background. style.css does have
 * `body.dark input[type=…]:focus{color:#CCCCCC;background-color:#333333}`, but
 * that is the focused state: an untouched field keeps the browser's white with
 * black text, and Chrome paints its autofill swatch over whatever CSS says
 * anyway. Section 21's share-row bug lives in this same page, so the two fixes
 * have to be verified together.
 *
 * Both fields get the site's own dark control recipe — the one
 * `body.dark .search-form input` and the skin-menu buttons already use:
 * rgba(26,26,26,.8), a #7d7d7d30 hairline, the site's 30px radius. The submit
 * follows #pagination a, the site's button: transparent fill, 30px radius, the
 * accent from --theme-skin-matching, and the dark bloom at section 15's reach.
 *
 * -webkit-autofill needs its own rule because the swatch is not a background:
 * Chrome draws it into the field, so the only way to cover it is an inset shadow
 * in the colour actually wanted, sized to overflow the field, plus a transition
 * long enough that the yellow never gets a frame to fade in.
 */
body.dark .post-password-form input[type="password"] {
	background-color: rgba(26, 26, 26, 0.8);
	color: #cccccc;
	border: 1px solid #7d7d7d30;
	border-radius: 30px;
	padding: 8px 18px;
	transition: all 0.8s ease;
}

body.dark .post-password-form input[type="password"]:focus {
	background-color: #333333;
	color: #cccccc;
}

body.dark .post-password-form input:-webkit-autofill,
body.dark .post-password-form input:-webkit-autofill:hover,
body.dark .post-password-form input:-webkit-autofill:focus {
	-webkit-text-fill-color: #cccccc;
	-webkit-box-shadow: 0 0 0 100px #1a1a1a inset;
	caret-color: #cccccc;
	transition: background-color 9999s ease-in-out 0s;
}

body.dark .post-password-form input[type="submit"] {
	background-color: rgba(255, 255, 255, 0);
	border: 1px solid #7d7d7d30;
	border-radius: 30px;
	padding: 8px 24px;
	color: var(--theme-skin-matching, #b97a57);
	box-shadow: 0 1px 12px 1px rgba(26, 26, 26, 0.72);
	transition: all 0.8s ease;
}

body.dark .post-password-form input[type="submit"]:hover {
	background-color: rgba(26, 26, 26, 0.86);
}

/* ------------------------------------------------------------------------- 15.
 * Long grey shadows band on a dark page (owner, item 6: "部分元素在暗黑模式下，
 * 边缘会有比较长的深灰至浅灰的渐变，这种渐变在我的10bit色深屏幕上都会出现色彩断层，
 * 那么一般的屏幕就更严重了…比如大幅缩短过渡").
 *
 * Two different gradients, and they need different fixes. The page-wide ramp under
 * the front-page cover is section 11's business: five levels over 700px is 0.06
 * levels per pixel, so every grey level owns a 17px stripe and it bands by
 * construction — shortening it would only make the stripes narrower, which is why
 * that one is dithered instead. What is left here is the shadows, and for a shadow
 * reach is the only lever.
 *
 * style.css gives 31 selectors the same `0 1px 20px 2px rgba(26,26,26,.8)`, the
 * cards `0 1px 35px -8px rgba(26,26,26,.6)`, and eight hover states
 * `0 1px 30px -2px rgba(26,26,26,.95)`. A gaussian blur's tail is exactly where
 * levels-per-pixel falls to a fraction: the last few levels of a 20px blur are
 * spread over the last few pixels of reach, and that faint long tail around an
 * element edge is the gradient being described. So blur and spread come down
 * together and the alpha comes down slightly with them:
 *
 *   0 1px 20px 2px  rgba(26,26,26,.8)    reach 12px  →  0 1px 12px 1px  rgba(26,26,26,.72)   reach 7px
 *   0 1px 35px -8px rgba(26,26,26,.6)    reach 9.5px →  0 1px 22px -8px rgba(26,26,26,.55)   reach 3px
 *   0 1px 30px -2px rgba(26,26,26,.95)   reach 13px  →  0 1px 16px -2px rgba(26,26,26,.9)    reach 6px
 *
 * The coloured hover glows stay at 30px on purpose: they are saturated (section 8
 * made them all --theme-skin-matching), a coloured bloom reads as a bloom whatever
 * its radius, and the owner accepted that look this round. If they band too, the
 * same halving applies to them.
 *
 * Nothing in this section carries !important, deliberately. The theme's values are
 * not important either, so these win on print order alone (gpluo-dark.php enqueues
 * at 99, after the theme's style.css) — and marking them important would make the
 * static shadow outrank the theme's :hover shadows, which are not important, so
 * the cards' orange bloom would stop appearing on hover.
 */
body.dark #moblieGoTop,
body.dark #changskin,
body.dark #pagination a,
body.dark .ai-excerpt,
body.dark .author-profile .desc,
body.dark .author-profile .info,
body.dark .author-profile .meta,
body.dark .brick a,
body.dark .comment-respond #cancel-comment-reply-link,
body.dark .comment-respond,
body.dark .comment .main,
body.dark .conversations-code-text,
body.dark .font-family-controls button,
body.dark .menu-list li,
body.dark .links ul li,
body.dark .navigator i,
body.dark .notification,
body.dark .post-lincenses,
body.dark .post-modified-time,
body.dark .post-tags,
body.dark .reward-open,
body.dark .shortcodestyle,
body.dark .showcard,
body.dark .showcard .img,
body.dark .showcard-button,
body.dark .skin-menu .row-container .menu-list,
body.dark .skin-menu .row-container.font-family-controls,
body.dark .footer-shuo,
body.dark .toc,
body.dark .widget-area,
body.dark .xControl {
	box-shadow: 0 1px 12px 1px rgba(26, 26, 26, 0.72);
}

body.dark .post-list-thumb {
	box-shadow: 0 1px 22px -8px rgba(26, 26, 26, 0.55);
}

body.dark .conversations-code-text:hover,
body.dark .showcard .img:hover,
body.dark .showcard-button.hover,
body.dark .showcard:hover,
body.dark .skin-menu .row-container .menu-list:hover,
body.dark .skin-menu .row-container.font-family-controls:hover,
body.dark .footer-shuo:hover,
body.dark .widget-area:hover {
	box-shadow: 0 1px 16px -2px rgba(26, 26, 26, 0.9);
}