Shadow type feedback

[c1rrus]

Is the shadow composite type fit for purpose? Does it need to support multiple shadows, as some tools and platforms do?

Please share your feedback, thoughts and ideas in this issue.

[drwpow]

I like it. That makes logical sense to me. My only request, personally, is that arrays of shadow objects are accepted (example). IMO layering shadows still counts as “one shadow” and they are difficult/unwieldy to combine as separate tokens (i.e. they aren’t reusable because they depend on the precise position of other shadows in the array)

[natemoo-re]

Totally agree with @drwpow that supporting arrays of shadow objects is critical for my use cases.

Is the idea that color tokens also encode an alpha value? Personally I would love to see an optional opacity or alpha value on the shadow object so that color tokens wouldn't need to be created for each opacity.

[WardMe]

I don't see an inset property on shadows? How would we define box vs inner shadows?

[TravisSpomer]

Yes, that appears to be an oversight. Seems like an inset property would be required.

[Chudesnov]

I would love to see an optional opacity or alpha value on the shadow object so that color tokens wouldn't need to be created for each opacity.

@natemoo-re maybe I'm overgeneralising, but to me it seems that a color part of a shadow is still a color token (even though it's "anonymous" and probably should never be referenced by anyone from the outside), it seems less then ideal to have separate definition mechanisms for the same types of tokens in different contexts.

Maybe, instead of that, sub-properties for composite tokens' $value should allow plain values as a shorthand but generally expect an anonymous token definition ({ $value, etc... }); then opacity/alpha/mixing transformation could be defined locally under that anonymous token.

Here's an example of what I mean (based on a different but similar spec we've been working on for some time at our company):

{
  "color": {
    "accent": {
      "$type": "color",
      "$value": "#000000"
    }
  },
  "shadow-token": {
    // most Web-compatible implementations would need support for multi-layered shadows,
    // so this might be "shadowLayer" instead
    "$type": "shadow",
    "$value": {
      "color": {
        // in our case it's "$value": {"$ref": "color.accent"} instead
        "$value": "{color.accent}", 
        "$transforms": [
          // based on https://www.w3.org/TR/css-color-5/#relative-RGB
          { "$type": "rgb", args: [{"$name": "alpha", "$value": "88"}] } 
        ]
      },
      "offsetX": "0.5rem",
      "offsetY": "0.5rem",
      "blur": "1.5rem",
      "spread": "0rem"
    }
  }
}

[CITguy]

Akin to #100 (comment) and #100 (comment), a boolean inset property is required to clarify whether a shadow should be internal vs external.

Figma provides two ways to define shadows (Drop Shadow and Inner Shadow):

Inner Shadow corresponds to the use of the inset keyword for a CSS box-shadow property.

The equivalent tokens for the above shadows should be as follows:

{
  "dropShadow": {
    "$type": "shadow",
    "$value": {
      "offsetX": "0px",
      "offsetY": "0px",
      "blur": "2px",
      "spread": "4px",
      "color": "#cccccc"
    }
  },
  "innerShadow": {
    "$type": "shadow",
    "$value": {
      "offsetX": "0px",
      "offsetY": "0px",
      "blur": "2px",
      "spread": "4px",
      "color": "#cccccc",
      "inner": true
    }
  }
}

Resolution

• dropShadow.$value.inner should resolve to false, if not present

Caveats

1. Similar to the spread property, the inner property doesn't apply for CSS text-shadow.

[CITguy]

How would a CSS translation tool know if a $type: "shadow" token is a box-shadow or a text-shadow?

Flutter and CSS have different definitions for a shadow when applied in different contexts. I would assume that other environments would also have similar differentiation.

Text Shadow

• Relevant Token Properties:
  • offsetX (Dimension)
  • offsetY (Dimension)
  • blur (Dimension)
  • color (Color)
• Flutter: Shadow class
  • properties:
    • blurRadius
    • color
    • offset → Offset(dx, dy)
  • Stacked for use in TextStyle shadows config.
• CSS: text-shadow property
  • sub-properties:
    • offset-x
    • offset-y
    • blur-radius
    • color
  • (MDN) text-shadow
  • (W3C) CSS Text Decoration Module Level 3: Text Shadows

Box Shadow

• Relevant Token Properties:
  • offsetX (Dimension)
  • offsetY (Dimension)
  • blur (Dimension)
  • spread (Dimension)
  • color (Color)
  • inset (Boolean)
• Flutter: BoxShadow class
  • properties:
    • blurRadius
    • spreadRadius
    • color
    • offset → Offset(dx, dy)
    • blurStyle → [inner|normal|outer|solid]
• CSS: box-shadow property
  • sub-properties:
    • inset
    • offset-x
    • offset-y
    • blur-radius
    • spread-radius
    • color
  • (MDN) box-shadow
  • (W3C) CSS Backgrounds and Borders Module Level 3: Drop Shadows

[MatthiasDunker]

This might be connected to #134
Maybe composite tokens are too specific and might exclude specific coding environments.
Is it the task of tokens to take care of their usage?
Should token types contain assumed context or semantics?

[MatthiasDunker]

Another thought: Should the standardization of design tokens empower (to build custom design systems) or limit down (to follow a given approach)?
Just using primitive tokens leaves a lot of space for interpretation and thus causes a lot of work and vagueness for translation tools.
Narrowing it down to composite tokens helps avoiding disambiguation, but on the other hand assumes how tokens should be used. And we can’t foresee future frameworks, design systems, whatever (maybe we don’t have to, because this will be the standard ?!).

Is there something in between? Like a name-spaced type set?
like

{
  "dropShadow": {
    "$type": "@web/shadow",
    "$value": {
      "offsetX": "0px",
      "offsetY": "0px",
      "blur": "2px",
      "spread": "4px",
      "color": "#cccccc"
    }
  }
}

or even an offer of multiple types?
(thinking of multiple color spaces or ways of defining line-height (like in px, w/o unit or em....))

{
  "dropShadow1": [
    {
      "$type": "@web/shadow",
      "$value": {
        "offsetX": "0px",
        "offsetY": "0px",
        "blur": "2px",
        "spread": "4px",
        "color": "#cccccc"
      }
    },
    {
      "$type": "@flutter/shadow",
      "$value": {
        "blurRadius": 2,
        "spreadRadius": 4,
        "color": "#cccccc",
        "offset": [0, 0],
        "blurStyle": "normal"
      }
    }
  ]
}

Downside: this does not look like a standard, but like a collection of different platform definitions.

[CITguy]

My point was to show that the concept of a Text Shadow and Box Shadow (e.g., "drop shadow", "inner shadow", etc.) are present in multiple platforms. I was just providing examples of their implementation.