[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 westonruter):

 Replying to [comment:11 georgestephanis]:
 > 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.

 That's a good idea. So when CSSTidy is availably, as with Jetpack, the
 `capability` restricting with the `custom_css` setting could be opened up,
 but then if the user does not have `unfiltered_css` then Jetpack then the
 sanitization filters would apply on the setting value. In this case, it
 would also be beneficial to add selective refresh for the `style` element
 so that the actual sanitized CSS would be previewed rather than the pre-
 sanitized value coming straight from CSS.

 > 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.

 Yeah, I suppose so. It just seems that having revisions in the DB without
 them being accessible in any way seems like it would be a first time in
 core where permanent data is kept but it is not accessible?

 > 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.

 If I were trying to export data from one site to import into another, as a
 user I sure would like it if my custom CSS were included in the export.
 But for that matter, I'd also want all of my other site options to be
 included as well, but as you know presently there isn't a core way to
 export site settings without a plugin. Better something than nothing.

 > 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
 );` ?

 Yeah, some whitespace normalization could be good. The amount of byte
 savings would border on being trivial though? I also wonder if there could
 be a problem with whitespace normalization stripping corrupting CSS in any
 way. I'd feel safer if a CSS tokenizer were used to identify the actual
 syntactic whitespace, in the same way as we need a tokenizer to properly
 identify unbalanced parens, braces, and brackets.

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