@yuneta/gobj-ui 7.23.17 → 7.23.18

package/dist/gobj-ui.cjs.js

@@ -10080,16 +10080,39 @@ var PRIVATE_DATA$11 = {
 var __gclass__$11 = null;
 var __layout_registered__$1 = false;
 /***************************************************************
-*  Type colors matching the original mx_json_viewer
-***************************************************************/
-var TYPE_COLORS = {
+*  Type colours, ONE EXPLICIT PALETTE PER THEME and not a
+*  derivation, for the same reason the tree keeps two sets of
+*  CSS tokens: a colour that reads on white is not the same
+*  colour lightened, and deriving one from the other made the
+*  two views of one document disagree about what a string is.
+*  These ARE the tree's tokens (`c_yui_json.css`), so the tree
+*  and the graph now say green with the same green.
+*
+*  The light values are darker than the `mx_json_viewer` ones
+*  they came from, because those could not be read: `#FF8C00`
+*  is mid-luminance, so it reaches at most **2.33:1 against any
+*  background that exists** -- no card colour and no highlight
+*  could have fixed it, only the colour itself. Orange and blue
+*  moved until every type clears 4.5:1 on all five surfaces this
+*  viewer paints (two light cards, the match chip, two dark
+*  cards); red and green were already there.
+***************************************************************/
+var TYPE_COLORS_LIGHT = {
 	string: "#006000",
-	number: "#EE422E",
-	boolean: "#FF8C00",
-	null: "#475ED0",
+	number: "#b5330b",
+	boolean: "#8C4D00",
+	null: "#4359C6",
 	list: "#4C0099",
 	dict: "#4C0099"
 };
+var TYPE_COLORS_DARK = {
+	string: "#7ec87e",
+	number: "#ff8a65",
+	boolean: "#ffb74d",
+	null: "#90a4f4",
+	list: "#B799D6",
+	dict: "#B799D6"
+};
 /***************************************************************
 *  Group (card) colours. `fill` is the light-theme card; `tint`
 *  is the hue that fill hints at, used to derive the dark card —
@@ -10143,21 +10166,15 @@ function json_card_style(group, dark) {
 	};
 }
 /***************************************************************
-*  A scalar's colour by type. The palette is tuned for a light
-*  card; on a dark one every one of them (dark green #006000,
-*  blue #475ED0, …) sinks into the background, so brighten it.
-*
-*  60% white and not the 45% it shipped with.  The number is a
-*  balance measured both ways: brighter reads better on the dark
-*  card (the worst type goes from 2.88:1 to 4.74:1) and washes the
-*  six types toward one pastel, and past this point red, orange
-*  and purple stop being tellable apart, which is the only reason
-*  they are coloured at all.
+*  A scalar's colour by type, straight out of the palette for
+*  the theme.  It used to be the light colour mixed with white,
+*  which is how a document ended up green in one view and a
+*  paler green in the other, and how the amount of white became
+*  a knob nobody could set: enough of it to read on a dark card
+*  washed the six types into one pastel.
 ***************************************************************/
 function type_color(type, dark) {
-	let color = TYPE_COLORS[type] || (dark ? "#e8eaed" : "black");
-	if (!dark) return color;
-	return `color-mix(in srgb, ${color} 40%, #ffffff)`;
+	return (dark ? TYPE_COLORS_DARK : TYPE_COLORS_LIGHT)[type] || (dark ? "#e8eaed" : "black");
 }
 /******************************
 *      Framework Methods

package/dist/gobj-ui.es.js

@@ -10075,16 +10075,39 @@ var PRIVATE_DATA$11 = {
 var __gclass__$11 = null;
 var __layout_registered__$1 = false;
 /***************************************************************
-*  Type colors matching the original mx_json_viewer
-***************************************************************/
-var TYPE_COLORS = {
+*  Type colours, ONE EXPLICIT PALETTE PER THEME and not a
+*  derivation, for the same reason the tree keeps two sets of
+*  CSS tokens: a colour that reads on white is not the same
+*  colour lightened, and deriving one from the other made the
+*  two views of one document disagree about what a string is.
+*  These ARE the tree's tokens (`c_yui_json.css`), so the tree
+*  and the graph now say green with the same green.
+*
+*  The light values are darker than the `mx_json_viewer` ones
+*  they came from, because those could not be read: `#FF8C00`
+*  is mid-luminance, so it reaches at most **2.33:1 against any
+*  background that exists** -- no card colour and no highlight
+*  could have fixed it, only the colour itself. Orange and blue
+*  moved until every type clears 4.5:1 on all five surfaces this
+*  viewer paints (two light cards, the match chip, two dark
+*  cards); red and green were already there.
+***************************************************************/
+var TYPE_COLORS_LIGHT = {
 	string: "#006000",
-	number: "#EE422E",
-	boolean: "#FF8C00",
-	null: "#475ED0",
+	number: "#b5330b",
+	boolean: "#8C4D00",
+	null: "#4359C6",
 	list: "#4C0099",
 	dict: "#4C0099"
 };
+var TYPE_COLORS_DARK = {
+	string: "#7ec87e",
+	number: "#ff8a65",
+	boolean: "#ffb74d",
+	null: "#90a4f4",
+	list: "#B799D6",
+	dict: "#B799D6"
+};
 /***************************************************************
 *  Group (card) colours. `fill` is the light-theme card; `tint`
 *  is the hue that fill hints at, used to derive the dark card —
@@ -10138,21 +10161,15 @@ function json_card_style(group, dark) {
 	};
 }
 /***************************************************************
-*  A scalar's colour by type. The palette is tuned for a light
-*  card; on a dark one every one of them (dark green #006000,
-*  blue #475ED0, …) sinks into the background, so brighten it.
-*
-*  60% white and not the 45% it shipped with.  The number is a
-*  balance measured both ways: brighter reads better on the dark
-*  card (the worst type goes from 2.88:1 to 4.74:1) and washes the
-*  six types toward one pastel, and past this point red, orange
-*  and purple stop being tellable apart, which is the only reason
-*  they are coloured at all.
+*  A scalar's colour by type, straight out of the palette for
+*  the theme.  It used to be the light colour mixed with white,
+*  which is how a document ended up green in one view and a
+*  paler green in the other, and how the amount of white became
+*  a knob nobody could set: enough of it to read on a dark card
+*  washed the six types into one pastel.
 ***************************************************************/
 function type_color(type, dark) {
-	let color = TYPE_COLORS[type] || (dark ? "#e8eaed" : "black");
-	if (!dark) return color;
-	return `color-mix(in srgb, ${color} 40%, #ffffff)`;
+	return (dark ? TYPE_COLORS_DARK : TYPE_COLORS_LIGHT)[type] || (dark ? "#e8eaed" : "black");
 }
 /******************************
 *      Framework Methods

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yuneta/gobj-ui",
-  "version": "7.23.17",
+  "version": "7.23.18",
   "type": "module",
   "main": "dist/gobj-ui.cjs.js",
   "module": "dist/gobj-ui.es.js",

package/src/c_yui_json.css

@@ -9,11 +9,20 @@
  *          All Rights Reserved.
  ***********************************************************************/
 
+/*
+ *  Light values are darker than a naive orange/blue because they have to
+ *  be READ, on the card and on the graph view's match chip alike.  The
+ *  ceiling is a fact of the colour, not of the surface: `#FF8C00`, which
+ *  these came from, is mid-luminance and reaches at most 2.33:1 against
+ *  ANY background that exists.  The graph view carries the same two
+ *  palettes (`c_yui_json_graph.js`), so one document says green with the
+ *  same green in all three views.
+ */
 .C_YUI_JSON {
     --json-string: #006000;
     --json-number: #b5330b;
-    --json-boolean: #b36b00;
-    --json-null: #475ed0;
+    --json-boolean: #8C4D00;
+    --json-null: #4359C6;
     --json-key: var(--bulma-text-strong, #1a1a1a);
     --json-row-hover: rgba(0, 0, 0, 0.05);
     --json-guide: #b5b5b5;

package/src/c_yui_json_graph.js

@@ -197,17 +197,41 @@ let __layout_registered__ = false;
 
 
 /***************************************************************
- *  Type colors matching the original mx_json_viewer
+ *  Type colours, ONE EXPLICIT PALETTE PER THEME and not a
+ *  derivation, for the same reason the tree keeps two sets of
+ *  CSS tokens: a colour that reads on white is not the same
+ *  colour lightened, and deriving one from the other made the
+ *  two views of one document disagree about what a string is.
+ *  These ARE the tree's tokens (`c_yui_json.css`), so the tree
+ *  and the graph now say green with the same green.
+ *
+ *  The light values are darker than the `mx_json_viewer` ones
+ *  they came from, because those could not be read: `#FF8C00`
+ *  is mid-luminance, so it reaches at most **2.33:1 against any
+ *  background that exists** -- no card colour and no highlight
+ *  could have fixed it, only the colour itself. Orange and blue
+ *  moved until every type clears 4.5:1 on all five surfaces this
+ *  viewer paints (two light cards, the match chip, two dark
+ *  cards); red and green were already there.
  ***************************************************************/
-const TYPE_COLORS = {
+const TYPE_COLORS_LIGHT = {
     string:  "#006000",     // green
-    number:  "#EE422E",     // red
-    boolean: "#FF8C00",     // orange
-    null:    "#475ED0",     // blue
+    number:  "#b5330b",     // red
+    boolean: "#8C4D00",     // orange
+    null:    "#4359C6",     // blue
     list:    "#4C0099",     // purple
     dict:    "#4C0099",     // purple
 };
 
+const TYPE_COLORS_DARK = {
+    string:  "#7ec87e",
+    number:  "#ff8a65",
+    boolean: "#ffb74d",
+    null:    "#90a4f4",
+    list:    "#B799D6",
+    dict:    "#B799D6",
+};
+
 /***************************************************************
  *  Group (card) colours. `fill` is the light-theme card; `tint`
  *  is the hue that fill hints at, used to derive the dark card —
@@ -260,24 +284,17 @@ function json_card_style(group, dark)
 }
 
 /***************************************************************
- *  A scalar's colour by type. The palette is tuned for a light
- *  card; on a dark one every one of them (dark green #006000,
- *  blue #475ED0, …) sinks into the background, so brighten it.
- *
- *  60% white and not the 45% it shipped with.  The number is a
- *  balance measured both ways: brighter reads better on the dark
- *  card (the worst type goes from 2.88:1 to 4.74:1) and washes the
- *  six types toward one pastel, and past this point red, orange
- *  and purple stop being tellable apart, which is the only reason
- *  they are coloured at all.
+ *  A scalar's colour by type, straight out of the palette for
+ *  the theme.  It used to be the light colour mixed with white,
+ *  which is how a document ended up green in one view and a
+ *  paler green in the other, and how the amount of white became
+ *  a knob nobody could set: enough of it to read on a dark card
+ *  washed the six types into one pastel.
  ***************************************************************/
 function type_color(type, dark)
 {
-    let color = TYPE_COLORS[type] || (dark ? "#e8eaed" : "black");
-    if(!dark) {
-        return color;
-    }
-    return `color-mix(in srgb, ${color} 40%, #ffffff)`;
+    let palette = dark? TYPE_COLORS_DARK: TYPE_COLORS_LIGHT;
+    return palette[type] || (dark ? "#e8eaed" : "black");
 }