@hattisar/design-tokens 0.3.11 → 0.3.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hattisar/design-tokens",
-  "version": "0.3.11",
+  "version": "0.3.13",
   "description": "Shared design tokens (colors, type, radius, spacing, motion) and base primitives (reset, buttons, inputs, cards, modals, auth shell) for every Hattisar frontend.",
   "main": "tokens.css",
   "files": [

package/tokens.css

@@ -277,7 +277,7 @@
      A control that stretches to the page is the thing that made these
      forms read as a wall: an email box does not need 900px, and at
      that width the eye has to travel back across empty space to find
-     the next label. Zoho holds both to a fixed, comfortable size and
+     the next label. Both are held to a fixed, comfortable size and
      lets the page be as wide as it likes. */
   --form-label-width: 160px;
   --form-control-width: 340px;
@@ -352,17 +352,35 @@
   --sidebar-width-collapsed: 64px;
   --sidebar-height: calc(100vh - var(--header-height));
 
-  /* Three content widths, not one — simple field-only forms (Credit
-     Memos, Settings CRUD, ...), structured views with a sidebar or grid
-     (Dashboard, Customer/Vendor forms, Modules), and line-item-heavy
-     documents (Invoices, Purchase Orders, ...) don't read well at the
-     same width. Every page that opts into one of these also centers via
-     margin: 0 auto (see .record-form-layout > form, .wide-form-layout >
-     form, .dashboard-page-content, .settings-layout-content below) —
-     instead of each page picking its own guess at either. */
-  --page-width-small: 800px;
-  --page-width-medium: 1152px;
-  --page-width-large: 1600px;
+  /* Two widths, because a page is one of two things.
+     Measured against a storefront admin at 1920: its product *list* runs
+     256→1888, effectively the full area, and their product *form* runs
+     605→1554 — 950px, centred, with 365px of gap either side. A table
+     wants every pixel; a form wants a column you can read across
+     without your eyes travelling.
+
+     There were three before — 800 for plain field lists, 1152 for
+     forms with a sidebar, 1600 for line-item documents — and they were
+     flush left. Three caps left-aligned is the worst of both: the
+     right edge moves between pages *and* so does the amount of empty
+     space, so the app reads as if it cannot decide how wide it is.
+
+     --page-width-content is 1152 rather than the 950 measured there,
+     reason that is ours and not theirs: their product form has no
+     line-item grid and every one of our documents does. A sales order
+     at 950 would scroll its item table sideways on every visit, and
+     trading a horizontal scroll on the busiest form in the app for
+     200px of symmetry is a bad deal. */
+  --page-width-content: 1152px;
+
+  /* Kept as aliases: several rules and a handful of pages still name
+     them, and pointing all three at the same value is what makes the
+     consolidation a one-line change rather than a sweep through forty
+     files. They resolve to the same width now — the modifier classes
+     are inert. */
+  --page-width-small: var(--page-width-content);
+  --page-width-medium: var(--page-width-content);
+  --page-width-large: var(--page-width-content);
 
   color-scheme: light dark;
 }
@@ -1011,7 +1029,7 @@ input[type="date"]::-webkit-calendar-picker-indicator:hover {
 /* A required field says so on its label, in the red this app already
    uses for things that are wrong or missing.
    Asked for: "use our existing red for required field title" — the
-   same convention Zoho uses, where a required label is red and the
+   usual convention, where a required label is red and the
    optional ones are not.
 
    Written as `:has()` rather than a prop on forty forms: the label
@@ -1033,7 +1051,7 @@ input[type="date"]::-webkit-calendar-picker-indicator:hover {
  * difference between one red label on a form and all of them.
  */
 /*
- * And a star after the label text, the way Zoho marks a required
+ * And a star after the label text, the usual way to mark a required
  * field.
  *
  * Harder than it looks, because the label's text is a bare text node:
@@ -1299,37 +1317,28 @@ input[type="radio"] {
   margin-bottom: 12px;
 }
 
-/* Capped, NOT centered — small by default, the right width for a plain
-   field-only form (Credit Memos, Vendor Payments, most Settings CRUD
-   pages, ...). Flush left, same edge as the page's own <h2> title (a
-   separate sibling outside this box) and the same edge every list page
-   (.reports-layout-content/.settings-layout-content) already starts
-   from — centering via margin:0 auto instead used to drift this box's
-   left edge away from both of those, and away from itself between a
-   wide table and a two-field form, reading as content jumping around
-   from page to page instead of a page that's simply narrower. */
-.record-form-layout > form {
-  flex: 1;
-  min-width: 0;
-  max-width: var(--page-width-small);
-}
+/* Capped and centred, one width for every form.
+   This reverses the note that stood here, so the reasoning it replaces
+   is worth keeping rather than deleting: centring was rejected before
+   because it drifted the form's left edge away from the page's own
+   title and away from the list pages' left edge, so content appeared
+   to jump around between pages.
 
-/* Structured forms that need more room than a plain field list but
-   aren't a line-item document — a sidebar panel (Customer/Vendor +
-   Notes/Tags) or a longer component list (Builds). Opt in with both
-   classes: className="record-form-layout medium-form-layout". */
-.record-form-layout.medium-form-layout > form {
-  max-width: var(--page-width-medium);
-}
+   That was true, and it was true *because there were three widths*. A
+   centred box only moves if the box keeps changing size — with one
+   width the left edge is the same on every form in the app, which is
+   the thing the old note actually wanted. The page title moves with
+   it, so the two stay aligned.
 
-/* Wide-table document forms (Invoices, Purchase Orders, Sales Orders,
-   ...) need more room than --page-width-medium for their line-items
-   table, but a truly unbounded max-width stretches those rows into
-   awkward proportions on an ultra-wide monitor — capped generously
-   instead, still full-bleed on any normal screen. Flush left, same
-   reasoning as .record-form-layout > form above. */
+   Tables are untouched and stay full width, which is what those do
+   and what a table wants. */
+.record-form-layout > form,
+.record-form-layout.medium-form-layout > form,
 .wide-form-layout > form {
-  max-width: var(--page-width-large);
+  flex: 1;
+  min-width: 0;
+  max-width: var(--page-width-content);
+  margin-inline: auto;
 }
 
 .wide-form-layout .party-form-columns {