[wp-trac] [WordPress Trac] #64418: Valid CSS is causing failure in the Additional CSS panel

[WordPress Trac]

#64418: Valid CSS is causing failure in the Additional CSS panel
--------------------------+---------------------
 Reporter:  drw158        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Customize     |     Version:  4.7
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  css
--------------------------+---------------------

Comment (by jonsurrell):

 Replying to [comment:11 westonruter]:
 > @dmsnell @jonsurrell I'm not sure that KSES applies here? The
 `wp_custom_css_cb()` function outputs the CSS without KSES. It just uses
 `strip_tags()`.

 That certainly makes this easier. I put together an idea for relaxing the
 validation to reject only problematic text in https://github.com/WordPress
 /wordpress-develop/pull/10641. It works, allowing CSS like the following:

 {{{#!css
 @property --animate {
   syntax: "<custom-ident>";
   inherits: true;
   initial-value: false;
 }
 @keyframes marquee {
   0% { transform: translateX(0); }
   100% { transform: translateX(-100%); }
 }
 h1 {
   --animate: marquee;
   overflow-x: hidden;
   overflow-y: visible;
   &::before {
     content: '<cool>';
     color: red;
     display: inline-block;
     animation: var(--animate) 5s linear infinite;
   }
 }
 }}}

 However, when I viewed the page it had concatenated my CSS into a larger
 stylesheet:

 {{{#!xml
 <style id='global-styles-inline-css'>
 :root { /* … a lot */ }@property --animate {
   syntax: "<custom-ident>";
   inherits: true;
   initial-value: false;
 }
 @keyframes marquee {
   0% { transform: translateX(0); }
   100% { transform: translateX(-100%); }
 }
 h1 {
   --animate: marquee;
   overflow-x: hidden;
   overflow-y: visible;
   &::before {
     content: '<cool>';
     color: red;
     display: inline-block;
     animation: var(--animate) 5s linear infinite;
   }
 }

 /*# sourceURL=global-styles-inline-css */
 </style>
 }}}

 The concatenation allows me to bypass the check in my initial version
 (`preg_match( '#</style[ \\t\\f\\n\\r/>]#', $css )`) because it appends a
 newline to whatever the CSS contains. That concatenation concerns me in
 general.

 I still think the CSS check can and should be relaxed, it's obviously
 wrong and limiting the ability to use valid CSS.

 Ensuring that the STYLE tag works as expected really doesn't seem like
 business of these validation functions. It should probably happen wherever
 the STYLE tag is being constructed. Working with snippets of text that
 will be printed inside of HTML is error prone, it's too easy to introduce
 issues when snippets are naively stitched together.

 Relying on the HTML API to construct these tags seems like a much better
 approch. This has common ground with #64419 and
 [https://github.com/WordPress/wordpress-develop/pull/10639 PR 10639] where
 I'm proposing the HTML API for constructing safe, sane SCRIPT tags.

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