[wp-trac] [WordPress Trac] #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out

[WordPress Trac]

#38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-
out
-------------------------+------------------
 Reporter:  folletto     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  high         |   Milestone:  4.9
Component:  Customize    |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+------------------

Comment (by folletto):

 > So it just adds “Custom CSS” as another one of the fields

 Ok, now I understand. I'm not sure of the plan for Customize Posts tho, so
 I can't at this time evaluate which could be better. From what I
 understand, if Customize Posts lands, it would make sense to explore that
 direction in more depth.

 > What is the CSS linked with when you provide per-page CSS?

 These are all good question that need to be sorted out. We need to figure
 out what's the best pattern to follow.

 For example, a "high level" approach that we could use for testing would
 be to reuse the same set of classes specified by `get_body_class()`. This
 however might get TOO granular and have unintended side effects, yet, it's
 where I'd probably start prototyping as it already exists.

 Another approach could be to define a criteria that seems working well in
 most of the scenarios, striking a balance between all the various pages
 above: posts get tied to post ID, while categories apply to any category
 page.

 Another approach would be to limit this strictly to Pages, Posts and
 Custom Post Types, which will provide a narrow scope that might be more
 feasible for a v1, and would also avoid any ambiguity.

 Do you have a preference here?


 > This leads directly into one of the big challenges that @melchoyce and I
 have been thinking about for the future of the Customizer: how can users
 be informed when a change is local to the current “page” or global to all
 areas of the site?

 Yes, this is a broader question, that I'd still try to avoid in the work
 done in this component specifically. The reason is that it's an issue at a
 higher order in the architecture, and should be addressed there instead of
 a per-feature UI. Once we have a higher-level pattern, we can review all
 the UIs to follow that pattern.

 The reason I'm saying this is that I could imagine that, with Gutenberg in
 sight, the difference is dealt in the same way at a block level, either by
 having "global blocks" (instances that are flagged as such) or "templates"
 (layout schemes that can be reused across multiple screens). Or... maybe
 not.

 It's a very important discussion to have tho. Is there another existing
 issue where it's better to discuss it?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38707#comment:37>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform