Stroke style type feedback

[c1rrus]

Is the stroke style composite type fit for purpose? Does it need more sub-values (e.g. equivalents to SVG's stroke-linejoin, stroke-miterlimit and stroke-dashoffset attributes)?

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

[TravisSpomer]

One additional property that could be useful is stroke alignment: whether it draws inside the edge of the object on top of the fill, or outside of the object.

Figma	CSS	WinUI
Inner	background-clip: border-box	BackgroundSizing="OuterBorderEdge"
Outer	background-clip: padding-box	BackgroundSizing="InnerBorderEdge"

[drwpow]

I think there’s a unique problem with the string | object polymorphism here which doesn’t exist on other tokens.

font, for example, may be a string | string[]. But if string is passed, you could normalize that by simply placing that in an array, and it would be equivalent (in other words, you can “expand” one type into another). This form of polymorphism is easy to deal with because they aren’t necessarily distinct types; one is simply a shorthand for another.

I would expect for strokeStyle the string value should be “expandable” to the object value, but that doesn’t seem to be the case. If I’m reading this right, the object value would always be the dashed style? If so, I’d suggest the following:

{
  "alert-border-style": {
    "$type": "strokeStyle",
    "$value": {
      "style": "dashed",
      "dashArray": ["0.5rem", "0.25rem"],
      "lineCap": "round"
    }
  }
}

Having a "style" that corresponds to the string value (feel free to bikeshed the name; I’m not opinionated about “style”) allows the two types to be interchangeable. So "$value": "dashed" and "$value": { "style": "dashed" } are two ways to write the same thing.

Of course, that begs the question of whether or not other styles ("$value": { "style": "solid" }) also have attributes that could be set. I’d probably lean toward simply letting the implementor decide which additional attributes apply and which don’t (e.g. say dashArray was set on a solid stroke and the tool author decided to ignore that attribute without throwing an error). But I could realistically see a core set of attributes applying to multiple styles and not being mutually-exclusive to one.

---

Alternate suggestion: if each different stroke type needs different values and there is little to no overlap, (i.e. there are “sub-types,”) I’d argue those are actually not the same type and need to be split apart.

In that instance, splitting apart one stroke into multiple e.g. $type: "solidStroke", $type: "dashedStroke", etc., would make it easier both on the author and the tool implementor than dealing with complex polymorphic types where one part of $value has implications on the rest of the shape (hidden types).

[PavelLaptev]

I think if we're coping dashArray or lineCap. Because we're also referring here to SVG. There should also be other values like:

• lineJoin: "round" | "bevel" | "miter"
• miterLimit: number
• dashOffset: number