Opt out of self-closing tags

[colindean]

I surmise that the presence of self-closing tags in jekyll-seo-tag's template is because these are ~needed because Jekyll technically supports XHTML still (evidenced here and here).

I'd like these not to be in my output, as they create noise in validations since they're optional in HTML5 but not optional in XHTML.

I'd love to detect the type based on page.url but I think it's safer to enable an opt-out when calling the plugin, e.g.

{% seo close_tags=false %}
<!-- OR -->
{% seo xhtml=false %}

Would either of these suffice?

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master/main branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

[colindean]

I'd still like this, and I think someone on my team might have an implementation at least started.

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master/main branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

[captn3m0]

Still important, please keep this open.

@samford: Did you get a chance to upstream your changes?

[datapolitical]

I have this issue as well. Would love to see it fixed.

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master/main branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

[samford]

Looking into this again, it appears that there's a related open PR but it only covers removing the trailing slashes entirely. When I last left this, I created two potential implementations: one that uses a site variable in _config.yml and one that uses an argument/attribute/option (I'm not sure what you call it in a Liquid template) like in the original issue description. The former seems like something that can be replicated in other plugins (e.g., jekyll-feed) but the latter takes advantage of some existing jekyll-seo-tag code that's not present in other plugins and may be a challenge to replicate (at least for me but maybe not the maintainers).

In both approaches, the literal forward slash (/) is replaced with a variable that is conditionally set to either "" (an empty string) or " /". To maintain backward compatibility, the plugin continues to self-close tags by default but the difference is that these implementations allow you to opt out of self-closing tags.

From the outside, this seems like a decent compromise between the extremes of always self-closing tags or never self-closing tags (as in the linked PR). However, I'm not sure that either of these approaches are necessarily compelling in terms of the actual code involved. The existing /> is terse but having to remember to use {{ close_tag }}> at the end of every tag may be a hard sell. At the very least, this may further the discussion in the aforementioned PR. I will comment on that PR to link to this issue and my branches later today.

---

That said, if this doesn't end up going anywhere (or if you want a workaround in the interim time), I found that you can capture the plugin output into a variable and call the replace filter on it to replace instances of /> in the generated HTML. It ends up looking something like this:

{% capture seo_tag_output %}
  {% seo title=false %}
{% endcapture %}
{{ seo_tag_output | replace: " />", ">" | replace: "/>", ">" }}

The replace filter doesn't support regular expressions (e.g., /\s*\/>/, so this example chains multiple filters to handle both /> and />. However, jekyll-seo-tag seems to consistently use />, so you can probably get away with just the first replace call.

It's a naive replacement and isn't foolproof (i.e., it could potentially replace text that we don't want it to) but should seemingly work for most cases.

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master/main branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.