/**
 * Content typography — every block type a doc can contain, styled
 * consistently whether it came from the Gutenberg editor (wp-block-*
 * classes) or from a Markdown import (plain h1-h6/p/ul/table/etc, no
 * wrapper classes). Also loaded as an editor style so authoring in
 * wp-admin roughly previews the front-end look.
 */

.hmd-content,
.editor-styles-wrapper .edit-post-visual-editor__post-title-wrapper + .block-editor-block-list__layout {
	font-size: 16px;
	line-height: 1.75;
	color: var(--hmd-text, #1f2328);
	/* Defensive against a fairly common authoring/paste artifact: text
	   copied from some rich-text editors (or certain Markdown->HTML
	   converters) replaces every space with a non-breaking space
	   ( ), especially between inline code spans like `a`, `b`, `c`.
	   A run of  -joined words has NO valid line-break point at
	   all, so without this the whole run stays on one line and
	   overflows past the content column into whatever sits next to it
	   (the right-hand ToC sidebar). overflow-wrap: anywhere lets the
	   browser break even inside an unbroken run as a last resort,
	   so content can never bleed out of its column regardless of
	   whether it was authored with normal spaces or not. */
	overflow-wrap: anywhere;
}

.hmd-content > *:first-child {
	margin-top: 0;
}

/* ------------------------------- Headings ------------------------------- */

.hmd-content h1,
.hmd-content h2,
.hmd-content h3,
.hmd-content h4,
.hmd-content h5,
.hmd-content h6 {
	font-weight: 700;
	line-height: 1.3;
	scroll-margin-top: 90px; /* so anchored jumps clear the sticky header */
	color: var(--hmd-text, #1f2328);
}

.hmd-content h2 {
	font-size: 24px;
	margin: 40px 0 16px;
	padding-top: 8px;
}

.hmd-content h2:first-child {
	padding-top: 0;
}

.hmd-content h3 {
	font-size: 19px;
	margin: 28px 0 12px;
}

.hmd-content h4 {
	font-size: 16px;
	margin: 22px 0 10px;
}

/* ------------------------------- Paragraphs ------------------------------- */

.hmd-content p {
	margin: 0 0 18px;
}

.hmd-content strong {
	font-weight: 700;
}

.hmd-content a {
	text-decoration: underline;
	text-underline-offset: 2px;
}

/* --------------------------------- Lists --------------------------------- */

.hmd-content ul,
.hmd-content ol {
	margin: 0 0 18px;
	padding-left: 24px;
}

.hmd-content li {
	margin-bottom: 6px;
}

.hmd-content li > ul,
.hmd-content li > ol {
	margin-top: 6px;
	margin-bottom: 0;
}

/* Multi-level bullets get progressively lighter markers, matching how
   most style guides visually distinguish nesting depth. */
.hmd-content ul {
	list-style-type: disc;
}
.hmd-content ul ul {
	list-style-type: circle;
}
.hmd-content ul ul ul {
	list-style-type: square;
}

/* -------------------------------- Blockquote -------------------------------- */

.hmd-content blockquote {
	margin: 0 0 18px;
	padding: 4px 20px;
	border-left: 4px solid var(--hmd-accent, #4f46e5);
	background: var(--hmd-accent-soft, #eef1ff);
	border-radius: 0 8px 8px 0;
	color: var(--hmd-text, #1f2328);
}

.hmd-content blockquote p:last-child {
	margin-bottom: 0;
}

/* -------------------------------- Images -------------------------------- */

.hmd-content img {
	border-radius: 8px;
	margin: 8px 0 20px;
	display: block;
}

/* Set on every content image by lightbox-init.js once it's found and
   wired up a click handler for it — a zoom cursor is the standard
   affordance for "this enlarges", so readers don't have to guess. */
.hmd-content img.hmd-lightbox-trigger {
	cursor: zoom-in;
}

/* The wrapper lightbox-init.js inserts directly around each
   enlargeable image, purely so the magnifying-glass badge below has
   something positioned to sit inside. "display: block" matches the
   image's own default (see .hmd-content img above) so the wrapper
   never adds any visible width/height of its own. */
.hmd-content .hmd-lightbox-wrap {
	position: relative;
	display: block;
}

/* Always visible (not just on :hover) — a hover-only badge is
   invisible by definition on touch devices, which have no hover
   state at all, and that's exactly the audience most likely to need
   the extra hint that an image can be tapped to enlarge. */
.hmd-content .hmd-lightbox-wrap__badge {
	position: absolute;
	bottom: 10px;
	right: 10px;
	width: 34px;
	height: 34px;
	border-radius: 50%;
	background: rgba( 0, 0, 0, 0.55 );
	color: #fff;
	display: flex;
	align-items: center;
	justify-content: center;
	opacity: 0.85;
	pointer-events: none;
	transition: opacity 0.15s ease, transform 0.15s ease;
}

.hmd-content .hmd-lightbox-wrap__badge svg {
	width: 18px;
	height: 18px;
}

.hmd-content .hmd-lightbox-wrap:hover .hmd-lightbox-wrap__badge,
.hmd-content .hmd-mermaid:hover .hmd-lightbox-wrap__badge {
	opacity: 1;
	transform: scale( 1.08 );
}

.hmd-content figure {
	margin: 0 0 20px;
}

.hmd-content figcaption {
	font-size: 13px;
	color: var(--hmd-text-muted, #66707a);
	margin-top: 8px;
	text-align: center;
}

/* --------------------------------- Tables --------------------------------- */

/* Wrapped around every <table> at runtime by app.js's
   initResponsiveTables() — found live on a real doc with a 4-column
   reference table: with only `width: 100%` and default table-layout,
   Chrome will shrink a short-content column (e.g. "Line") down well
   below the width even its own HEADER word needs the moment a sibling
   column (e.g. "Rule") has a lot of text, wrapping "Line" mid-word
   into "Li"/"ne". `min-width: max-content` on the table tells the
   browser's own table layout algorithm to never compress any column
   past its natural/unwrapped width; that can legitimately make the
   table wider than its column, which is exactly what this wrapper's
   own horizontal scrollbar is for — the same pattern already used for
   wide code blocks below. */
.hmd-content .hmd-table-scroll {
	overflow-x: auto;
	margin: 0 0 22px;
}

.hmd-content table {
	width: 100%;
	min-width: max-content;
	border-collapse: collapse;
	margin: 0;
	font-size: 14px;
}

.hmd-content th,
.hmd-content td {
	border: 1px solid var(--hmd-border, #e4e4e8);
	padding: 10px 12px;
	text-align: left;
	vertical-align: top;
}

.hmd-content th {
	background: var(--hmd-bg-subtle, #f7f7f9);
	font-weight: 600;
}

.hmd-content tbody tr:nth-child(even) {
	background: var(--hmd-bg-subtle, #f7f7f9);
}

/* ---------------------------------- Code ---------------------------------- */

.hmd-content code {
	font-family: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace;
	background: var(--hmd-code-bg, #f4f4f7);
	padding: 2px 6px;
	border-radius: 4px;
	font-size: 0.9em;
}

/* The extra ".wp-block-code"/pre[class] selectors below exist purely
   for specificity: WordPress auto-enqueues its own wp-block-library
   stylesheet (with hardcoded colors) whenever content has blocks, and
   a plain "pre"/"code" rule alone can lose that cascade fight
   depending on load order. Repeating the class keeps ours winning
   without needing !important. */
.hmd-content pre,
.hmd-content pre.wp-block-code {
	position: relative;
	background: var(--hmd-code-bg, #f4f4f7);
	border: 1px solid var(--hmd-border, #e4e4e8);
	border-radius: 8px;
	padding: 0;
	margin: 0 0 20px;
	color: var(--hmd-text, #1f2328);
}

/* The actual horizontally-scrolling area, injected by app.js's
   initCodeCopyButtons() as a wrapper around the existing <code> — kept
   OUT of pre's own overflow so the Copy button (a normal sibling of
   this div, not a child of it) can stay visually pinned to pre's
   top-right corner. Found live: overflow-x was previously set on pre
   itself, with the button positioned absolute as a DIRECT CHILD of
   that same scrolling box — position:absolute only pins an element to
   its containing block's edges, it does NOT exempt that element from
   being part of the box's own scrolled content, so the button visibly
   scrolled away together with the code the moment a long line was
   scrolled horizontally. Moving the scrolling to this inner wrapper
   means pre itself never scrolls, so the button (now pre's child, not
   this div's) has nothing to scroll away with. */
.hmd-content pre .hmd-code-scroll {
	overflow-x: auto;
	padding: 16px 18px;
}

.hmd-content pre code,
.hmd-content pre.wp-block-code code {
	background: none;
	padding: 0;
	font-size: 14px;
	line-height: 1.6;
	color: inherit;
}

/* "Copy" button injected by app.js into the top-right corner of every
   code block. */
.hmd-code-copy {
	position: absolute;
	top: 8px;
	right: 8px;
	background: var(--hmd-bg, #fff);
	border: 1px solid var(--hmd-border, #e4e4e8);
	color: var(--hmd-text-muted, #66707a);
	font-family: var(--hmd-font-sans, sans-serif);
	font-size: 12px;
	font-weight: 500;
	padding: 4px 10px;
	border-radius: 6px;
	cursor: pointer;
	opacity: 0;
	transition: opacity 0.15s ease, color 0.15s ease, border-color 0.15s ease;
}

.hmd-content pre:hover .hmd-code-copy,
.hmd-code-copy:focus {
	opacity: 1;
}

.hmd-code-copy:hover {
	color: var(--hmd-accent, #4f46e5);
	border-color: var(--hmd-accent, #4f46e5);
}

.hmd-code-copy.is-copied {
	opacity: 1;
	color: #147a3d;
	border-color: #147a3d;
}

/* ------------------------------ Mermaid diagrams ------------------------------ *
 * mermaid-init.js swaps a ```mermaid code block for a <div class="mermaid">
 * that Mermaid.js then fills with an inline SVG. The wrapper below just
 * gives that SVG the same card look as a fenced code block (border,
 * background, rounded corners) and lets a wide diagram scroll
 * horizontally on narrow/mobile screens instead of overflowing.
 */
.hmd-content .hmd-mermaid {
	position: relative;
	background: var(--hmd-code-bg, #f4f4f7);
	border: 1px solid var(--hmd-border, #e4e4e8);
	border-radius: 8px;
	padding: 16px 18px;
	margin: 0 0 20px;
	overflow-x: auto;
	text-align: center;
}

/* lightbox-init.js adds a click-to-enlarge badge to every rendered
   diagram, the same way it already does for content images (see
   .hmd-lightbox-wrap__badge above) — reused as-is here since it's a
   generic descendant selector, not scoped to .hmd-lightbox-wrap
   specifically. cursor:zoom-in on the diagram itself, since (unlike
   an <img>) the whole card is the click target, not just an inner
   element. */
.hmd-content .hmd-mermaid.hmd-lightbox-trigger {
	cursor: zoom-in;
}

/* A diagram that's still rendering (mermaid.run() hasn't resolved yet,
   or the CDN library itself is still loading) — see
   pendingOpenContainer in lightbox-init.js. A click here is still
   remembered and opens the lightbox the instant rendering finishes,
   but "cursor: progress" is the only visible cue in the meantime that
   there's something worth waiting on, rather than looking unclickable. */
.hmd-content .hmd-mermaid.hmd-lightbox-pending {
	cursor: progress;
}

.hmd-content .hmd-mermaid svg {
	max-width: 100%;
}

/* ------------------- WordPress default color palette ------------------- *
 * Content pasted/imported from other WordPress sites (e.g. via the
 * BetterDocs importer) often carries inline classes like
 * "has-black-color has-text-color" or "has-vivid-red-color", which
 * WordPress core resolves against a handful of default CSS custom
 * properties (this theme has no theme.json of its own, so those core
 * defaults are what's in effect). Left alone, "black" text is
 * unreadable on our dark background — redefining just the palette
 * variables here lets all of that legacy content adapt automatically,
 * with no need to touch individual posts or classes. */
[data-hmd-theme="dark"] .hmd-content {
	--wp--preset--color--black: #e7e8ea;
	--wp--preset--color--white: #14151a;
	--wp--preset--color--cyan-bluish-gray: #b8bcc4;
	--wp--preset--color--very-light-gray: #2a2b32;
	--wp--preset--color--very-dark-gray: #e7e8ea;
	--wp--preset--color--pale-pink: #3a2530;
}

/* Belt-and-braces direct overrides in case the installed WordPress
   version prints these as hardcoded hex rather than var() (varies by
   version) — same intent as above, just guaranteed to apply either way. */
[data-hmd-theme="dark"] .hmd-content .has-black-color,
[data-hmd-theme="dark"] .hmd-content .has-very-dark-gray-color {
	color: var(--hmd-text) !important;
}

[data-hmd-theme="dark"] .hmd-content .has-black-background-color,
[data-hmd-theme="dark"] .hmd-content .has-very-dark-gray-background-color {
	background-color: var(--hmd-bg-subtle) !important;
}

.hmd-content .has-white-color {
	color: var(--hmd-text) !important;
}

/* ---------------------------------- Misc ---------------------------------- */

.hmd-content hr {
	border: none;
	border-top: 1px solid var(--hmd-border, #e4e4e8);
	margin: 32px 0;
}

.hmd-content .wp-block-columns {
	display: flex;
	gap: 24px;
	margin-bottom: 18px;
}

.hmd-content .wp-block-column {
	flex: 1;
	min-width: 0;
}

.hmd-content .wp-block-embed {
	margin-bottom: 20px;
}

/* Every <iframe> in a doc — whether it's wrapped in Gutenberg's
   .wp-block-embed figure, left over from a Markdown import, or a raw
   embed code pasted into the classic editor — is forced to the same
   16:9 box, full content width. Videos pasted from different sources
   (YouTube, Loom, etc.) each carry their own hardcoded width="..."
   height="..." attributes from whatever the source site's "copy embed
   code" produced, and those pixel values don't agree with each other
   — that mismatch is exactly what made videos on the same page render
   at visibly different heights. CSS width/height (and aspect-ratio)
   always override an element's HTML width/height attributes, so
   ignoring whatever inline values came with the pasted code and
   applying one consistent rule to all of them fixes that regardless
   of where the embed came from.
   Plain HTML5 <video> keeps its own natural aspect ratio instead
   (height: auto) rather than being forced to 16:9, since actual video
   files can legitimately be a different ratio and cropping them to
   16:9 would distort the picture. */
.hmd-content iframe,
.hmd-content video {
	display: block;
	width: 100%;
	max-width: 100%;
	border-radius: 8px;
}

.hmd-content iframe {
	aspect-ratio: 16 / 9;
	height: auto;
}

.hmd-content video {
	height: auto;
}

.hmd-content audio {
	display: block;
	width: 100%;
	max-width: 100%;
	border-radius: 8px;
	margin: 0 0 20px;
}

/* --------------------------- Definition lists --------------------------- */

.hmd-content dl {
	margin: 0 0 18px;
}

.hmd-content dt {
	font-weight: 600;
	color: var(--hmd-text, #1f2328);
}

.hmd-content dd {
	margin: 0 0 12px 0;
	padding-left: 16px;
	color: var(--hmd-text-muted, #66707a);
}

/* ------------------------- Inline text elements ------------------------- */

.hmd-content kbd {
	font-family: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace;
	font-size: 0.85em;
	background: var(--hmd-bg-subtle, #f7f7f9);
	border: 1px solid var(--hmd-border, #e4e4e8);
	border-bottom-width: 2px;
	border-radius: 4px;
	padding: 1px 6px;
}

.hmd-content mark {
	background: #fef08a;
	color: #1f2328;
	border-radius: 3px;
	padding: 0 3px;
}

[data-hmd-theme="dark"] .hmd-content mark {
	background: #7a6a1a;
	color: #fdf6e3;
}

.hmd-content sub,
.hmd-content sup {
	font-size: 0.75em;
}

.hmd-content abbr {
	text-decoration: underline dotted;
	cursor: help;
}

/* ----------------------------- Task lists ----------------------------- *
 * Markdown "- [ ] todo" / "- [x] done" lines are commonly converted to
 * <ul><li><input type="checkbox">…</li></ul> by importers. Style them
 * so they don't just look like a stray form control in the middle of
 * a list. */
.hmd-content li input[type="checkbox"] {
	margin-right: 8px;
	accent-color: var(--hmd-accent, #4f46e5);
}

.hmd-content ul:has(li > input[type="checkbox"]:first-child) {
	list-style: none;
	padding-left: 4px;
}

/* --------------------------- Details / summary --------------------------- */

.hmd-content details {
	margin: 0 0 18px;
	border: 1px solid var(--hmd-border, #e4e4e8);
	border-radius: 8px;
	padding: 12px 16px;
	background: var(--hmd-bg-subtle, #f7f7f9);
}

.hmd-content summary {
	font-weight: 600;
	cursor: pointer;
}

.hmd-content details[open] summary {
	margin-bottom: 10px;
}

/* --------------------------- Nested blockquotes --------------------------- *
 * Gutenberg's own "wp-block-quote" class and a plain Markdown ">"
 * blockquote both land on the same <blockquote> element, so the base
 * rule above already covers both. This just keeps a second level of
 * nesting (">> quoted reply") visually distinct instead of doubling
 * the same border/background. */
.hmd-content blockquote blockquote {
	border-left-color: var(--hmd-text-muted, #66707a);
	background: transparent;
	margin-top: 12px;
}

/* --------------------- Gutenberg-specific block classes --------------------- *
 * These carry extra classes beyond the plain HTML tag the base rules
 * above already style, so they need a couple of additions on top
 * rather than a full redefinition. */
.hmd-content .wp-block-table {
	overflow-x: auto;
}

.hmd-content .wp-block-pullquote {
	border-top: 3px solid var(--hmd-accent, #4f46e5);
	border-bottom: 3px solid var(--hmd-accent, #4f46e5);
	padding: 24px 0;
	margin: 0 0 20px;
	text-align: center;
}

.hmd-content .wp-block-pullquote blockquote {
	border-left: none;
	background: transparent;
	margin: 0;
	padding: 0;
}

.hmd-content .wp-block-file {
	margin: 0 0 18px;
}

.hmd-content .wp-block-file__button {
	display: inline-block;
	background: var(--hmd-accent, #4f46e5);
	color: #fff;
	border-radius: 6px;
	padding: 6px 14px;
	font-size: 14px;
	font-weight: 500;
	text-decoration: none;
	margin-left: 10px;
}

/* Code blocks can contain very long unbroken lines (URLs, minified
   output) from any of the three sources — force a horizontal
   scrollbar rather than letting them blow out the layout width. */
.hmd-content pre,
.hmd-content pre.wp-block-code {
	max-width: 100%;
}

.hmd-content pre code {
	white-space: pre;
	word-break: normal;
}