[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