Typography with Fonts output is invalid when auto-prefixing is off

[derekwsgray]

The README suggests (using standard format) that it can export both Fonts and Typography tokens, however the tree structure doesn't seem to be valid (by that I mean, using only style-dictionary transforms alone would not be enough, for web css)

It exports something like this:

{
  "myTheme": {
      "font": {
          "myFontA": {
              "type": "custom-fontStyle",
              "value": {
                  "fontSize": 42,
                  "textDecoration: ...  etc.
               },
               "fontSize": {
                  "type": "dimension",
                  "value": 42
               },
               ... the others
          }
      }
   }

Since myFontA has a type and a value key, the other siblings are not picked up as separate tokens and get ignored.

[lukasoppermann]

Hey, this is correct. Style dictionary does not support the w3c standard. You will need to create custom transformers for this. That is by design. I am assuming that once the w3c format is finalized and releases style dictionary will implement it as well.

[derekwsgray]

Now I'm getting confused... So when your plugin outputs "Standard" format.. it's not really the w3c draft standard.

According to StyleDictionary format what you output should be supported: https://amzn.github.io/style-dictionary/#/tokens?id=design-tokens so I'm not sure actually why the individual "fontSize" gets skipped by StyleDictionary... In StyleDictionary format, a group can also be a token itself, while having child tokens.

But according to the Standard, what the plugin outputs above is not valid. In the spec, the way I'm reading it at least, you cannot mix Groups with Tokens: https://tr.designtokens.org/format/#additional-group-properties

Where am I going wrong?

[lukasoppermann]

So what is outputted in the Original (outdated) mode, should be supported by style dictionary.

What is output in standard mode is not. It is by now also not according the standard anymore, as they updated. I will hopefully in the next days/weeks have time to refactor standard to align with the specs.

[lukasoppermann]

What you have written there in the code is not valid. However I can not reproduce it. For me it is a normal composite token: https://tr.designtokens.org/format/#composite-design-token

[derekwsgray]

I figured out why you're not seeing it. You have to turn OFF auto prefixing.

So I'm not sure the best way to avoid generating invalid standard format... we definitely don't want to turn on the prefixing because we want <product>-<theme>- to come first in the token name.

[derekwsgray]

I've updated the title to reflect the special case. Should be re-opened.