[wp-trac] [WordPress Trac] #53070: Establish a Core CSS deprecation path

[WordPress Trac]

#53070: Establish a Core CSS deprecation path
---------------------------+-------------------------------
 Reporter:  isabel_brison  |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  css, performance
---------------------------+-------------------------------

Comment (by johnjamesjacoby):

 > with a negative impact on performance

 Is the negative performance impact of unused CSS being enqueued a bigger
 problem than the negative experience plugin users will have when they see
 a broken WordPress admin interface because of an unenqueued
 `deprecated.css`? 🧐

 In my opinion, no. Any potential UI breakage is too high of a risk. 🪂

 The `deprecated.css` approach is a problem, in that it will just end up
 always being enqueued by plugins forever. The bytes saved across the web
 will be miniscule. The only time anyone will notice is when it's broken.

 This is why `deprecated.php`, `ms-deprecated.php`, and `pluggable-
 deprecated.php` are always included. They exist only for developer and
 contributor joy; where unused functions go to be forgotten about, but
 their overhead is forever part of WordPress.

 ----

 CSS is somewhat different in that no promises are ever made to plugin
 authors that they can rely on it working perfectly forever. When I'm using
 the built-in WordPress CSS classes, it's because I want to inherit that
 styling and do not want to invent my own. If it changes, I want those
 changes. If it's being completely removed, that is a problem that
 `deprecated.css` doesn't solve for me as a plugin author because I still
 need to stay ahead of the WordPress release curve to add support for
 whatever the new thing is to avoid breakage for my users. And who's to say
 the old CSS won't break the new CSS?

 I'd almost rather the CSS break entirely than walk the line, like the MP6
 initiative did. Either you're with it, or you're not.

 My vision for solving this problem is one that simply uses the existing
 enqueue API. New styles get newer, better, more organized CSS in whatever
 atomic files make sense, and old styles just stay what they are. If a
 plugin wants to enqueue the new thing, it does. If it wants to keep using
 the old thing, it can.

 Enqueue `wp-admin-list-tables-v1` and get the correct CSS for list tables
 version 1. Componentize and version everything: buttons, forms, settings,
 etc... when I'm ready to support version 2, I enqueue the new hotness. 🔥

 It used to work a lot like this, but over time everything drifted apart
 and got commingled together a few times. Add into that, the modern desire
 to slim the CSS down with JavaScript, is in conflict with the convenience
 of having everything partitioned and readily available and enqueued via
 PHP.

 As a PHP developer, I want to announce to WordPress the core CSS my plugin
 needs loaded, and that's it. If I can't do that, or if the reliability of
 that is diminished, what will happen is plugins will all start rolling
 everything out on their own, and there simply will no longer be a "native
 looking WordPress plugin" because the core CSS cannot be trusted to do its
 job.

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