[wp-trac] [WordPress Trac] #63919: Block Bindings: Conditional rendering of HTML elements corresponding to block attrs

[WordPress Trac]

#63919: Block Bindings: Conditional rendering of HTML elements corresponding to
block attrs
-----------------------------+-----------------------
 Reporter:  Bernhard Reiter  |       Owner:  (none)
     Type:  enhancement      |      Status:  assigned
 Priority:  normal           |   Milestone:  6.9
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------

Comment (by Bernhard Reiter):

 Yes, that's a very valid point. There's a real risk of adding too much
 implicit magic to the logic that processes block markup before rendering.

 Earlier approaches ([https://github.com/WordPress/gutenberg/pull/70642
 e.g.]) attempted to avoid this by adding directives (such as `wp-data-
 maybe-hide`) to instruct WP what to do and to make the process thus more
 explicit. However, TBH I didn't like that too much either, since the
 directive seemed largely redundant (the infomation's available from the
 block's `metadata.bindings` attribute), yet required pervasive updates to
 existing block markup (as seen in the block markup snapshot test updates
 [https://github.com/WordPress/gutenberg/pull/70642/files in that PR]);
 plus I wasn't quite sure if this approach would scale well to other logic
 constructs (e.g. `for` loops) which we will eventually need (think Gallery
 blocks).

 But I agree that there's a risk in saying, "oh yeah, this element is
 empty, and it corresponds to a `rich-text` attribute whose `selector` in
 block.json is a tag name, so that means we'll remove it".

 One alternative I can think of is a more block-supports inspired approach,
 where we provide utils on both the editor (JS) and render (PHP) side.
 "Just" opting a block attribute into Block Bindings seems like a bit of a
 pipe dream anyway right now; there's always ''some'' block-specific logic
 that needs tweaking. (For example, the Image caption needed
 [https://github.com/WordPress/gutenberg/pull/71483/files#diff-
 a14b61c874095649b236b78413e805b4541277b24eb71ce350a17d9f2b6396b1 changes
 to its corresponding UI control's visibility]).

 So maybe we can provide block authors with tools such as
 `replace_block_attribute_value()` (which would be basically
 [https://github.com/WordPress/wordpress-
 develop/blob/e81ed1179135c1550986b2e70310cdf92bb5e0bb/src/wp-includes
 /class-wp-block.php#L409 this thing]) or `remove_node`. One downside is
 that it would mean that even blocks that have so far been static will need
 to add PHP code to do so if any of their attributes is to be supported by
 Block Bindings (even e.g. `core/paragraph`!)

 ----

 As a way forward, how about we start by landing
 [https://github.com/WordPress/gutenberg/pull/71483 the editor-only
 changes] first (once that PR is unblocked)? From there, we can see if we
 prefer conditionally removing the `<figcaption>`
 [https://github.com/WordPress/wordpress-develop/pull/9702 based on
 "generic" criteria], or to do it from the block's `render` method (needs a
 PR).

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