You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: spx-gui/AGENTS.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -94,6 +94,7 @@ When working with backend unique string identifiers such as `username`, project
94
94
95
95
* Keep `src/app.css` limited to Tailwind entry setup, theme bridge, and rare project-wide utilities.
96
96
* Keep `src/components/ui/global.css` and `src/components/ui/reset.css` as the base reset/foundation layer (Tailwind preflight stays disabled).
97
+
* The global CSS layer order is `theme, base, naive-ui, components, utilities`, declared in `index.html`.
97
98
* Keep `--ui-*` tokens as the source of truth.
98
99
* In Tailwind classes, prefer bridged semantic tokens (for example `text-text`, `text-title`, `bg-primary-100`).
99
100
* In local CSS, prefer direct `--ui-*` variables instead of bridged Tailwind variables.
@@ -119,7 +120,8 @@ When working with backend unique string identifiers such as `username`, project
119
120
* For root-class overrides and utility conflicts:
120
121
- For business components, external root `class` overrides are allowed by default. If utility conflicts need an explicit winner, prefer adding Tailwind's important modifier at the usage site (for example `rounded-md!`, `w-32!`) instead of expanding the component API. This keeps intent explicit, usage concise, and matches the fact that business components rarely need nested override chains.
121
122
- For most UI components, `twMerge` and `@layer components` are set up so external utilities or custom classes can override root classes in the common case without special handling, though edge cases can still exist.
122
-
- For the Naive UI-root components listed in `src/components/ui/README.md`, avoid relying on external `class` for styling-critical overrides when possible; the final result is often hard to predict.
123
+
- For the Naive UI-root components listed in `src/components/ui/README.md`, Naive UI defaults live in the `naive-ui` layer and our authored UI styles live in the `components` layer, so component-layer rules have higher cascade priority on the same element/property pair.
124
+
- Even so, those Naive UI-root components still are not identical to DOM-root utility wrappers. Treat them as component-specific: simple root overrides are often fine, while deeper visual changes may still need wrapper layout control, explicit props, or Naive UI theme overrides.
123
125
* Avoid non-equivalent Tailwind simplifications for flex values. In particular, `flex: 1 1 0` is not equivalent to Tailwind `flex-1` (`flex: 1 1 0%`), so do not simplify between them unless the layout behavior has been verified. Likewise, do not simplify `flex: 0 0 auto` to `shrink-0`; use the equivalent `flex-none` when that shorthand is desired.
124
126
* Prefer `style` / `:style` for one-off values when clearer than Tailwind arbitrary utilities. For example, prefer `style="box-shadow: 0 24px 32px -16px rgba(0, 0, 0, 0.1)"` over a long arbitrary utility such as `shadow-[0_24px_32px_-16px_rgba(0,0,0,0.1)]`.
125
127
* For important/non-obvious background assets, prefer TS imports and inline `backgroundImage` binding.
Copy file name to clipboardExpand all lines: spx-gui/src/components/ui/README.md
+10-6Lines changed: 10 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,13 +22,15 @@
22
22
- For most non-Naive UI components, prefer Tailwind utilities for local structure, layout, and surface styling
23
23
- Local authored style blocks in the UI package use plain CSS; do not reintroduce SCSS
24
24
- Keep complex selectors, animations, third-party/global overrides, and other readability-sensitive rules in plain CSS
25
+
- The global CSS layer order is `theme, base, naive-ui, components, utilities` and is declared in `spx-gui/index.html`
25
26
26
27
- Root class handling
27
28
28
-
- Current cases fall into three buckets: DOM-root components with merged utilities, single-root semantic wrappers that rely on inherited classes, and Naive UI-root wrappers whose final class priority can be harder to predict
29
-
- If the root is a normal DOM element and the component already owns root utility classes, use `cn(..., attrs.class)` so external root classes are merged with`tailwind-merge`
29
+
- Current cases fall into three buckets: DOM-root components with merged utilities, single-root semantic wrappers that rely on inherited classes, and Naive UI-root wrappers whose root-level styling behavior still needs component-specific judgment
30
+
- If the root is a normal DOM element and the component already owns root utility classes, prefer an explicit `class?: ClassValue` prop and merge it with `cn(..., props.class ?? null)` so external root classes participate in`tailwind-merge`
30
31
- If the component is a single-root wrapper whose styling still depends on semantic hook classes in `@layer components`, prefer Vue's default root attr/class/style inheritance unless explicit root attr control is needed
31
-
- If the rendered root is primarily a Naive UI component, do not assume external root classes will override reliably. Naive UI's internal styles are not layered with our component styles, so their priority can be higher and the final visual result may be hard to predict
32
+
- If the rendered root is primarily a Naive UI component, remember that Naive UI styles live in the `naive-ui` layer while our authored UI styles live in `@layer components`, so component-layer rules have higher cascade priority than Naive UI defaults on the same element/property pair
33
+
- Even so, Naive UI-root components still do not behave exactly like DOM-root utility wrappers: some visual details live on internal child nodes, teleported content, or Naive UI theme tokens instead of the exposed root element
32
34
- Current Naive UI-root components that need extra care are:
33
35
34
36
-`UIDropdown` → `NPopover`
@@ -42,12 +44,14 @@
42
44
-`UIRadio` → `NRadio`
43
45
-`UIRadioGroup` → `NRadioGroup`
44
46
-`UIForm` → `NForm`
47
+
-`UITextInput` → `NInput`
48
+
-`UINumberInput` → `NInputNumber`
45
49
-`UITimeline` → `NTimeline`
46
50
-`UITimelineItem` → `NTimelineItem`
47
51
48
-
- For all UI components, an external `class` can still be passed, but do not rely on it for styling-critical behavior. Prefer an outer layout wrapper, explicit component props, or a dedicated API extension when finer control is needed
49
-
- For the Naive UI-root components listed above, root-level visual overrides from an external`class` are especially hard to predict. Prefer an outer layout wrapperor Naive UI theme overrides instead of assuming the component root will restyle reliably
50
-
-`UIDivider`, `UIFormItem`, `UILoading`, `UITextInput`, and `UINumberInput` also use Naive UI internally, but they expose a wrapper DOM root; external `class` lands on that wrapper instead of the inner Naive UI control
52
+
- For all UI components, an external `class` can still be passed, but prefer explicit component props or a dedicated API extension for styling-critical behavior
53
+
- For the Naive UI-root components listed above, simple root-level overrides are generally workable because the `components` layer sits above `naive-ui`, but do not assume every visual change should come from the root`class`. For deeper visual changes, prefer an outer layout wrapper, explicit props, or Naive UI theme overrides
54
+
-`UIDivider`, `UIFormItem`, and `UILoading` also use Naive UI internally, but they expose a wrapper DOM root; external `class` lands on that wrapper instead of the inner Naive UI control
51
55
- This is primarily a component authoring/maintenance concern. The long-term goal is to keep these wrappers easy to consume so business code does not need to carry much Naive UI-specific styling knowledge
0 commit comments