Why do utility class outputs for 'dimension' not include margin/padding-block variations?

[geebru]

Hey there! Just diving into Terrazzo and the DTCG spec in general and the utility class output is super enticing (as I currently argue about Tailwind use from a contractor).

I did have primary question and then a less important question:

1. In the list of compiled utility classes for dimension margin|padding-inline-* are accounted for, but not margin|padding-block-*. Is there a technical reason behind this? While our app doesn't necessarily rely on these, I found it odd that logical properties seemed "half" included.
2. Is there a world in which we have some control over the utility class naming to potentially avoid conflicts with other systems? Even something as simple as a prefix option?

Thanks for all the work here - it's been a blast learning this stuff with the help of the communal work around tokens ✨

[drwpow-figma]

1. Probably just an oversight! If you have the time to open a quick bug ticket we can fix that 🙂
2. Possibly. Do you have systems in mind that would conflict (just so we know a prefix is the right solution)? The general idea with utility classes is predictability and brevity, so would love to learn more about real or potential conflicts to try and still solve for both

[geebru]

1. I should have time this week, yeah!
2. Nothing immediate came to mind (i.e., I didn't see the output and think "dang that conflicts with system name"), it was more so that I like prefixing "libraries" we send off to dev just to avoid any conflicts with stuff they may have made, existing systems, etc. I don't have a real example of a conflict, which is why I framed it more like a question than a request. I think brevity wins here, I agree, but being able to put 1-2 characters up front would resolve any potential collisions forever in theory.

EDIT: But I hear you, ideally the utility library is low level, predictable, etc. so I can see opening the door to class customization being a can of worms.