[wp-trac] [WordPress Trac] #50328: Enqueue script and style assets only for blocks present on the page

[WordPress Trac]

#50328: Enqueue script and style assets only for blocks present on the page
-------------------------+-------------------------
 Reporter:  aduth        |       Owner:  gziolo
     Type:  enhancement  |      Status:  assigned
 Priority:  normal       |   Milestone:  5.5
Component:  Editor       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  javascript
-------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:3 gziolo]:
 > 1. Is the approach I took valid, or did I misunderstood what you were
 proposing?

 And yes, the approach you took is the same I
 [https://github.com/studiopress/atomic-blocks/pull/294/files#diff-
 5345cbb1a2fb13ed3390b67455b585b8R52-R67 took] in Atomic Blocks, except I
 had to use the `render_block` filter naturally.

 I do have one potential issue to simply prepending the `link`, `style`,
 and `script` tags. Some themes (actually,
 [https://wpdirectory.net/search/01EC5YHWSWM7QHZ716N0VQXKGD quite a few])
 have CSS that target top-level elements of the content via CSS like
 `.entry-content > *`.

 Consider a theme that does this:

 {{{#!css
 .entry-content > * {
     display: block;
 }
 }}}

 This would have [https://codepen.io/westonruter/pen/zYrPbOJ negative
 results]! (I faced this on an actual site.)

 For this reason, in my plugin I actually [https://github.com/westonruter
 /syntax-highlighting-code-
 block/blob/e652901420ee6991213eba11e7c8c52176e84e0c/syntax-highlighting-
 code-block.php#L440-L471 inject the style markup] ''inside'' the block's
 opening start tag.

 Nevertheless, this won't work in the general case, as it can break CSS
 that is trying to target a block's `:first-child`.

 Maybe themes are just `_doing_it_wrong` by targeting `.entry-content > *`
 with `display` properties and this should be fixed with education. But I
 see another potential problem: consider CSS that is trying to target a
 given block that appears right after another one: `p + .wp-block-
 illustration`. If there is CSS that gets extracted from such an
 Illustration block to be printed before the block, then this will break
 the selector.

 One area to explore could be to extract the styles and scripts during
 `do_blocks` and then prepend them all to the `$output` of that function.
 That would improve the sibling selector situation, but it would not help
 with the `.entry-content > *:first-child` case.

 I don't have a conclusion here, nor am I entirely sure how much of a
 problem this will with sites generally. But I wanted to raise this as an
 area of concern.

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