WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 9 days ago

#38707 new enhancement

Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out

Reported by: folletto Owned by:
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description

https://core.trac.wordpress.org/raw-attachment/ticket/35395/customizer-css-i2.png

This ticket is to track the next steps of Additonal CSS after 4.7. See #35395 for the discussion so far.

The MVP of the Additional CSS editor in customizer included the basic UI, navigation and backend work.

There are various next steps that area already included in the design above, and can be done either in a single next release or staggered further as needed. From the latest discussed design, the features we already have ready to build are:

  1. Syntax Highlighting
  2. Revisions
  3. Selection of items on the page (CSS selector)
  4. Per-Page CSS as a complement of the current site-wide CSS for better management
  5. The ability to pop-out the editor in a separate window for a more comfortable editing experience

Just one special note regarding revisions: we might want to not do CSS revisions, and instead build the more flexible and general revision UI for the customizer as a whole. That's being discussed in #31089.

Attachments (4)

customizer-css-i2.png (765.9 KB) - added by folletto 10 months ago.
Customizer CSS design i2
customizer-css-revisions-i3.png (181.5 KB) - added by melchoyce 5 months ago.
customizer-css-revisions-i4.png (238.6 KB) - added by melchoyce 5 months ago.
customizer-css-revisions-i4.2.png (245.3 KB) - added by melchoyce 5 months ago.
Updated mockup with @folletto's feedback

Download all attachments as: .zip

Change History (28)

@folletto
10 months ago

Customizer CSS design i2

#1 @lukecavanagh
10 months ago

@folletto

What about global options for CSS?

So plugin CSS specific changes would be global and not be active theme dependant.

#2 @folletto
10 months ago

What about global options for CSS?
So plugin CSS specific changes would be global and not be active theme dependant.

I'm not convinced about this: CSS is very very strongly DOM and the rest of theme-CSS dependent.

However, I might be biased here. Can you list potential situations where a CSS would translate well across themes so we can evaluate the extent of this feature?

#3 @lukecavanagh
10 months ago

@folletto

Say for example a user is using the Jetpack subscribe widget on their site.

#subscribe-email input {
 width: 62%;
 padding: 1px 2px;
}
.comment-subscription-form .subscribe-label {
 display: inline !important;
}

So that CSS is just related to plugin front-end changes and it not related to a theme.

#4 @folletto
10 months ago

I'm not sure, even these seem risky to preserve on a theme change: what if the theme is overriding input fields with flexbox or different widths or margins? What if the inlining breaks entirely the forms?

I think the kind of user that would make use of this UI — which is surely more experienced than others, but also likely not a fully CSS experienced person — might get confused if they enabled a theme straight off and it looks "broken" due to some old lingering CSS they forgot about. That would trigger support emails to the theme author when it's really not the case.

Last edited 10 months ago by folletto (previous) (diff)

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


7 months ago

#6 @westonruter
7 months ago

For CSS syntax highlighting, see #23601.

#7 @westonruter
7 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.8

I think the revisions should be worked on in another ticket, namely #31089.

The other enhancements to Custom CSS outlined here I think should be among low hanging fruit (in conjunction with #12423).

#8 @westonruter
7 months ago

The code editor component we pick should to have syntax checking as well so that a user can see when they have an error in their code. With this in place, we could remove the server-side syntax validation that is currently being done incompletely (see #39198, #39728).

Last edited 7 months ago by westonruter (previous) (diff)

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


7 months ago

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by westonruter. View the logs.


6 months ago

#12 @westonruter
6 months ago

As noted in #12423, there is an inputStyle for CodeMirror that is better for accessibility. Here is a CSS demo forked from @iseulde and @afercia: http://codepen.io/westonruter/pen/Graepj

Looks like the main thing missing in this pen is CSS autocomplete.

#13 @melchoyce
5 months ago

customizer-css-revisions-i3.png is an update just including revisions, without any of the other enhancements. I've updated the styles to match my mockups in #21666.

customizer-css-revisions-i4.png is a potential second iteration, which specifically shows the additions and subtractions you made in each revision.

Both iterations would still update the preview on the right when you toggle between revisions.

#14 follow-up: @folletto
5 months ago

Looks solid, and nicely split into incremental steps :)

One clarification: I'm assuming the text in the i4 (the diff) is going to be "normal" text, not editable which makes things a bit easier. In that case, wouldn't be possible to have the + and the - in the gutter (like line numbers), aligned "outside" the text , instead of being "inside"?

#15 in reply to: ↑ 14 @melchoyce
5 months ago

Replying to folletto:

One clarification: I'm assuming the text in the i4 (the diff) is going to be "normal" text, not editable which makes things a bit easier.

Yup! Also thinking we could add cursor: not-allowed to reinforce that.

In that case, wouldn't be possible to have the + and the - in the gutter (like line numbers), aligned "outside" the text , instead of being "inside"?

Good idea. 👍

@melchoyce
5 months ago

Updated mockup with @folletto's feedback

This ticket was mentioned in Slack in #core-restapi by westonruter. View the logs.


5 months ago

#17 @westonruter
5 months ago

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 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 custom styling and 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.

This ticket was mentioned in Slack in #core-restapi by westonruter. View the logs.


5 months ago

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


4 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


4 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


3 months ago

#22 @jbpaul17
3 months ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per today's bug scrub.

#23 @westonruter
3 months ago

  • Milestone changed from 4.8.1 to 4.9

#24 @westonruter
9 days ago

👉 Please test the new 0.1.0 release for the “codemirror-wp” feature plugin—being worked on for 4.9. This plugin:

  • Extends the Custom HTML widget to add syntax highlighting and checking
  • Incorporates CodeMirror to the Additional CSS control in the Customizer
  • Adds CodeMirror to the file editors for themes and plugins

See the plugin's GitHub releases page to download a ZIP for easy installation: https://github.com/WordPress/codemirror-wp

Report any issues at https://github.com/WordPress/codemirror-wp/issues

Note: See TracTickets for help on using tickets.