{ "version": 3, "sources": ["notionkit.css"], "sourcesContent": ["/* ============================================================\n NOTIONKIT COMPONENT LIBRARY\n Jungherz GmbH \u2013 v1.19.1\n\n A pure CSS component library for calm, document-centric\n workspace interfaces. No build step, no JavaScript, no\n framework coupling.\n\n Features:\n - Scoped reset (no unprefixed global selectors)\n - Light mode (default) + dark mode via [data-theme=\"dark\"]\n - ~130 components across app shell, page, database, forms,\n overlays, collaboration and AI surfaces\n - Editor adapter section for TipTap / BlockNote / Novel, sharing\n its rules with .nk-prose for rendered text\n ============================================================ */\n\n\n/* ============================================================\n A NOTE ON THE TWO-BLOCK STRUCTURE\n\n This file is physically split into two contiguous blocks:\n\n BLOCK A \u2013 design tokens: :root { \u2026 } [data-theme=\"dark\"] { \u2026 }\n BLOCK B \u2013 components: everything else, no --nk-* declarations\n\n build-styles-js.mjs slices the minified sheet at exactly those\n two rule blocks and emits tokensCss / componentsCss separately.\n The split is asserted at build time; if a --nk-* declaration\n leaks into a component rule, or if the two token blocks stop\n being adjacent, the build fails.\n\n Why it matters: a shadow root that adopts the *whole* sheet\n also adopts the token blocks, and inside that shadow root the\n selectors match the element's own theme wrapper. Every token is\n then re-declared locally \u2014 and a matching rule always beats an\n inherited value, so a consumer's own `:root { --nk-accent: \u2026 }`\n never arrives. Consumers that adopt only componentsCss keep\n inheritance intact and put tokensCss on the document instead.\n\n Practical consequences while editing this file:\n - Never declare a --nk-* custom property outside BLOCK A.\n - Never put a rule between the :root and [data-theme=\"dark\"] blocks.\n - Derive brand-dependent values with color-mix() from a token,\n never from a hard-coded hex. Re-branding must stay reachable\n from a handful of declarations.\n ============================================================ */\n\n\n/* ============================================================\n A NOTE ON THE ::slotted() PAIRS\n\n Several rules are written twice, e.g.\n\n .nk-tree-item .icon,\n .nk-tree-item ::slotted(.icon) { \u2026 }\n\n They are not redundant. When this sheet is adopted into a shadow\n root \u2014 as NotionKit Elements will do \u2014 content passed in from the\n outside stays in the light DOM and is therefore no descendant of\n anything in the shadow tree. `.nk-tree-item .icon` cannot reach it;\n only `::slotted()` can.\n\n Do not \"simplify\" these away. In the document they match nothing,\n so they cost nothing there.\n\n Three limits worth knowing:\n - ::slotted() only ever matches the assigned node itself. An icon\n wrapped in a container \u2014 \uD83D\uDCCC \u2014\n cannot be styled from inside the shadow root at all. Pass slotted\n content directly.\n - The descendant space is mandatory: `.nk-callout ::slotted(.c-icon)`,\n never `.nk-callout::slotted(.c-icon)`. The compound before\n ::slotted selects the slot element inside the shadow tree.\n - For slotted content the outer tree wins. A consumer's own document\n rule takes precedence over ::slotted() from the shadow tree. That\n is a feature, not a bug.\n - Since 1.1.0 every part that NotionKit Elements exposes as a named\n slot has a second twin keyed on the slot name, e.g.\n `.nk-tree-item ::slotted([slot=\"icon\"])`, so a consumer writes\n \uD83D\uDCC1 without repeating the internal class.\n - Margin and padding in a twin are marked !important when the scoped\n reset (0. above) also sets them \u2013 on buttons, headings, paragraphs.\n The reset lives in the document tree, and for *normal* declarations\n the outer tree beats ::slotted() from the shadow tree; for\n !important ones the inner tree wins. Without the flag a slotted\n