What should be the HTML structure returned when `wp-show` is false?

[SantosGuillamot]

While working on creating the wp-show directive attribute, I wasn't sure the HTML that should be returned when wp-show evaluates as false. I'm opening this issue to discuss the implications of the different alternatives and decide on an approach.

Given the following HTML:

<div data-wp-show="false" class="my-class">
  <p>Children</p>
</div>

I considered two alternatives:

Option 1 - Wrapped everything inside the <template> tag

<template>
  <div data-wp-show="false" class="my-class">
    <p>Children</p>
  </div>
</template>

Option 2 - Wrapped children inside the <template> tag

<div data-wp-show="false" class="my-class">
  <template>
    <p>Children</p>
  </template>
</div>

As I mentioned, I don't know the pros and cons of each alternative, so I'd love to hear your thoughts. Whatever we decide, should probably be applied to similar directives like wp-each to keep consistency.

Alpinejs is using the second approach. For directives like x-if or x-for, they used them directly in the <template> tags, and it requires that <template> MUST contain only one root element.

On the other hand, if not explained properly, I feel that Option 2 could cause unexpected layout issues.

[dmsnell]

wrapping in a template pulls the contents and the directive out of the DOM and out of the page. this effectively hides it in a pocket dimension, so calls to querySelectorAll('div') will only find the one living outside of the <template>

that also means we can't apply styling to them, not that we would likely want to, but for example, some debug border to show the location of the directives wouldn't be possible.

since I'm less aware, possibly forgetful, is the requirement to wrap in a <template> manadatory, vs. hiding with CSS?

Option 2 could cause unexpected layout issues.

the main thing is probably that Option 1 simply doesn't participate in layout, as it's not in the page, whereas Option 2 lives in the DOM as an empty <div>

[luisherranz]

Imagine these blocks. Each inner block can be hidden or shown when clicked, and they can start hidden or shown depending on an attribute.

<!-- wp:superlist/list -->
<ul class="wp-block-superlist-list">
  <!-- wp:superlist/list-item -->
  <li class="wp-block-superlist-list-item">Item 1</li>
  <!-- /wp:superlist/list-item -->

  <!-- wp:superlist/list-item -->
  <li class="wp-block-superlist-list-item">Item 2</li>
  <!-- /wp:superlist/list-item -->

  <!-- wp:superlist/list-item -->
  <li class="wp-block-superlist-list-item">Item 3</li>
  <!-- /wp:superlist/list-item -->
</ul>
<!-- /wp:superlist/list -->

<?php
// render.php - superlist/list-item
?>

<li
  <?php echo get_block_wrapper_attributes(); ?>
  data-wp-context='{ "superlist": { "isShown": <?php echo $attributes[ "isShown" ]; ?> } }'
  data-wp-show="context.superlist.isShown"
  data-wp-on:click="actions.superlist.toggleItem"
>
  <?php echo $attributes[ 'text' ]; ?>
</li>

