Add a way to Extend the properties allowed in theme.json schema! (It is currently not possible to use them)

[ghost]

What problem does this address?

Hello!

I appreciate very much -> how I am able to extend spacing units in Theme.json, for it to allow us to work with the vast possibilities regarding height and width units... We can build the layout we need, because in fact there are 50 spacing units out there, many more than the ones that come pre-installed by default (px, em, rem...). And even very recent, new, modern Spacing Units are recognized, output and even recognized by the Editor, as long as they have been defined in Theme.json. For example:

  "spacing": {
  	"units": [
  		"%",
  		"rem",
  		"vh",
  		"vw",
  		"vmin"
  	]
  },

Colors are also somewhat extensible in Theme.json, because although the new color spaces LAB and LCH are not possible to be used in the color components, they can be registered in Theme.json and they are going to be output correctly.

Although Theme.json is being somewhat extensible for Spacing Units and Color Spaces, at the same time, the system is very limited, it is a pain point, in how theme.json deals with properties.

Take for example the Logical Properties (margin-block, margin-inline, inset-block, inset-inline, padding-block, padding-inline, border-block, border-inline). These are fantastic properties that are already available in 97% of browsers, and therefore we use them to craft and deliver our projects to clients today.
And they have direct Physical equivalents: margin, padding, top/left/right/bottom, border.

How to work with them in Gutenberg, would you ask? Is it just a matter of writing them in theme.json.....? Yeah, but there is no place for it yet.

Now I need to be clear: I am not requesting a whole new set of components specific for Logical properties.

I just expected that the system would, at least, recognize other CSS properties...
OR a way for us to extend Theme.json, to make the system recognize MORE properties if we need.
A simple improvement below: a section in theme.json where I can declare that: hey, I am going to work with margin-blocks and margin-inlines, instead of the old "physical margins". For example, it could be as easy as writing this in theme.json:

"settings": {

  "customProperties": [
  	"margin-block-start",
  	"margin-block-end",
  	"margin-inline-start",
  	"margin-inline-end",
  ]

}

OR IT COULD BE:

"settings": {
"spacing": {
"units": [
"%",
"rem",
"vh",
"vw",
"vmin"
]
"properties": [
"logical"
]
}
}

Logical margins would at least be recognized in Theme.json, when I set them to blocks:

  "elements": {
  	"button": {
  		"spacing": {
  			"margin": {
  				"block-end": "0.5rem",
  				"inline-start": "var(--wp--preset--spacing--40)",
  				"inline-end": "var(--wp--preset--spacing--40)",
  				"block-start": "0.5rem"
  			}
  		}
  	}
  }

Currently this is forbidden. Theme.json doesn't recognize these properties. Theme.json recognizes custom Spacing Units and new Color Spaces, but not "custom" properties, and there is no way to extend this small set of default properties.

Any improvement to this would be appreciated in a first moment.

I understand that, at a later time, you could then develop a way to map these custom properties to current properties, in order for them to be used in the Editor instead of the current ones.
Take for example, the need of logical margins instead of physical margins. A simple example:

"settings": {
"spacing": {
"margins": [
"physical" (default, what it currently is)
"logical"
]
}
}

If I set Logical Margins in Theme.json, the system would be smart enough to map these properties where "margins" are to be set by components in the Editor. But we don't need that in a first moment, just the need to be able to use many more properties, and some of them may never be common to be added to this project, so this feature request come in time...

What is your proposed solution?

[ghost]

I am going to ping some people that may be interested in this issue, because they have worked recently on things related to Theme.json definitions, and its related engines...
@carolinan
@t-hamano
@andrewserong
@ramonjd
@aaronrobertshaw
@jameskoster
@tellthemachines
@mtias
Please consider this issue on your development. Ah I have searched for similar issues and this seems like a new issue. 🙏

[ghost]

(( Ah if the current issue is not going to be solved soon, in the meantime please allow more common properties to be written/recognized in theme.json.
I remember a few... (logical properties), text-shadow, z-index, filter, box-sizing, animation, position (more than sticky), direction, mask, the new scroll properties, snap properties, grid properties, writing-mode, display+visibility, writing-mode.
PS: ideally all CSS properties should be allowed to be written/recognized in theme.json, even if they are never going to be used in default components nor receive a special treatment in the style engine. ))
Modern developments in CSS... please come to theme.json one way or another! #GutenbergNotLateToTheParty