[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:10 westonruter]:
 > That being said, a plugin like Jetpack could continue to bundle it and
 then grant `unfiltered_css` to everyone, while then invoking CSSTidy when
 sanitizing CSS to allow it to be available to everyone.

 I'd sooner leave `unfiltered_css` for just that -- unfiltered css -- and
 then for non-superadmins that have access to custom css, run it against
 csstidy to strip out unexpected syntax.

 > The reason for not adding revisions support in core is because there is
 no UI, yet. Plugins, such as Jetpack, can add `revisions` post type
 support. The reasons for the custom post type without revisions is in
 #35395 comments [https://core.trac.wordpress.org/ticket/35395#comment:19
 19] and [https://core.trac.wordpress.org/ticket/35395#comment:74 74] among
 others. A major consideration in using a custom post type was scalability
 and actually specifically having in mind the WordPress.com environment
 where there is a 1MB limit on all options ''combined'' due to Memcached.
 But a custom post type was also chosen to support revisions in the future
 and also so that `custom_css` posts can be imported and exported via WXR,
 eventually.

 It'd be much nicer when revisions support is added to core, or a plugin
 adds it, if the history has already been saved -- as opposed to just
 throwing out the data and it then being unrecoverable.

 Also, WXR doesn't feel right for this -- as the WordPress WXR importer
 isn't really meant for theme-specific stuff as Custom CSS is?  More a gut
 feeling than a firm opinion, fwiw.

 > The reason for having the styles inline is so that they can be
 dynamically overridden with JavaScript in the customizer preview. We did
 discuss being able to link to an external resource, especially when in a
 non-preview context, but for the initial scope it seemed like that could
 be deferred to a future enhancement.

 Any thoughts on adding some base level minification when `SCRIPT_DEBUG`
 isn't set to true -- even if it's just a `str_replace( "\r\n\t", '', $css
 );` ?

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