If we use Option 2 and the second element is hidden, the resulting HTML would be (I'm omitting the directives for simplicity):

<!-- wp:superlist/list -->
<ul class="wp-block-superlist-list">
  <!-- wp:superlist/list-item -->
  <li class="wp-block-superlist-list-item">Item 1</li>
  <!-- /wp:superlist/list-item -->

  <!-- wp:superlist/list-item -->
  <li class="wp-block-superlist-list-item">
    <template>Item 2</template>
  </li>
  <!-- /wp:superlist/list-item -->

  <!-- wp:superlist/list-item -->
  <li class="wp-block-superlist-list-item">Item 3</li>
  <!-- /wp:superlist/list-item -->
</ul>
<!-- /wp:superlist/list -->

That is not correct because it's rendered like this:

This specific case seems to be resolved by adding style="display: contents" to the <li> node when it's hidden, but that overcomplicates the developer experience because they would need to add:

<?php
// render.php - superlist/list-item
wp_store( array( 
  'selectors' => array(
    'superlist' => array(
      'listItemDisplay' => $attributes[ 'isShow' ] ? 'list-item' : 'contents'
    ),
  ),
) );
?>

<li
  ...
  data-wp-style:display="selectors.superlist.listItemDisplay"
>
  ...
</li>

// view.js
store({
  selectors: {
    superlist: {
      listItemDisplay: ({ context }) =>
        context.superlist.isShown ? "list-item" : "contents",
    },
  },
});

There are also some accessibility problems related to display: contents.

So:

• Is there another way to make this work if we go with Option 2?
• Are there more cases like this?

[luisherranz]

is the requirement to wrap in a template manadatory, vs. hiding with CSS?

I believe it's the correct one because the browser doesn't load the assets.

For example, a 100-image slideshow using this for each image:

<div data-wp-show="false" style="display: none;">
  <img src="...">
</div>

would download 99 unnecessary images on page load.

But as everything, it's open for discussion, of course 🙂

[dmsnell]

the browser doesn't load the assets.

interesting. have we confirmed this with any tests? seems like browsers today might optimize that away. if not, I can run a test and check

[luisherranz]

have we confirmed this with any tests? seems like browsers today might optimize that away.

I did a quick test in Stackblitz and it seems like Chrome is indeed honoring that behavior. Although I wouldn't mind if it wouldn't in certain circumstances, like a desktop computer with a fiber connection (similar to what it does with loading="lazy").

Screen.Capture.on.2023-03-03.at.11-48-04.mp4

[adamziel]

Option 2 combined with tables would result in

  <tr>
    <template><td>Col 1</td><td>Col 2</td></template>
  </tr>

An extra table row also sounds problematic for all sorts of reasons: borders, paddings, rowspans and colspans.

Perhaps if the outer tag was rendered with an inline style="display: none"?

[SantosGuillamot]

Maybe there's a third option I didn't share in the opening post: Restrict the wp-show directive to be used inside <template>. So users would be required to write something like this:

<template data-wp-show="false">
  <div class="my-class">
    <p>Children</p>
  </div>
</template>

I'm not convinced of this approach, I don't see clear benefits of this one over option 1, but sharing it here in case it makes sense somehow. I'm still not familiar with how this would work internally, especially in the SSR.

[luisherranz]

I'm not convinced of this approach

Yeah, my neither... but it's the best option if we finally can't use set_outer_html. Thanks for sharing.

Perhaps if the outer tag was rendered with an inline style="display: none"?

The problem is that if we use style="display: none;" in the outer tag and that tag is an image/iframe/script, it will still download the asset.

Alpinejs is using the second approach. For directives like x-if or x-for, they used them directly in the <template> tags, and it requires that <template> MUST contain only one root element.

I think it was me who told you this, but I was wrong. Alpine is using style="display: none" for x-show and the template approach (option 3) for x-if. I don't like either.

---

I think the best option in terms of developer experience is 1.

Actually, I would even use a slightly simplified variation of 1. When wp-show is false:

• Wrap it with <template> in the server (maybe also move the wp-show to the template).
• Remove it from the DOM in the client.

In the client, having the DOM elements wrapped by <template> is not useful. I mean, we already have the static virtual nodes that represent that HTML in memory, we don't need them in the DOM anymore.

Stackblitz example

[SantosGuillamot]

I think it was me who told you this, but I was wrong. Alpine is using style="display: none" for x-show and the template approach (option 3) for x-if. I don't like either.

Okay, you're right! Got it 🙂

I think the best option in terms of developer experience is 1.

I agree with this. I guess I would just go with option 3 if we can't use set_outer_html then.

Actually, I would even use a slightly simplified variation of 1.

I like it 🙂 I have one question, though: Would this mean that, if you inspect the HTML in the browser, you won't be able to see the hidden elements? Could this cause some issues with debugging?

[luisherranz]

Could this cause some issues with debugging?

Well, wrapping them in the <template> is incidental to the fact that we are using HTML as our templating language. This React component won't put anything in the DOM either and I have never seen people complaining about it:

const Comp = ({ children }) => {
  const [show, setShow] = useState(false);
  return show ? children : null;
}

[SantosGuillamot]

That makes sense 🙂 Thanks for clarifying!