@ohhwells/bridge 0.1.158 → 0.1.160-next.427

package/dist/index.d.cts

@@ -348,6 +348,51 @@ interface AiFooterRendererProps {
  */
 declare function AiFooterRenderer({ tree, brand, resolveMedia, editKeyPrefix, logoUrl, resolvePageHref, legal, surface, }: AiFooterRendererProps): react_jsx_runtime.JSX.Element | null;
 
+/**
+ * Relative headline sizing: "make the section heading bigger" as a MULTIPLIER on whatever the
+ * template already renders, not an absolute px token.
+ *
+ * Why this exists. The original `headlineScale` prop is an absolute 4-token px scale (md 24 / lg 32
+ * / xl 40 / display 56) painted by a stylesheet rule. Measuring two real templates at 1440px found
+ * 12 of 13 section headings rendering ABOVE the top of that scale (rebound: 148, 64, 72, 84;
+ * haven-realty: 86, 58, 48, 64, 58 x5), so every token the model could pick, `display` included,
+ * made the heading SMALLER. That is the bug users hit: "make it bigger" visibly shrank the heading.
+ *
+ * Why a multiplier rather than more tokens. The same headings render 30-56px at 390px wide, i.e.
+ * the templates have a working responsive type scale. Any absolute px override freezes one width's
+ * value at every width: a `96px` token chosen to beat a 1440px heading would still be 96px on a
+ * phone where the template wanted 36px. A multiplier rides the template's own scale instead, so it
+ * is correct at every breakpoint by construction.
+ *
+ * Why this is runtime JS and not CSS. CSS cannot multiply an element's OWN font-size: `em` and `%`
+ * both resolve against the PARENT's size, so `font-size: calc(1em * 1.2)` on an <h1> throws away
+ * the template's h1 sizing rather than scaling it. The only way to scale what the element actually
+ * renders is to read it and write it back, which is what this module does, re-measuring on resize
+ * so a breakpoint change re-reads the template's new base.
+ */
+/** Multiplier per token. `base` is the template's own size, which is also the reset target. */
+declare const HEADLINE_SIZE_MULTIPLIERS: Record<string, number>;
+
+/**
+ * Per-section and per-node style overrides. The backend's update_style verb (and, later, toolbar
+ * UI) produces a delta {target, changed}; the editor merges it onto one reserved node,
+ * `__ohw_styles`, and hands the whole store to the bridge. The bridge applies it to the DOM:
+ *
+ * - Section props are written as `data-ohw-style-*` attributes on the `[data-ohw-section]` element
+ *   plus one injected stylesheet of attribute-scoped rules. The rules are best-effort by design —
+ *   they nudge presentation (background band, vertical distribution, headline scale, image fit,
+ *   spacing) and a template whose structure doesn't tolerate one simply keeps its current look.
+ * - Node props (text colour/size, button colours) are written inline on every element carrying the
+ *   node's `data-ohw-key`, which covers native template nodes and generated-section slots alike.
+ *
+ * Application is idempotent: each pass clears what it wrote before (tracked via the attributes and
+ * a wrote-marker) and re-applies from the store, so removing an override restores the original look
+ * and re-rendered generated sections just need a re-apply.
+ *
+ * The store shape, the node key, and the enums are a contract with the backend
+ * (`app/helpers/style-update.ts`) and the editor (which persists/undoes the node).
+ */
+
 declare const SECTION_BACKGROUNDS: readonly ["default", "surface", "accent", "accent-soft"];
 declare const TEXT_DISTRIBUTIONS: readonly ["top", "center", "space-between"];
 declare const HEADLINE_SCALES: readonly ["md", "lg", "xl", "display"];
@@ -369,8 +414,20 @@ interface SectionStyleOverride {
     fontFamily?: string;
     /** Section-wide heading colour — painted onto the section's h1-h6 editables, over textColor. */
     headingColor?: string;
+    /** Section-wide ICON colour (OHH-875) — the glyphs in the section's icon slots, which are
+     *  neither headings nor body text, so neither textColor nor headingColor could ever reach them.
+     *  Painted as `color` on each `[data-ohw-editable="icon"]`, which a glyph drawn with
+     *  stroke/fill="currentColor" (lucide and every set like it) follows. Best-effort, like every
+     *  other section prop: a glyph with a hardcoded colour of its own keeps it. */
+    iconColor?: string;
     textDistribution?: (typeof TEXT_DISTRIBUTIONS)[number];
+    /** @deprecated Absolute px headline tokens. Still rendered for stores saved before the switch,
+     *  but nothing writes it any more: it could only ever name a size BELOW what most templates
+     *  render, so "bigger" shrank the heading. New edits use `headlineSize`. */
     headlineScale?: (typeof HEADLINE_SCALES)[number];
+    /** Headline size as a multiplier on the template's own size (`base` = untouched). Relative on
+     *  purpose, and applied by measuring rather than by a CSS rule — see lib/headline-size.ts. */
+    headlineSize?: keyof typeof HEADLINE_SIZE_MULTIPLIERS;
     imageAspect?: string;
     /** @deprecated OHH-789 folds this into verticalPadding — a store saved before the fold may
      *  still carry it; legacyVerticalPaddingAlias resolves it at apply time. */
@@ -666,7 +723,7 @@ declare function filterAvailablePages(pages: LinkPage[], existingTargets: string
 
 declare const toggleVariants: (props?: ({
     variant?: "default" | "outline" | null | undefined;
-    size?: "default" | "lg" | "sm" | null | undefined;
+    size?: "default" | "sm" | "lg" | null | undefined;
 } & class_variance_authority_types.ClassProp) | undefined) => string;
 declare function Toggle({ className, variant, size, ...props }: React.ComponentProps<typeof Toggle$1.Root> & VariantProps<typeof toggleVariants>): react_jsx_runtime.JSX.Element;
 

package/dist/index.d.ts

@@ -348,6 +348,51 @@ interface AiFooterRendererProps {
  */
 declare function AiFooterRenderer({ tree, brand, resolveMedia, editKeyPrefix, logoUrl, resolvePageHref, legal, surface, }: AiFooterRendererProps): react_jsx_runtime.JSX.Element | null;
 
+/**
+ * Relative headline sizing: "make the section heading bigger" as a MULTIPLIER on whatever the
+ * template already renders, not an absolute px token.
+ *
+ * Why this exists. The original `headlineScale` prop is an absolute 4-token px scale (md 24 / lg 32
+ * / xl 40 / display 56) painted by a stylesheet rule. Measuring two real templates at 1440px found
+ * 12 of 13 section headings rendering ABOVE the top of that scale (rebound: 148, 64, 72, 84;
+ * haven-realty: 86, 58, 48, 64, 58 x5), so every token the model could pick, `display` included,
+ * made the heading SMALLER. That is the bug users hit: "make it bigger" visibly shrank the heading.
+ *
+ * Why a multiplier rather than more tokens. The same headings render 30-56px at 390px wide, i.e.
+ * the templates have a working responsive type scale. Any absolute px override freezes one width's
+ * value at every width: a `96px` token chosen to beat a 1440px heading would still be 96px on a
+ * phone where the template wanted 36px. A multiplier rides the template's own scale instead, so it
+ * is correct at every breakpoint by construction.
+ *
+ * Why this is runtime JS and not CSS. CSS cannot multiply an element's OWN font-size: `em` and `%`
+ * both resolve against the PARENT's size, so `font-size: calc(1em * 1.2)` on an <h1> throws away
+ * the template's h1 sizing rather than scaling it. The only way to scale what the element actually
+ * renders is to read it and write it back, which is what this module does, re-measuring on resize
+ * so a breakpoint change re-reads the template's new base.
+ */
+/** Multiplier per token. `base` is the template's own size, which is also the reset target. */
+declare const HEADLINE_SIZE_MULTIPLIERS: Record<string, number>;
+
+/**
+ * Per-section and per-node style overrides. The backend's update_style verb (and, later, toolbar
+ * UI) produces a delta {target, changed}; the editor merges it onto one reserved node,
+ * `__ohw_styles`, and hands the whole store to the bridge. The bridge applies it to the DOM:
+ *
+ * - Section props are written as `data-ohw-style-*` attributes on the `[data-ohw-section]` element
+ *   plus one injected stylesheet of attribute-scoped rules. The rules are best-effort by design —
+ *   they nudge presentation (background band, vertical distribution, headline scale, image fit,
+ *   spacing) and a template whose structure doesn't tolerate one simply keeps its current look.
+ * - Node props (text colour/size, button colours) are written inline on every element carrying the
+ *   node's `data-ohw-key`, which covers native template nodes and generated-section slots alike.
+ *
+ * Application is idempotent: each pass clears what it wrote before (tracked via the attributes and
+ * a wrote-marker) and re-applies from the store, so removing an override restores the original look
+ * and re-rendered generated sections just need a re-apply.
+ *
+ * The store shape, the node key, and the enums are a contract with the backend
+ * (`app/helpers/style-update.ts`) and the editor (which persists/undoes the node).
+ */
+
 declare const SECTION_BACKGROUNDS: readonly ["default", "surface", "accent", "accent-soft"];
 declare const TEXT_DISTRIBUTIONS: readonly ["top", "center", "space-between"];
 declare const HEADLINE_SCALES: readonly ["md", "lg", "xl", "display"];
@@ -369,8 +414,20 @@ interface SectionStyleOverride {
     fontFamily?: string;
     /** Section-wide heading colour — painted onto the section's h1-h6 editables, over textColor. */
     headingColor?: string;
+    /** Section-wide ICON colour (OHH-875) — the glyphs in the section's icon slots, which are
+     *  neither headings nor body text, so neither textColor nor headingColor could ever reach them.
+     *  Painted as `color` on each `[data-ohw-editable="icon"]`, which a glyph drawn with
+     *  stroke/fill="currentColor" (lucide and every set like it) follows. Best-effort, like every
+     *  other section prop: a glyph with a hardcoded colour of its own keeps it. */
+    iconColor?: string;
     textDistribution?: (typeof TEXT_DISTRIBUTIONS)[number];
+    /** @deprecated Absolute px headline tokens. Still rendered for stores saved before the switch,
+     *  but nothing writes it any more: it could only ever name a size BELOW what most templates
+     *  render, so "bigger" shrank the heading. New edits use `headlineSize`. */
     headlineScale?: (typeof HEADLINE_SCALES)[number];
+    /** Headline size as a multiplier on the template's own size (`base` = untouched). Relative on
+     *  purpose, and applied by measuring rather than by a CSS rule — see lib/headline-size.ts. */
+    headlineSize?: keyof typeof HEADLINE_SIZE_MULTIPLIERS;
     imageAspect?: string;
     /** @deprecated OHH-789 folds this into verticalPadding — a store saved before the fold may
      *  still carry it; legacyVerticalPaddingAlias resolves it at apply time. */
@@ -666,7 +723,7 @@ declare function filterAvailablePages(pages: LinkPage[], existingTargets: string
 
 declare const toggleVariants: (props?: ({
     variant?: "default" | "outline" | null | undefined;
-    size?: "default" | "lg" | "sm" | null | undefined;
+    size?: "default" | "sm" | "lg" | null | undefined;
 } & class_variance_authority_types.ClassProp) | undefined) => string;
 declare function Toggle({ className, variant, size, ...props }: React.ComponentProps<typeof Toggle$1.Root> & VariantProps<typeof toggleVariants>): react_jsx_runtime.JSX.Element;