↓Skip to main content
  1. Docs/
  2. Background Patterns/

Presentation

Look at the pretty patterns #

Where patterns are implemented #

How patterns are presented #

Each SVG has been modified to enable the pattern partial to perform the following adjustments:

  • fillColor: affects the fill attribute of any paths within the svg
  • strokeColor: affects the stroke attribute of any paths within the svg
  • stopColor: Some patterns contain a gradient that may be adjusted. This parameter adjusts that color.

Acceptable Color Values #

all color values may be provided as:

  • A tailwindcss style colorname-hue color pattern: [a-z0-9A-Z_]-(50,100-900,950) including theme-scoped-abstractions like “primary-50”, “secondary-400” and “neutral-950” note that only 50, and 950 are the only half values supported by tailwind natively.
  • A hex value rgb declaration: “^#[a-fA-F0-9]{6}$”

Opacity adjustments #

  • fillOpacity, stopOpacity, and strokeOpacity: these parameters respectively adjust the fill-opacity stop-opacity and stroke-opacity attributes for any paths within a given SVG pattern. The supported vales for svg fill-opacity stop-opacity and stroke-opacity attributes are a float value ranging from 0.0 to 1

Stroke width #

  • strokeWidth: The pattern partial supports the alteration of the stroke-width attribute of all paths in the given pattern. The acceptable value is a positive number (int, or float)

Contrast Polarity support #

(Light / Dark mode) I have extended the functionality and accessibility of these backgrond patterns by enabling the declaration of a contrast-polarity-specific variant of all the above attributes. This allows the contributor/site author more flexibility in displaying a more visually appealing version of the pattern in question aligned with the viewer’s active contrast-polarity setting.

  • This functionality is facilitated by the pattern-broker partial, which is a wrapper to the pattern partial which alters the SVG blueprints and renders the resultant svg into the webroot of the site..

    pattern-broker accepts a dict which contains the site theme, the current language if multilang, the specific pattern, and the pattern attributes to use in that context. it expects the attributes to be provided in the following structure: json "pattern": { "enable": true, "pattern_colors": [ { "dark": { "fillColor": "primary-950", "strokeColor": "secondary-200", "stopColor": "neutral-700", } }, { "light": { "fillColor": "primary-50", "strokeColor": "secondary-50", "stopColor": "neutral-50" } } ], "pattern_name": "pattern_file_name_without_extension_here", "pattern_options": { "fillOpacity": "0.1", "path": "svg/patterns", "strokeOpacity": "0.1", "strokeWidth": "2" } } It’s important to note that for the time being, dark and light are the only contexts pattern-broker currently supports, however there is an issue open to evaluate the usefulness of this construct for other use-cases, like, draft status, or unpublished, or expired content. These are keyed to align with tailwind-css’s dark/light mode concept by creating a dark and light key which may override the default attributes that would otherwise be fed to the pattern partial.

  • fill-color

  • fill-opacity

  • stop-color

  • stroke-color

  • stroke-opacity

  • stroke-width

The background pattern enablement knobs are values descending from the site param params.content_style.[specific page type, or default].pattern:

enable
bool - Whether or not to enable bg patterns

pattern_colors:

  • dark

    • fillColor
    • stopColor
    • strokeColor

  • light

    • fill color
    • stop color
    • stroke color

  • pattern_name

  • pattern options

    • fillOpacity:
    • path
    • strokeOpacity
    • strokeWidth

there is a default key

context specific logic #

Contributor profile page #

Contributor content list cards #

Relevant Partial
layouts/partials/cards/pages/article.html
This partial is USUALLY instantiated by the contributor’s profile partial. As such, it stands to reason we should be given relevant information from the calling resource.

so, first we eval the config blob we were handed for either background disablement, or enablement and a resource

if we were not told NOT to use a background, then we assume we should, but that we weren’t handed one.

  • look at page params.
  • look at site params

Pages #

any page may define the following params. If set, they should override what was read from site params.

patternEnable: true
patternName: "topography"
patternFillOpacity: 0.5
patternStrokeOpacity: 1
patternStrokeWidth: 1
patternStopOpacity: 0.1
patternDarkFillColor: primary-100
patternDarkStopColor: primary-100
patternDarkStrokeColor: primary-100
patternLightkFillColor: primary-100
patternLightStopColor: primary-100
patternLightStrokeColor: primary-100