@hattisar/design-tokens 0.3.10 → 0.3.12

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hattisar/design-tokens",
-  "version": "0.3.10",
+  "version": "0.3.12",
   "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

@@ -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 Shopify at 1920: their 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 Shopify's 950 for a
+     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;
 }
@@ -1032,6 +1050,50 @@ input[type="date"]::-webkit-calendar-picker-indicator:hover {
  * picker in the app is a Combobox underneath, so this is the
  * 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
+ * field.
+ *
+ * Harder than it looks, because the label's text is a bare text node:
+ * `<label>First Name<input required></label>`. A plain `label::after`
+ * renders after *everything* in the label — under the input, not
+ * beside the words — and the only way to attach it to the text
+ * directly would be to wrap that text in a span on every field of
+ * every form.
+ *
+ * So the label becomes a wrapping flex row for required fields only,
+ * and the three items are ordered explicitly: the text (order 0, an
+ * anonymous flex item), the star (order 1), then the control, forced
+ * onto the next line by a full-width basis. The result is the text and
+ * its star on one line and the field under them — which is what the
+ * label already looked like, with a star added and no markup touched.
+ */
+label:has(:required) {
+  /*
+   * !important because 212 labels in this app carry an inline
+   * `style={{ display: "block" }}`, and an inline declaration beats
+   * any stylesheet rule regardless of specificity. This is the case
+   * the keyword exists for: overriding markup a stylesheet cannot
+   * reach. Without it the star renders after the control on every one
+   * of those labels instead of beside the words.
+   */
+  display: flex !important;
+  flex-wrap: wrap;
+  align-items: baseline;
+}
+
+label:has(:required) > * {
+  order: 2;
+  flex-basis: 100%;
+}
+
+label:has(:required)::after {
+  content: "*";
+  order: 1;
+  margin-left: 2px;
+  color: var(--color-danger);
+}
+
 label:has(:required) {
   color: var(--color-danger);
 }
@@ -1255,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 Shopify does
+   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 {