Approach to Foundational Block Styling

Overview

To make our block plugins as compatible as possible across as many themes as possible and upcoming wordpress releases, styling for these blocks should be consistent with best practices observed in core blocks. Outlined below are some of the considerations to make when developing the foundational of base styles of a given block.

style.scss vs editor.scss

  • style.scss is the base stylesheet that’s pulled into the front end output of the block as well as the editor on the content management side.
  • editor.scss A separate block-editor specific stylesheet is needed for block elements present only in the block-editor. This is because in the editor a block will have additional states, form fields, or markup differences that assist in making the block editable. Therefore additional styles might need to be provided on the editor side which are unnecessary to the published output.

BU Base Styles and Custom CSS Properties

BU Base Styles includes a standardized set of CSS variables for use across plugins and themes, as well as some Sass variables/mixins. The names and naming convention used can be found at https://github.com/bu-ist/bu-base/tree/main/styles

Block base styling requirements

Many generic content blocks we build will presumably be used in a myriad of configurations and nesting combinations. With that said base styling will need to be extensively overridable and minimal. As such the following guidelines are meant to ensure compatibility with child themes and any styles they may tack on to augment the presentation and behaviors of a given block.

  • Assume the block might not be used with Responsive Framework. there may be other theme frameworks in the future.
  • Don’t assume essential styles will be inherited from the theme (box-sizing, font-size: 16px, and other common reset/normalize styles). If those are needed for the default appearance of the block they should be included in the block’s styles in the plugin.
  • Test the block against an empty theme without styles and ensure the design of the block is functional and how we intend. Then move on to testing against our theme frameworks.
  • Keep base styles for the block lightly opinionated:
    • Limit color properties in the plugin styles
    • Limit font family properties in the plugin styles
    • Limit styling to the following properties if possible
      • display
      • flex
      • font-sizes
      • font-weight
      • line height
      • margin
      • opacity
      • overflow
      • padding
      • position
      • width (percentage)
    • Do not assume the width of the content container
    • Don’t rely on breakpoint media queries if possible, as breakpoint have the potential to vary between themes.
    • Container Queries may be a safer & better option.
  • Make use of foundational CSS custom properties introduced in BU Base and customized in the child theme so as to reduce the need of override styles from the block via CSS selectors and increased specificity in a child theme.
  • Generally it would be best practice to leave block margins (vertical spacing relative to other blocks) as well as left right wide and full alignment sizing and spacing to be determined by the theme.