Expanding the customization of Playground display via blueprints

[0aveRyan]

As I've looked at Playground in recent weeks, there are a few ideas that are relatively feasible technically, but more come down to product decisions.

The existing playground has hardcoded CSS (with some notes about replacing 😎 ). I've wondered whether...

• Background behind the browser could accept hex or background-image() properties sourced from the blueprint for display behind the browser mode. Hex might be a sensible starting point as background-image() with SVG, etc could get a tiny bit trickier.
• Browser button colors - Generally noting these are a tad small touch target-wise.
• Browser application chrome colors - It'd be neat if the browser chrome inherited the user's color scheme.
• Potentially the fonts used for the address bar, colors and fonts for menus and modals.
• The optional overlay used prior to running a playground - The "Run Playground" button and display of the modal colors, type.

The reading of the blueprint could write the necessary CSS variables, and on WP.org for plugins the endpoint used to deliver blueprints could allow-list property values, limit length, etc. I don't think every possible value should get a custom property, but I think 5-10 intentional properties could help make Playground even-more chameleon and flexible in use.

Deciding the appropriate boundaries, where Playground could be customized in display even further via Blueprint properties (if at all) and where someone really should customize and consume it for something unique I think is what I'm hoping to get at.

[adamziel]

@0aveRyan would the ability to provide a custom stylesheet be helpful? I'm worried about exposing an API consisting of specific CSS variables as it will be difficult to maintain and i anticipate a lot of requests to expose one more setting.

[0aveRyan]

I do think a custom stylesheet would be helpful! And I hear the concern of API creep ♾️ .

I think the custom stylesheet is the quick, "ultimate" unlock. But the downside is it will more tightly restrict changes that can be made to the markup of Playground as customizers keep up with breaking changes and, of course... specificity 😇 .

I guess I said "it could do X" and didn't really articulate, "... why do X?":

• Consistent branding across multiple blueprint paths, products, etc, when providing demos.
• Change the text of the "Run Playground" button. If multiple playgrounds are blocks in a post, that could be helpful.
• If you have a ton of Playground's open hitting a variety of blueprints, this color change could be a visual aid to many sighted users similar to how many WordPress users will use one color scheme in Production, another in Staging, another on Local.

So maybe the middle ground is providing a few very-specific attributes that are known to be safe to adopt, "background color" could even be a user-facing or query parameter option. Then, if you want to get fancy, and accept the ongoing maintenance burden and risks, you can use a CSS file knowing the responsibility has entirely shifted to you.

[0aveRyan]

Kinda just hit me like a ton of bricks... but we do have software that generates skinned HTML from a JSON format 😇 Maybe in future iterations (long-term) Playground frontend should use the WP default theme markup, stylesheet and CSS variables with a Playground block injected that does the browser chrome/features? Make the expand/collapse, menus and modals all interactivity API-driven. Still distill-down to fully-static, same-name HTML file... just generated from WordPress. Provide a limited subset of theme.json, etc. (Then a remote CSS file of variables could be much safer and robust!)

[adamziel]

but we do have software that generates skinned HTML from a JSON format 😇

That's definitely interesting! Do you have any specific software in mind?