You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
List View > Custom CSS (at block level) > add css indicator / flag #75236
GB 20.5 introduced the nice Custom CSS Support for Individual Blocks
Now we have more ways to manage custom css (at global style level, or per block), for sure it's better for performance.
The consequence is to locate them "where can see where i've set a custom css, i cannot remember where", to update / delete it.
The custom css rules are now disseminated aside the standard centralization in the Style Manager
What is your proposed solution?
Add a 'css" badge in the list view, to rapidly identify what block has a custom css.
Just an example, but the design is not the best one
NB : it's perhaps not the core to provide a global overview within a single (admin) page.
A third part plugin can provide a more convenient way, exactly like the "Find my block" needs (find my block plugin https://wordpress.org/plugins/find-my-blocks/).
But having an indicator at List View level is a bare minimum (for a core level / just apply the 80% rule)
At this point, I feel like we should embrace the Notes tray as a linting tool. Here's how that would look like for hidden blocks:
It's screamingly obvious for surfacing things. Whether indicating CSS deserves this level of prominence, I don't know. The alternative would be an actual linting tab in the List view that showed errors, warnings, and notices, just like the JS does. I would like such a thing regardless.
My main point is, the existing UIs can't expand endlessly, so at some point we have to draw a line in the sand and say: it's time for a linting UI.
Noting that I closed #71168 in favour of consolidating with this issue.
I also want to connect some dots with instincts shared by @kedarjoyner in #81226, where there are similar concerns about surfacing block-specific customisations, in that case responsive edits. The discussion goes into linting tools, of which one variant has been shown on this issue, but it discusses another option of a "Lint panel". Possibly worth a look to see if it inspires some action on this one.
Activity
[-]List View > Custom CSS (block + global) > add css indicator / flag[/-][+]List View > Custom CSS (at block level) > add css indicator / flag[/+]Mamaduka commentedon Feb 5, 2026
I think similar "badges" have been requested for other features, but given limited space, we're trying to avoid introducing more.
cc @jasmussen, @t-hamano, I think we were all involved in a similar discussion at one point or another.
Update: Here's another request to display block values in List View: #71168 and #42610.
jasmussen commentedon Feb 5, 2026
It's a crowded space. There's also anchors:
At this point, I feel like we should embrace the Notes tray as a linting tool. Here's how that would look like for hidden blocks:
It's screamingly obvious for surfacing things. Whether indicating CSS deserves this level of prominence, I don't know. The alternative would be an actual linting tab in the List view that showed errors, warnings, and notices, just like the JS does. I would like such a thing regardless.
My main point is, the existing UIs can't expand endlessly, so at some point we have to draw a line in the sand and say: it's time for a linting UI.
t-hamano commentedon Feb 5, 2026
It's probably not possible to cram everything users want into it.
Perhaps one option would be to expose a slot and let users inject their own information.
Mamaduka commentedon Feb 5, 2026
I think that would make the situation worse in the limited space.
aminul-xs commentedon Feb 25, 2026
Mamaduka commentedon Feb 25, 2026
@aminul-xs, that's not what this issue is about. Here's the issue for syntax highlighting - #10423.
jasmussen commentedon Aug 28, 2026
Noting that I closed #71168 in favour of consolidating with this issue.
I also want to connect some dots with instincts shared by @kedarjoyner in #81226, where there are similar concerns about surfacing block-specific customisations, in that case responsive edits. The discussion goes into linting tools, of which one variant has been shown on this issue, but it discusses another option of a "Lint panel". Possibly worth a look to see if it inspires some action on this one.