Add the base foundation for the Ink LessCSS codebase.

Review Request #13583 — Created Feb. 27, 2024 and submitted — Latest diff uploaded

Information

Ink
master

Reviewers

This introduces the beginnings of the LessCSS codebase, in preparation
for the default theme and the first components.

Ink's LessCSS code is based on our CardStock experiments, which builds
components in three layers:

  1. Schema layer: Schemas are LessCSS mixins that define the
    structure of a component, but not the rules.

    They provide all the CSS selectors that comprise a component and
    offer named rulesets that the caller can provide in order to fill out
    those selectors.

    Schemas are used to populate rules for a component and also to
    specialize rules for a component without being affected when any part
    of the underlying structure changes.

  2. Component layer: These are mixins that define the components'
    basic styles and layout.

    They take in a name for the component and some other state and then
    make use of a schema to fill out the styling.

    The component layer itself does not output CSS. Instead, its mixins
    can be invoked to output CSS with a specified component name and any
    relevant arguments. This allows a component to specialized under
    another name, which is useful if one needs a very custom variant of a
    button but doesn't want to copy/paste a bunch of styling or mix in
    the original classes.

  3. Theme layer: The theme injects the CSS for the components, using
    the component mixins, and adds any CSS variables that fulfill the
    contract of the component.

    By injecting at this layer, we minimize the amount of CSS that
    ultimately needs to be generated, helping keep the resulting
    stylesheet tidy and making it easier to specialize aspects of it.

    It's also responsible for defining any units, palettes, and other
    design tokens that are used by components.

This change contains the support for defining schemas and components,
and the base support for defining themes, but otherwise results in an
empty stylesheet. Upcoming changes will introduce actual styles.

The base theme support does contain some very useful CSS variables that
act as feature flags. These include --if-dark, --if-dark-only,
--if-light, and --if-high-contrast, and are used like:

property: var(--if-dark, dark-value)
          var(--if-light, light-value)
          var(--if-high-contrast, high-contrast-value);

Depending on the theme used (system or an explicit light, dark, or
high-contrast), the appropriate flag will fall back to the value that
accompanies the flag, and the others will convert to empty strings. This
is an effective way of defining switches for styles, and will be used
throughout the upcoming default theme.

Been working extensively with this foundation to draft a half dozen
components and a base theme we can use in Review Board. All provided
functionality has been used.

Commits

Files