@uniweb/kit 0.10.0 → 0.10.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniweb/kit",
-  "version": "0.10.0",
+  "version": "0.10.2",
   "description": "Standard component library for Uniweb foundations",
   "type": "module",
   "exports": {
@@ -36,13 +36,14 @@
     "node": ">=20.19"
   },
   "dependencies": {
+    "@tailwindcss/typography": "^0.5.20",
     "clsx": "^2.1.0",
     "fuse.js": "^7.0.0",
     "shiki": "^3.0.0",
     "tailwind-merge": "^3.6.0",
-    "@uniweb/semantic-parser": "1.2.0",
     "@uniweb/core": "0.8.0",
-    "@uniweb/scene": "0.1.2"
+    "@uniweb/scene": "0.1.2",
+    "@uniweb/semantic-parser": "1.2.0"
   },
   "peerDependencies": {
     "react": "^19.0.0",

package/src/prose-tokens.css

@@ -1,11 +1,14 @@
 /*
  * Tailwind Typography, wired to the theme.
  *
- * Usage — after the plugin, so these win on equal specificity:
+ * Usage — one line, in the foundation's stylesheet:
  *
- *   @plugin "@tailwindcss/typography";
  *   @import "@uniweb/kit/prose-tokens.css";
  *
+ * That is the whole setup: this file brings the plugin with it (below) and then
+ * overrides its greys. It used to take two lines, and the foundation had to
+ * install the plugin itself and remember that the order mattered.
+ *
  * `prose` ships its own greys, which means long-form body copy is the one part
  * of a foundation that ignores the site's theme.yml unless someone bridges it
  * by hand. Everyone does bridge it by hand, identically, and the bridge is easy
@@ -29,6 +32,33 @@
  * other one only supplies column width and padding.
  */
 
+/*
+ * The plugin comes from kit, and the ORDER below is the reason.
+ *
+ * A `@plugin` inside a package's own CSS resolves from that package's
+ * dependencies, so a foundation importing this file needs nothing installed
+ * (verified 2026-07-30: a foundation with no typography dependency and no
+ * `@plugin` line of its own emitted `.prose :where(p){margin-top:1.25em}` in a
+ * production build).
+ *
+ * Why it moved here rather than staying the foundation's job. The overrides
+ * below have to come AFTER the plugin's own declarations or they lose on equal
+ * specificity — which made "install this, then import that, in this order" a
+ * three-part instruction a foundation could get subtly wrong, and the failure
+ * is silent: the variables are set, the rules they modify do not exist, and
+ * prose renders with no margins at all. Measured on a foundation missing only
+ * the plugin: `--tw-prose-body` present, every paragraph `margin-top: 0px`, no
+ * warning from anywhere. Owning both halves here makes the order unorderable.
+ *
+ * The precedent is `shiki` and `fuse.js` — kit takes DIRECT dependencies on
+ * what its own code needs at build time rather than asking a foundation to
+ * supply them (framework CLAUDE.md gotcha #10). This is that rule applied to
+ * the CSS layer. A foundation that never writes `prose` pays disk only:
+ * Tailwind emits utilities that are used, so an unused plugin generates
+ * nothing.
+ */
+@plugin "@tailwindcss/typography";
+
 .prose {
   --tw-prose-body: var(--body);
   --tw-prose-headings: var(--heading);

package/src/styled/Render/index.jsx

@@ -144,6 +144,51 @@ function renderAll(sequence, block, components) {
   ))
 }
 
+/**
+ * A table cell's contents, with a lone block UNWRAPPED.
+ *
+ * The schema declares `tableCell` as `paragraph+`, so a markdown cell is always
+ * exactly one block — and emitting its `<p>` faithfully is what a typography
+ * layer then gives paragraph margins to. Measured on a real docs site: 17.5px
+ * top and bottom inside every cell, turning a one-line reference row into 75px.
+ *
+ * TWO shapes reach a cell, which is easy to miss and was: an ordinary paragraph,
+ * and a `link` — because the parser PROMOTES a paragraph holding nothing but a
+ * link, which is what makes a link on its own line a call to action in prose.
+ * A cell whose whole content is a link is the same promotion arriving somewhere
+ * it means nothing, so it unwraps too. Fixing only the paragraph left every
+ * link-only cell tall, which is how this was found: 17 of them on one page.
+ *
+ * A cell holding genuinely several blocks still gets them, because that is what
+ * it is.
+ */
+function renderCell(cell, block, components) {
+  const children = cell.children || []
+  if (children.length !== 1) return renderAll(children, block, components)
+
+  const [only] = children
+
+  if (only?.type === 'paragraph') {
+    if (!only.text) return null
+    return /<uniweb-inset/.test(only.text) ? (
+      renderParagraphWithInsets(only.text, block)
+    ) : (
+      <SafeHtml value={only.text} as="span" />
+    )
+  }
+
+  if (only?.type === 'link') {
+    const { href, label } = only.attrs || {}
+    return <Link to={href}>{label}</Link>
+  }
+
+  if (only?.type === 'button') {
+    return <Link to={only.attrs?.href}>{only.text}</Link>
+  }
+
+  return renderAll(children, block, components)
+}
+
 /**
  * One element of a sequence.
  *
@@ -255,7 +300,7 @@ export function SequenceElement({ element, block, components }) {
                 colSpan={cell.colspan > 1 ? cell.colspan : undefined}
                 rowSpan={cell.rowspan > 1 ? cell.rowspan : undefined}
               >
-                {renderAll(cell.children, block, components)}
+                {renderCell(cell, block, components)}
               </CellTag>
             )
           })}