[wp-trac] [WordPress Trac] #38672: Custom CSS should work with existing Jetpack custom CSS

[WordPress Trac]

#38672: Custom CSS should work with existing Jetpack custom CSS
-----------------------------+------------------
 Reporter:  helen            |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  highest omg bbq  |   Milestone:  4.7
Component:  Customize        |     Version:
 Severity:  blocker          |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------

Comment (by georgestephanis):

 Replying to [comment:7 westonruter]:
 > For what it's worth, I did ping the Jetpack team about the developments
 of the Additional CSS feature being worked on in core:
 https://github.com/Automattic/jetpack/issues/1621#issuecomment-247155624

 Ack! Posting a comment on a year-and-a-half old issue isn't a great way to
 get eyes on it, unfortunately. :(  That was somewhat compounded by the
 fact that it was right at the start of our Grand Meetup, so kinda doubtful
 anyone caught it.

 I think someone had DM'd me on Slack at it some point in the past, but I
 had no idea it was even being considered for merging into 4.7 until I saw
 some chatter about it this morning.

 For anyone else coming in via this ticket, the Custom CSS ticket was
 #35395 and the big commit was [38829]

 For a brief technical summary of how the core implementation operates
 (because I can't seem to find one anywhere else) -- it works similar to
 the Jetpack/WPCOM one, storing it in a Custom Post Type.  Core uses
 `custom_css` whereas Jetpack and WPCOM use `safecss`.  The Core
 implementation doesn't attempt at any sort of sanitization or
 normalization of the CSS ( :\ ), or any syntax highlighting (I don't blame
 you, the JS library we use adds a lot of weight to Jetpack).  The Core
 Post Type doesn't support revisions either (which I feel is probably a
 mistake).

 The Core implementation also just echoes the generated CSS on `wp_head` --
 personally I'd prefer it if core tweaked `wp_add_inline_style` to allow
 adding inline styles without an external stylesheet to attach it to, so it
 could be dequeued or the like as needed, just as any other style is
 treated.

 @beaulebens -- I worry that if we drop Jetpack's Custom CSS entirely in
 favor of just prettying up the Core implementation, a lot of users are
 going to get left out in the cold.  Permissions for each are radically
 different.   For example, you must be a superadmin on multisite to use the
 core implementation, because they don't even make an attempt at sanitizing
 it -- treating it akin to the `unfiltered_html` cap (it's actually mapped
 to that and named `unfiltered_css`).

 I have serious misgivings about how the Core implementation will work for
 users in multisite, it doesn't feel very well thought out, merely
 defaulting to just taking it away.

 I don't know what the ideal solution is /yet/, for how we play nicely with
 the Core implementation -- it may be to add Sass/LESS preprocessors,
 Syntax highlighting, Revisions, and Sanitization as an enhancement to the
 Core implementation -- with some sort of "nag" link at the top asking the
 user if they'd like to copy their existing Jetpack CSS into the new modal
 to work on further?  Whatever it is, we need to do it in a way that either
 when activating Jetpack's Custom CSS or deactivating Jetpack's Custom CSS,
 no data is lost.  Which could be particularly tricky.

 I'm not thrilled with how quickly this feature was merged into core after
 first being actively discussed, it gives very little time for plugin
 authors to react and work to sort out interop between various data
 structures.

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