Justin Tadlock

You have gotten me on a bit of a rant, and much of this is just me “thinking out loud.” It’s a tough problem to solve. Sorry for the wall of text.

If you figure out a way to make the class and property names not be awful with negative values and hyphens, it’d be less of an issue. However, I must admit that seeing something like -3 for a font size feels confusing to me in comparison to 2-xs.

I also think this method would be confusing when comparing it to other scales. Padding, margin, and gap scales starting at 0 literally mean 0 (or, they should in my mind).

The alternative of just starting a 0 and going up also feels odd because, you know, when do you ever need font sizes on the lower end of that range? (Actually, I know a few use cases for font-size: 0, but those are one-offs.)

1) Does there need to be individual margin/padding/gap values or could a single scale of spacing units work?

I would build it as a single scale. Maybe some folks work differently, but I couldn’t imagine splitting these up in my work. Of course, I always favor allowing for devs to extend this however they want.

2) What’s the right number of values on a spacing scale(s) that all themes should try to support and how do themes support more than that number?

That is a tough question to answer without folks just stepping up and saying, “Here’s what I do.” So, here’s the actual spacing used in my last project. However, I have went higher. Admittedly, I have relied on the Spacer block for larger spacing because I can overrule it for smaller screen sizes.

You might notice that I start skipping numbers after a bit because I find those “in-between” points less and less useful as the scale goes up. They are great for the small spacing, but usually not so much when growing.

Longer term, I plan on mixing in minmax() to make the larger values a bit more responsive (probably starting at 12):

"base": {
        "spacing": "0.25rem"
},
"spacing": {
        "0": "0",
        "1": "calc( var( --wp--custom--base--spacing ) * 1 )",
        "2": "calc( var( --wp--custom--base--spacing ) * 2 )",
        "3": "calc( var( --wp--custom--base--spacing ) * 3 )",
        "4": "calc( var( --wp--custom--base--spacing ) * 4 )",
        "5": "calc( var( --wp--custom--base--spacing ) * 5 )",
        "6": "calc( var( --wp--custom--base--spacing ) * 6 )",
        "8": "calc( var( --wp--custom--base--spacing ) * 8 )",
        "12": "calc( var( --wp--custom--base--spacing ) * 12 )",
        "16": "calc( var( --wp--custom--base--spacing ) * 16 )",
        "global": "calc( var( --wp--custom--base--spacing ) * 8 )",
        "px": "1px"
}

I add a specific global value there so that I can easily change that in one spot. And, I add in a px option for some edge cases where I just need a 1px.

---

At the other end of all this, even if we all agree to some standard naming system, there is potential for monumental differences between implementations. For example, imagine my theme defining --wp--preset--margin-1 to 0.25rem and another theme defining that as 2rem with an ever-increasing scale. It could get out of hand when switching themes.

So, even with a naming system in place, it does not quite go far enough. An agreed-upon implementation would be even tougher. That’s one of the key reasons I wanted WordPress to have a full CSS framework of its own. It would define that standard implementation. Crazy deviations from it would be on the shoulders of the theme author.

Name *

Email *

Website:

Topic Title (Maximum Length: 80):

Forum:
— No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor