@hattisar/design-tokens 0.3.12 → 0.3.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hattisar/design-tokens",
-  "version": "0.3.12",
+  "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;
@@ -353,7 +353,7 @@
   --sidebar-height: calc(100vh - var(--header-height));
 
   /* Two widths, because a page is one of two things.
-     Measured against Shopify at 1920: their product *list* runs
+     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
@@ -365,7 +365,7 @@
      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
+     --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
@@ -1029,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
@@ -1051,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:
@@ -1330,7 +1330,7 @@ input[type="radio"] {
    the thing the old note actually wanted. The page title moves with
    it, so the two stay aligned.
 
-   Tables are untouched and stay full width, which is what Shopify does
+   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,