[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:  normal       |   Milestone:  4.8
Component:  Customize    |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+------------------

Comment (by westonruter):

 For development, I think this will look like:

 1. Ensure that `custom_css` posts are exposed via the REST API. It may
 make sense to have a `/customize/custom-css` endpoint, along with
 `/customize/custom-css/twentyfifteen` for getting the post resource for
 the twentyfifteen theme and also `/customize/custom-
 css/twentyfifteen/revisions` to get the list of revisions for that theme's
 custom CSS. Some discovery will be needed there for what makes the most
 sense, and whether or not the REST API should allow access to `custom_css`
 posts for non-active themes. See also #39634 and #38900, and questions on
 [https://wordpress.slack.com/archives/C02RQC26G/p1491369854606383 Custom
 CSS endpoints].
 2. Create a custom customizer section for Custom CSS, instead of re-using
 the default section type. This custom section would have its UI augmented
 to show the “See CSS history” link, and when clicked to hide the controls
 (the textarea) and show the list of revisions (fetched via REST API). This
 custom section would also override the behavior of the back button to not
 cause the section to collapse but rather back out of viewing the list of
 revisions or previewing a revision at a given point. This might warrant
 also creating a custom control for the `textarea` input as well; see its
 [https://github.com/WordPress/wordpress-develop/blob/4.7.3/src/wp-
 admin/css/customize-controls.css#L1153-L1204 custom styling] and
 [https://github.com/WordPress/wordpress-develop/blob/4.7.3/src/wp-admin/js
 /customize-controls.js#L5296-L5339 behavior].
 3. When clicking on a revision, it needs to be previewed. This is a bit
 tricky, but the CSS from the `custom_css` post at that revision needs to
 be pushed into the `custom_css` setting so that it can be previewed. But a
 complication here is what if a user then clicks Save & Publish even though
 they didn't hit the Restore button? In this case, the Restore button would
 really not be doing anything other than collapsing the revision preview
 and revision list to then focus back on the textarea; similarly, the Back
 button would then also have to have the behavior of restoring the previous
 value for the `custom_css` setting, as clicking Back instead of Restore
 indicates the user didn't want to apply the setting change. This seems
 somewhat backwards, but it seems easier to implement than having a
 “preview preview”, some kind of preview change to a setting to preview
 without actually causing it to be written into the changeset.

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