[wp-trac] [WordPress Trac] #63007: Bundled themes: Stylesheets for block themes are missing path data for inlining

[WordPress Trac]

#63007: Bundled themes: Stylesheets for block themes are missing path data for
inlining
-----------------------------------+-------------------------------
 Reporter:  westonruter            |       Owner:  westonruter
     Type:  enhancement            |      Status:  accepted
 Priority:  normal                 |   Milestone:  6.9
Component:  Bundled Theme          |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  css, performance
-----------------------------------+-------------------------------

Comment (by westonruter):

 Replying to [comment:22 poena]:
 > I can't explain this better, and I would prefer if it was addressed and
 not dismissed.
 > If I am coming on as aggressive right now, it is because I am not
 feeling heard.

 Sorry, I'm trying to understand. And sorry if I was pushing too hard to
 get this in this release. To me it seemed like an easy performance win,
 but I'm not a themes component maintainer so I defer to your expertise. I
 won't push for this to be part of 6.8 without the blessing of the
 component maintainers.

 > When the ticket was opened, it included this comment:
 > "I'm not sure if this is the right place to introduce the minification,
 as perhaps it should be part of the theme's own build process." [...]
 > But then without further discussion it seems to have been decided that
 it must be the minification script that is in core. Which, would require
 knowledge of this script. I believe that is not an incorrect claim.

 Yeah, I included minification of the `style.css` files for the block
 themes here because when they are inlined they should be minified to
 ensure they don't exceed the `styles_inline_size_limit` limit. So perhaps
 #63012 should be addressed first as a dependency for this ticket.

 > I added this as one point of my comment, in addition to documentation.
 [...]
 > And the comment about documentation has not been addressed at all.

 In regards to documentation, the
 [https://make.wordpress.org/core/handbook/testing/patch/#setting-up-
 without-vvv documentation for testing a patch] already instructs to run
 `grunt build`. So any additional documentation specifically for testing
 themes should include this if it doesn't already.

 > Secondly, I described a scenario where a user repurposes the theme and
 adds CSS to style.css.
 > It does not matter if the user uses a text editor or the built in theme
 file editor.
 >
 > What matters is that style.css is not enqueued, instead the minified
 files is. And the user does not have  knowledge of that they need to edit
 the minified files, or how, or knowledge about script debug.
 > So the users changes are not working, and it is not a positive
 experience for them.

 If someone forks a theme and modifies the `style.css` then this indeed
 would be an issue. I described this in a previous
 [https://core.trac.wordpress.org/ticket/49665#comment:4 comment] on #49665
 where I wondered if the forking scenario was a reason why minification
 hasn't been done in the past. Nevertheless, there are themes today that
 already have a build step for their CSS, namely Twenty Nineteen and Twenty
 Twenty-One. So technically if someone forks those themes they already
 should not be using the theme file editor to edit the `style.css` file
 directly but rather to edit the underlying SASS files and then run `npm
 install && npm run build` in the theme. For themes that use SASS and for
 those which have minified CSS files, there should probably be a big notice
 comment in the `style.css` that instructs the users to run `npm run build`
 after making a change, and that for themes using SASS that the change
 should be made to the SASS files directly. For minification, the comment
 can say something like:

 {{{
 /*
  * NOTICE:
  * This file is served minified to improve performance. In order to see
 edits
  * to this file on the frontend, either enable the `SCRIPT_DEBUG` constant
 or
  * run `npm run build` to regenerate `style.min.css`. Alternatively, if
 you do
  * not want to use minified version, then remove the `style.min.css`
 version from
  * being enqueued in `functions.php`.
  */
 }}}

 Every theme would need to include their own `package.json` which has the
 `npm run build` command that which would result in the minified files
 being generated so that they wouldn't have to rely on core's build process
 to generate those files.

 > Increasing the complexity of block themes is in direct opposition of the
 goal and purpose of block themes (Ideally, these themes should not have
 had any CSS at all). This is not an opinion that is only my own. This has
 impact on the project.
 >
 > The situation and expectation is different for the classic bundled
 themes, some of them already have build tools, they already require
 advanced coding knowledge.

 In regards to block themes, is the `style.css` related to the Site Editor
 in any way? As far as I know, the Site Editor only results in changes to
 "Global Styles" and doesn't touch the `style.css` at all.

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