Vixen
dd8b0a81
csharp
public static class EditorStyles

The utility half of the editor's stylesheet, compiled at build time.

Read the guide page for this →

Remarks

There is no code here, and that is the feature. Theming/vixen.ui.vcss is the design tokens, every source file and every .vxml in this assembly is scanned for class names, and the sheet is generated into obj/ by Vixen.Ui.Styling.Utilities.targets before the compiler runs. What is left over is this: a name for the constant, so that the rest of the editor does not have to know that a generated type exists.

⚠ The build step is why this file is four lines rather than a hundred and thirty. Samples/14-Mmo/Mmo.Ui/Theme/MmoStyles.cs is what this looked like before it: embed the markup as resources, walk the manifest, run the scanner, run the generator, cache the answer — a startup bootstrap whose own remarks admitted it was standing in for a build step that had not been written. It has been written, and that sample is converted too, so nothing in the tree does it by hand any more.

⚠ The tokens are not a second palette, and the @theme block goes to some trouble to stay that way. Every colour in it is a var(--…) reference to a custom property EditorTheme already declares on the root — so bg-surface and a hand-written background: var(--surface) are the same declaration, the light/dark toggle moves both, and a user theme loaded through ThemeService moves both again. Copying the hex across would have produced two palettes that agreed until the day one of them was edited.

⚠ The utility layer wins every argument it has with EditorTheme, and it is worth knowing that it used to lose every one of them. Everything generated lands in @layer utilities; the hand-written sheet was unlayered, an unlayered rule beats every layer whatever the specificity, and so task-row { padding: 6px } beat p-3 without either of them saying !important. A utility could only take effect on a property no rule in EditorTheme already set for that element, which meant retro-fitting one onto existing chrome began by deleting a rule. The sheet is now @layer components, utilities comes after it, and a class written on an element does what somebody writing it plainly meant.

⚠ What that costs, since nothing is free: a chrome rule that genuinely must not be overridable by a class has to say so, and the way to say it is !important — which in a layered cascade is not the blunt instrument it is in an unlayered one, because importance reverses the layer order and an important components rule therefore beats an important utilities one. Nothing in the sheet needs it today.

A public wrapper over an internal generated type rather than a generated public type, because a public generated type is a public API baseline entry and a documentation page for a class whose entire content is a string constant — and because the name the editor says is then this assembly's to choose rather than the build step's.

Fields and properties (2)

  • public static string Utilities

    The utilities the editor's markup and code use, in @layer utilities.

  • public static int RuleCount

    How many utility rules the build emitted.

Used by (3)

  • EditorThemeVixen.Editor.Ui
  • SharedThemeTestsVixen.Editor.App.Tests
  • StylesheetTestsVixen.Editor.Ui.Tests