WordPress.org

Make WordPress Core

Opened 4 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.8 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 (1)

customizer-css-i2.png (765.9 KB) - added by folletto 4 months ago.
Customizer CSS design i2

Download all attachments as: .zip

Change History (13)

@folletto
4 months ago

Customizer CSS design i2

#1 @lukecavanagh
4 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
4 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
4 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
4 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 4 months ago by folletto (previous) (diff)

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


5 weeks ago

#6 @westonruter
5 weeks ago

For CSS syntax highlighting, see #23601.

#7 @westonruter
5 weeks 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
5 weeks 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 4 weeks ago by westonruter (previous) (diff)

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


3 weeks ago

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


2 weeks ago

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


12 days ago

#12 @westonruter
9 days 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.

Note: See TracTickets for help on using tickets.