No way to target specific sidebar in widgets editor

[desrosj]

What problem does this address?

There's currently no way for a theme developer to target a specific sidebar to provide different CSS within the new widgets editor. This makes it near impossible to match the previews seen in the widget editor with the front end experience.

Use case: A theme with a sidebar displayed differently than the content area. At the most extreme level, this happens with different background colors. Two default themes that contain sidebars with different background colors are Twenty Twenty and Twenty Thirteen.

What is your proposed solution?

Short term, it would be great to have an ID or class matching the sidebar's ID so that theme developers could provide and target the appropriate CSS selectors.

Longer term, allowing a theme.json file to contain specific color, type, and behavior settings on a per-sidebar basis would be amazing.

[desrosj]

I've added this to the 5.8 must haves for discussion. I personally feel that there should be some basic way to accomplish this. The beauty of the block editor is that the editing experience very closely matches what is seen on the front end. We should enable that in theme developers for the widget editor.

[youknowriad]

Thanks for opening the issue, this is actually one of the reason I was not sure about adding editor_styles loading to the widget screen at all, these editor styles are optimized in themes for the post editor and sidebars/widget areas can be anything and can have different styling than the canvas. So sticking with a generic design (like the existing widgets screen) would have made sense to me.

Now that we have basic editor styles there, it's legitimate to ask this question though. I'd be ok to have a classname or something like that. I'm less tempted to use theme.json here, at least without taking into consideration FSE themes and contextual styling there, how can we target template parts there... and since the widgets screen is a migration path, I'm wondering whether it makes sense to have an API there instead of just encouraging folks to migrate.

It's though very short to have a new API/feature for 5.8, and since the classic widget screen doesn't have any implementation of editor styles, I'm thinking this might be better off 5.8.

[desrosj]

since the widgets screen is a migration path, I'm wondering whether it makes sense to have an API there instead of just encouraging folks to migrate.

The fact that this is a migration path is a good point. If I'm understanding the suggestion right, an API would allow theme developers to make one change, and adjustments to how the API work could be made by the team going forward?

It's though very short to have a new API/feature for 5.8, and since the classic widget screen doesn't have any implementation of editor styles, I'm thinking this might be better off 5.8.

I think I would be OK with this stance if we prioritize solving this in the short term.

But, I did dive in a bit, and it seems like a class or ID could be added here to accomplish this for 5.8 if it's decided to.

[youknowriad]

The fact that this is a migration path is a good point. If I'm understanding the suggestion right, an API would allow theme developers to make one change, and adjustments to how the API work could be made by the team going forward?

Not sure I understand here. My point was that since the widgets screen is a migration path for themes towards FSE themes, we should invest into making new APIs support it and focus more on FSE themes.

But, I did dive in a bit, and it seems like a class or ID could be added here to accomplish this for 5.8 if it's decided to.

I'll defer to the widgets screen team here but I'm not against a small class addition there yeah

[webmandesign]

Hi guys,

If theme styles are applied on new widgets editor screen, then I suggest adding a class instead of an ID attribute as ID might cause collisions.

Indeed, sidebars can be displayed in different ways in a theme, but as a theme author I hope I could at least apply proper colors and spacing in editor screen to match front-end.

[talldan]

There is already a class argument already passed to register_sidebar, so it could be possible to apply that in the editor:
https://developer.wordpress.org/reference/functions/register_sidebar/

But I would be concerned that it might cause some unusual styles if it were applied to editor content. Also checking recent bundled themes, this seems unused, I guess the themes prefer to add a classname directly in the html instead.

It does feel quite late to apply this kind of solution in 5.8 without adequate testing. I think we could try it in the plugin first, and then potentially roll out in 5.8.x if it's a small enough change and there's good results from testing.

An alternative idea could be to generate a classname based on the slug/id of the sidebar, e.g. is-${ id }-widget-area, and then themes could iteratively apply styles.

[webmandesign]

In my original issue report I suggested using a class generated from sidebar ID such as:

• wp-block-widget-area--sidebar-1 for sidebar with ID of sidebar-1
• wp-block-widget-area--footer for sidebar with ID of footer
• …and so on.

I think a class like that should not cause any potential issues.