Global styling for tags (links, headers, paragraphs)

[johnsicili]

Need to have a way to apply a default/global styles for the various HTML tags such as H1-H6, paragraphs, and links.

Spoke to @kof and it's something that is currently in the works. Noting here for reference.

BTW, idk if it's just me, but I find Webflow's implementation to be kinda annoying. I think especially when I'm setting my style guide I forget to select "All H1s" and accidentally create a new class. Could be an opportunity to improve it.

[Erudition]

Could the design tokens just be CSS selectors?
Like all the normal tokens like blue-bg and big-shadow tokens are displayed as .blue-bg and .big-shadow to distinguish, and then footer and iframe would be tokens in the list for those respective elements (unless those styles are undefined), automatically and non-removable.
This even maps better for those coming from designing with just CSS.
It also naturally introduces support for styling custom html tags, and maybe even attributes for semantics and accessibility ([checked], [hidden], [disabled], etc.)

[Erudition]

classes don't compose well due to specificity issues

Interesting. I believe you, but, is there an article somewhere reputable where I can read more about this?
The concept of "utility" or "atomic" classes was the whole point of e.g. Tailwind, and I haven't seen any specificity issues (and Webstudio already does the "order them in terms of precedence" thing). The classes are constructed specifically for composability.

https://shadowsmith.com/thoughts/tailwind-css-utility-classes-the-ultimate-electrons-for-atomic-design

I've read the Webstudio blog post about Tokens vs. Classes, but I didn't see how they were fundamentally different from utility classes so I though they were synonyms (the arguments presented were regarding traditional use of Classes, assuming "combo classes" was the typical solution to composing). Perhaps another blog post some day about "Design Tokens v. Utility Classes"? 😃

[kof]

Atomic classes as a rendering method is what we most likely will use, but forcing users to use atomic for reusing styles is a different story. With tokens user can decide what they want.

[kof]

I didn't see how they were fundamentally different from utility classes

I think the article eplxains that a token can have multiple properties defined on it, while atomic class can only have one property.

[kof]

Tokens are really just like css rules without selectors mess.

[Erudition]

I think the article eplxains that a token can have multiple properties defined on it, while atomic class can only have one property.

Hmm, I don't see that mentioned, only "Atomize your styles, or don’t", which is true of using plain classes (no need to force user classes to be atomic, only composable). An atomic class can have multiple properties, see Tailwind's transition class for example (3 properties, 1 job). But composable classes can of course accomplish multiple jobs as well.

Tokens are really just like css rules without selectors mess.

I think I get it but... what's the 'selectors mess' when it comes to using exclusively classes? Perhaps the article could give an explanation on that :) The tokens spec is the only reading material I could find

[dianepettipas]

I just wanted to let you know that if you are in the editor and go to "Marketplace" there's only one thing there, but if you open that project, and then clone your own copy so you can edit it - there's a whole stylesheet you can use with the Token names set that then act as global settings as soon as you assign them to an element.

Just make sure you select the token name (turns blue) before you edit it so that it applies to the token, not just the local instance. It also contains a bunch of prebuilt wireframe sections you can use to kick off your library.

I've cloned it a few times, I'm setting each copy up with my favorite font combos so all I have to do is make a copy, change logos and colors and I'm off!