• 
      

    Add the base foundation for the Ink LessCSS codebase.

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

    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.

    Summary ID
    Add the base foundation for the Ink LessCSS codebase.
    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: ```css key: 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.
    e0aeb471dd5b75859efdd86cd81e04840457461b
    chipx86
    david
    1. Ship It!
    2. 
        
    maubin
    1. Ship It!
    2. 
        
    chipx86
    Review request changed
    Status:
    Completed