Add top-level properties to theme.json for author data

[unscripted]

What problem does this address?

As style variations gain popularity, developers have increased their activity in sharing custom block style variations, color palettes, sections, and typography styles. By adding new properties, theme developers can add references to their WordPress profile, theme and repository or theme documentation.

This data could also be used in future Style Directories or Style Libraries to provide author credit.

What is your proposed solution?

I propose adding the following properties to the schema for theme.json.

• author
• authorURI
• styleURI

[karmatosed]

You know, I kind of like this. If this could be added I can see many others liking this also. Thank you for raising it up.

[t-hamano]

Thanks for the suggestion.

• What is the current purpose of the fields you want to add to theme.json?
• How is it different from the metadata defined in style.css?
• What is styleURI and what is it used for?
• What would be a style directory/library? Has it been suggested somewhere?

[carolinan]

I like the idea of making it easier to share and identify styles.
This solves a problem, which is that we can not use regular comments in the JSON file to add this type of data. (if we want the file to be valid..).
And a repository of styles does not need to be an internal WordPress project to be useful.

But thinking of this more, I thought there was an intention to move the style.css metadata to the theme.json configuration file.
This was something that was discussed in the early days of block themes.

So this needs to be approached carefully in a way that is future proof.

---

Since the purpose is sharing the style, it probably also needs a version.

[unscripted]

@carolinan I also love the idea of adding a version field.

@t-hamano Here are responses to your questions.

• What is the current purpose of the fields you want to add to theme.json?

From the agency side, we create many sites and often reuse different JSON files. This could be theme.json or different style variations, as outlined below. We've started a directory of these, but as they get copied into client themes, we can easily lose track of which one it originated from.

/styles
    /block
    /color
    /section
    /theme
    /typography

• How is it different from the metadata defined in style.css?

Because these are stored in a repo or shared online, they aren't associated with the theme until a developer copies the file as needed.

• What is styleURI and what is it used for?

I equate the styleURI to the Theme URI in a theme's style.css file.

This field would link to the file within a repo. In the future, if w.org implements a styles directory, this field could also link to the directory.

• What would be a style directory/library? Has it been suggested somewhere?

I'm not sure a directory has been suggested in the issues, but I've had conversations with other agencies doing similar things in private and public repos. Like the pattern library, I see a future where users can submit style variations for specific blocks, color palettes, and typography pairings.

[t-hamano]

Thanks for the reply.

I understand the purpose, but I think it's better to avoid adding fields ahead of something that's not yet determined, like a style directory or style library. Also, the version field is already reserved.

My ideas are:

1. Change additionalProperties to true at the top level, so that we can add any field we want.
2. Add a field like meta at the top level so that we can add fields within it.
3. Nothing for now. The code editor will report an error, but we're free to add any field we want.