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

WordPress Trac noreply at wordpress.org
Mon Dec 15 18:37:46 UTC 2025


#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:  needs-patch   |     Focuses:  css
--------------------------+---------------------

Comment (by dmsnell):

 @westonruter disallowing `</style` would be one idea, but as you shared
 from the HTML API, escaping the characters is a more reliable mechanism.
 `STYLE` is simpler than `SCRIPT` in this regard too, because I think we
 are 100% safe to escape `</style` without messing anything up, unlike how
 in `SCRIPT` we have complications between JavaScript code and JavaScript
 data.

 Still, I would expect this problem to go deep in the KSES stack. Here are
 typical aspects of the issue that can slow down updates:
  - KSES applies at unexpected times in the stack, meaning fixes in one
 place can reappear in others
  - the rules are based more on impulse and ad-hoc fixes than spec, meaning
 that established behaviors enshrine unwanted outputs from specific input
 test cases
  - downstream code isn’t robust, so Core prefers to corrupt the content
 rather than leave open a nebulous opportunity for other code to get
 confused. e.g. stripping tags to remove the chance that it might escape
 the `STYLE` element and be interpreted as HTML.

 for this particular issue, my initial thought is that we look at this box
 as a CSS box. it’s not HTML, and we handle it in the editor outside of an
 HTML context, so we should prepare it on save by turning it into a string
 that will avoid issues with Core’s treatment of it //as// HTML.

  - can we escape it before save to preserve the input?
  - is the existing “sanitizer” aware of CSS syntax? let’s update it for a
 tactical approach, if we can, to give us more time to resolve the issue
 properly and for the general case.
  - in the long term we should analyze the entire pipeline from CSS box in
 the browser through Core to the database and back, and ensure that we can
 stop applying hazardous rules to the content and preserve it.

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


More information about the wp-trac mailing list