[wp-trac] [WordPress Trac] #59673: Add viewStyle block.json property for frontend-only block styles

WordPress Trac noreply at wordpress.org
Wed Oct 18 17:28:05 UTC 2023


#59673: Add viewStyle block.json property for frontend-only block styles
-------------------------+-----------------------------
 Reporter:  gaambo       |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Editor       |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 Based on [https://github.com/WordPress/gutenberg/issues/54491 GitHub issue
 54491 for Gutenberg] - see below why created here as well.

 == What problem does this address?

 At the moment `block.json` allows adding `style`s and `editorStyle`s -
 where the assets of `style` are loaded in the editor **and** in the
 frontend. There's no way to add styles which are only added in the
 frontend. Not having this assumes, frontend styles can be used 1:1 in the
 editor. I've encountered many situations where that's just not true - it
 has gotten a lot better with the apiVersion: 2 blocks, but there are still
 many cases where I want to enqueue a style only in the frontend. Examples:
 - Very complex blocks - where I will develop a very specific block editing
 experience in the editor with components and editor styles and want to
 load the "real" styles for the (dynamically) rendered block only in the
 frontend.
 - JavaScript-heavy frontend - the most basic example being slider. I will
 have a lot of CSS which only styles the JS-initialized version of the
 block and they just don't need to be loaded in the editor.
 - There are cases where the frontend styles are just not used in the
 editor (and the block-developer knows that while developing), so it's a
 performance slow-down if you have many such blocks. But there are also
 cases where the frontend styles may just "destroy" the editing experience
 of a block because they just don't work in that context.

 == What is your proposed solution?

 For scripts there's already `script`, `viewScript` and `editorScript`.
 #33542 also brought parity to those so all of those support the same
 values (file paths, asset handles, one or multiple).
 Therefore I propose a `viewStyle` property which works just like the
 `viewScript` property but for styles.
 The `style` property should stay the way it is now (load in frontend +
 editor).
 See [https://github.com/WordPress/gutenberg/issues/33542 GitHub issue
 #33542] and [https://github.com/WordPress/gutenberg/issues/41236 GitHub
 issue #41236] for prior discussion.

 == Why trac ticket?
 It seems only the schema of block.json and documentation is in the
 Gutenberg repository. The code to load those assets is in core in
 [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 includes/blocks.php#L468 register_block_type_from_metadata]. Therefore a
 trac ticket seems the better place instead of GitHub.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59673>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list