-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be explicit about whether or not empty groups are allowed #235
Comments
Empty groups can be placeholders, I've used one as an alias for the default
set with no modification, also for planned future updates. Wouldn't want it
to throw an error.
…On Mon, 4 Mar 2024 at 22:27, James Nash ***@***.***> wrote:
Currently, the spec says nothing about whether or not groups can be empty
- i.e. not contain any tokens or nested groups.
I've always assumed they *can* be empty. But I recently discovered that
Cobalt UI has taken the opposite view
<terrazzoapp/terrazzo#206> and throws an error when
it encounters an empy group.
The spec doesn't say anything, so neither view is right or wrong.
I propose we take a stance on this and be explicit in the spec. Otherwise,
differing interpretations will lead to interoperability issues between
tools.
My vote would be to permit empty groups. While they may seem useless they
also do no harm. It's something that teams may legitimately encounter while
(re-)organising their tokens and working with work-in-progress DTCG files
(that's how I encountered that scenario anyway).
—
Reply to this email directly, view it on GitHub
<#235>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEKS36FEZC7WXDONU2GAPBTYWSRWLAVCNFSM6AAAAABEFR7TS2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGE3DOMZQHAYDANA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
@c1rrus Note that the Cobalt UI issue you've referenced has since been updated, they now do allow empty groups. |
I'm ok with empty groups as long as we specify that they can/should be ignored when parsing. |
Should empty token groups be kept when importing/exporting by token management tooling vendors like Tokens Studio, Zeroheight, Figma, or Knapsack? (my hunch is yes) When exporting to other formats (say, CSS), then it's probably up to the tool to do what they think is the best decision based on the language. |
Tools could simply implement empty group warning, just like CSS linters warns you about "Do not use empty rulesets". |
Currently, the spec says nothing about whether or not groups can be empty - i.e. not contain any tokens or nested groups.
I've always assumed they can be empty. But I recently discovered that Cobalt UI has taken the opposite view and throws an error when it encounters an empy group.
The spec doesn't say anything, so neither view is right or wrong.
I propose we take a stance on this and be explicit in the spec. Otherwise, differing interpretations will lead to interoperability issues between tools.
My vote would be to permit empty groups. While they may seem useless they also do no harm. It's something that teams may legitimately encounter while (re-)organising their tokens and working with work-in-progress DTCG files (that's how I encountered that scenario anyway).
The text was updated successfully, but these errors were encountered: