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

 > make it so that our editor comes in as an upgrade to what core provides.

 This seems the ideal approach to me.

 > ... It is a syntax-highlighted textarea, saves revisions, and also
 allows for pre-processing if the user desires ...
 > ... from a UI/UX front Jetpack could "enhance" things, such as the IDE-
 esque and preprocessor features ...
 > ... seeing revisions in the customizer interface ...
 > ... Editing in a narrow sidebar is kind of annoying, but at least it's
 not infuriating ...
 > ... it may be to add Sass/LESS preprocessors, Syntax highlighting,
 Revisions, and Sanitization as an enhancement ...

 Note that there's a
 [https://core.trac.wordpress.org/ticket/35395#comment:51 design for this
 already].
 Also #31089 that is specifically about designing and building a general
 approach to revisions in Customizer, which I think would be better than
 revisions for just CSS, but we can get there incrementally if we prefer
 building the CSS one first, and then removing it and moving to the global
 one.

 > I really hope this was an honest oversight and not a case of not-
 invented-here, "ugh Automattic" syndrome

 Given I was the designer involved (as well as in .com's CSS side) I'd say
 that's more a technical oversight than a design one. Jetpack's design is
 old and required a refresh, and both in .com and in the Core discussion in
 #35395 we were progressing with better alternatives.

 Just a note on preprocessors: I'd avoid them, or as mentioned in the other
 ticket, I'd simply include SCSS, as the syntax is identical (so a user
 that just knows CSS, simply writes CSS) but at the same time with zero UI
 needed a user writing SCSS will benefit from it too. No need of dropdowns
 or configuration flags.

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

 I agree on the general approach of moving Jetpack's configuretion to
 Core's implementation, data wise.

 May I ask why it couldn't just be a straight migration like:

 1. Jetpack detects Core's setup
 2. Jetpack migrates its CSS to Core's storage,
 3. Jetpack disables the wp-admin UI
 4. Jetpack enabled its enhancement to Core

 Wouldn't that work?
 What are the downsides of it?
 Would it need any change in Core?

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