Do not render anything if blocks output nothing

[bakura10]

Hi :),

As of today, if a block does not output anything, it will still output in the DOM the wrapper:

{{ block.settings.text }}

{
  "name": "Text",
  "settings": [
    {
      "type": "text",
      "id": "text",
      "default": "Welcome to our store",
      "label": "Content"
    }
  ]
}

Especially with settings bounded to metafields that might be empty, this will generate a lot of empty DOM elements:

We often use the sibling selector in CSS, and this basically breaks it.

[ludoboludo]

Hey @bakura10, you can actually opt out of having a wrapping element by adding "tag": null

{
  "name": "Text",
  "tag": null,
  "settings": [

Here is more info about it

Unless I'm misunderstanding and you had done that already 🤔

[bakura10]

Ah yeah I miss this. But this should then be the default as I will basically need to do that for all blocks. I think Shopify could abstract it and keep the wrapper (the wrapper has the benefit that you don’t have to output block.shopify_attributes yourself) but do not output the wrapper if nothing is rendered in the block

[ludoboludo]

Isn't it odd for the block to output nothing ? Having it showing in the sidebar but doing nothing on the actual theme 🤔

I guess a merchant can do this by having a text block and removing any text from the block setting. So it would be a good fallback and that's usually where we've used conditionals (if block.settings.text == blank...).
But if a wrapper is always outputted then there is no way to conditionally hide it.

So that's where you'd enjoy it if the platform was a bit smarter and didn't always add an wrapping element eh? 🤔

Though I still see a benefit to having "tag": null as an option.

[bakura10]

The most common use case of content being empty: a merchant create a block and connect the content with a meta field. This metafield might not have value for a lot of different products.

[tyleralsbury]

This use case makes a lot of sense and is quite interesting. It can happen for pretty much any block and may lead to a lot of empty space if there isn't a way to account for it (padding / margins / etc...) Thanks @bakura10 !

[t-kelly]

Another perspective here -- what I feel like this overlaps with is how sections/blocks/themes handle placeholder content, ie. what gets rendered when the intended content is not set.

Maybe a pattern that could be defined here to handle this case + all other placeholder content cases?

[ludoboludo]

+1 on this. If you're wanting to show a different placeholder image based on the context you can't. Same for info or paragraph from the sidebar settings.

[PaulNewton]

based on the context you can't

maybe for surrounding sections/blocks settings we can't access the scopes, i.e. which block is the next sibling , though for sure things like product.template or product.tags are used to swap placeholders. Though we're cautioned to not show stuff in preview not shown on the customer-storefront.

But at the same time since we can't change the sidebar conditionally either ALL information has to try and be baked into the settings info/paragraph or links; or the preview caution has to be ignored to insert warnings or onboarding content in place of meaningless placeholders.

[bakura10]

Is there some progress on this issue @ludoboludo

I'm doing some more experiments and this is actually a huge problem and I'm not sure how to solve this cleanly.

Even if the content is empty, Shopify generate an empty string, which prevents to use the :empty CSS selector.

But, ideally, Shopify should check if the content is empty and, if it is, completely remove the parent from the DOM.

For now, the only workaround I found would be to use the following CSS:

.shopify-block {
  display: contents;
}

This would ensure that block are ignored in the DOM tree, but I'm afraid this might cause compatibility issue with some apps.

[ludoboludo]

You could use something like this, but it's not quite empty. It's if an element has no other element as a child. So if it's a string, whether it's a space or text. It will apply the styling from the declaration below:

.shopify-block:not(:has(*)) {
  ...
}

I will run it past the team again though to make sure we're aware of it 👍

[PaulNewton]

.shopify-block:not(:has(*)) {
...
}

Please no, nope, no , We should not be styling for things that are both: A) NOT there and B) SHOULD NOT be there.
That is a complexity multiplier that should not be baked into the system making theme devs have to be "clever" from the jump.

[bakura10]

I agree. Plus :has selector is still only Safari 15.4+ (we suppprt up to Safari 14 at Maestrooo) and :has selector are among the slowest (selector performance is negligible I agree but with Shopify focus on perf we should avoid introducing that)

[ludoboludo]

Yes, I'm not suggesting it as the solution, just a work around for the time being 🙂

[clauderic]

Even if the content is empty, Shopify generate an empty string, which prevents to use the :empty CSS selector.

@bakura10 this should now be fixed, we shipped a fix for this bug yesterday.

[benjaminsehl]

This is an interesting idea — I don’t know how I feel about it. I get what you mean, basically “don’t let the merchant ship an empty block that they don’t intend to be there… and don’t force me to do defensive coding for it” … will think more about it.

[PaulNewton]

This also crashes into the guideline that themes shouldn't show things in the theme editor preview that wont actually be shown on the frontend to customers.

Which for stores that don't have a fancy staging process, or multivariate testing, results in placeholder content being visible to customers by default.
And cases where devs have to add some sort of callout to the editors preview when some feature/element wont visibly show to customers but the merchant needs feedback insitu in the preview to sanity check settings; and the callout message may also have mention the callouts message itself wont show too. Not an easy fix.