.. _usage: .. _using-the-viewhelper: ==================== Using the ViewHelper ==================== Use semantic manifest keys in the class attribute. The ViewHelper escapes its output for use in HTML attributes. For source organization, token naming, themes and CSS boundaries, see :ref:`stylex-authoring`. .. code-block:: html
Save
You can pass a Fluid array instead of a comma-separated string: .. code-block:: html
Save
Conditional styles ================== The ``when`` argument maps a template variable name to a style key. The ViewHelper adds every key whose condition resolves to a non-empty value. .. code-block:: html {page.title} If none of the conditions match, ``else`` adds its fallback key or keys: .. code-block:: html {item.label} The service can resolve a dotted variable path, but Fluid inline dictionary syntax may reject a dotted condition key. Assign a nested value to an ``f:variable`` first, as in the preceding example. Tag syntax ========== The same ViewHelper also supports tag syntax: .. code-block:: html How classes are merged ====================== Style keys are processed left to right. If style entries contain ``properties`` maps, a later style key replaces the class for an opaque conflict identifier used by an earlier key. Null values remove an earlier winner. This mirrors the last-key-wins behaviour expected when composing StyleX styles. For the manifest in :ref:`the-manifest`, this call produces ``x-root x-primary`` rather than both color classes: .. code-block:: html When a manifest entry only has ``className``, the service keeps its individual classes and removes duplicates. It cannot infer which CSS properties they represent. Generate property maps whenever the build tooling can provide them. Complete recipes contain finished class lists. Select one recipe for each component slot; combining recipes only concatenates and deduplicates classes. Dynamic functions that return runtime CSS custom-property values are outside this class-only API.