Doc bold font issue

[Icarus9913]

What happened?

https://kuma.io/docs/2.7.x/introduction/overview-of-kuma/

[Icarus9913]

For the first issue line, I think we fix it with (Just move ** into the if conditional check)

* {% if_version gte:2.6.x %}**Single-zone{% endif_version %}{% if_version lte:2.5.x %}**Standalone{% endif_version %} and multi-zone**: Supports multiple clouds, regions, and Kubernetes clusters with native DNS service discovery and ingress capability.

But for the latter sub-list gramma, I tried the upper way but not works. @johncowen Do you have any ideas?

[johncowen]

Hmm yeah weird, its this fiddly if_version thing again 🤔

I had a mess around with different approaches to listing/linebreaks and things, but couldn't get it to do what we want.

I wonder if just making completely separate lists for the different versions would be better? There would be some duplication but at least we might be able to get it to render how we want?

[Icarus9913]

Hmm yeah weird, its this fiddly if_version thing again 🤔

I had a mess around with different approaches to listing/linebreaks and things, but couldn't get it to do what we want.

I wonder if just making completely separate lists for the different versions would be better? There would be some duplication but at least we might be able to get it to render how we want?

Yeah, I think that will be pretty simple and direct. There's only one thing that I concerned, we used lot's of if_version gramma for docs and I just change this place or we change the whole ?

[johncowen]

If it was me I'd just do it here for now (if that solves the issue here)

I remember seeing a PR somewhere for improving how if_version works, not sure if thats applied here yet or will come soon, so it might be less fiddly to use pretty soon.

[Icarus9913]

@johncowen Hey jc, I just forgot. This page is only one. It's an overview page to summary the whole versions.

I mean, it seems like we can not do separate lists for different versions because all different versions share the common one page.

[johncowen]

I 'think' (but not totally sure 😅 ) that something like the following would do it. There's plenty of repetition but it works fine 🤷‍♂️ .

(just to note I'm not totally sure that the below versioning is correct, but if not we just need to make more variations of full lists)

What do you think?

{% if_version lte:2.5.x %}
* **Universal and Kubernetes-native**: Platform-agnostic, can run and operate anywhere.
* **Standalone and multi-zone**: Supports multiple clouds, regions, and Kubernetes clusters with native DNS service discovery and ingress capability.
  * [Read more about standalone deployments](/docs/{{ page.version }}/production/deployment/stand-alone/)
  * [Read more about multi-zone deployments](/docs/{{ page.version }}/production/deployment/multi-zone/)
* **Multi-mesh**: Supports multiple individual meshes with one control plane, lowering the operational costs of supporting the entire organization.
* **Attribute-based policies**: Lets you apply fine grained service and traffic policies with any arbitrary tag selector for `sources` and `destinations`.
* **Envoy-based**: Powered by Envoy sidecar proxies, without exposing the complexity of Envoy itself.
* **Horizontally scalable**
* **Enterprise-ready**: Supports mission critical enterprise use cases that require uptime and stability.
{% endif_version %}

{% if_version gte:2.6.x %}
* **Universal and Kubernetes-native**: Platform-agnostic, can run and operate anywhere.
* **Single-zone and multi-zone**: Supports multiple clouds, regions, and Kubernetes clusters with native DNS service discovery and ingress capability.
  * [Read more about single-zone deployments](/docs/{{ page.version }}/production/deployment/single-zone/)
  * [Read more about multi-zone deployments](/docs/{{ page.version }}/deployments/multi-zone)
* **Multi-mesh**: Supports multiple individual meshes with one control plane, lowering the operational costs of supporting the entire organization.
* **Attribute-based policies**: Lets you apply fine grained service and traffic policies with any arbitrary tag selector for `sources` and `destinations`.
* **Envoy-based**: Powered by Envoy sidecar proxies, without exposing the complexity of Envoy itself.
* **Horizontally scalable**
* **Enterprise-ready**: Supports mission critical enterprise use cases that require uptime and stability.
{% endif_version %}

[Icarus9913]

Agree, this is a good idea and we can do this.👍🏻