Logo Overlaps with Menu in RTL Languages

[mboukhalfa]

This is a Bug Report

Problem:
When switching to an RTL language, the logo overlaps with the menu, creating a layout issue as shown in the picture! This is different form the issue google/docsy#1442 and google/docsy#829 these issues are discussing switching the positioning for of menu elements to fit with RTL but the logo overlap problem is not observed in the docsy check: https://example.docsy.dev/fa/

The root cause of the problem is suspected to be the custom CSS applied in the k8s website. Here

website/assets/scss/_custom.scss

Lines 132 to 139 in 95ca859

	.navbar-brand {
	position: absolute;
	width: 45px;
	height: 44px;
	background-repeat: no-repeat;
	background-size: contain;
	background-image: url("/images/favicon.png");
	}

Proposed Solution:
To fix this we can override the logo position with RTL languages for example:

body:lang(fa),
body:lang(ar),
body:lang(az),
body:lang(dv),
body:lang(he),
body:lang(ku),
body:lang(ur) {
  .navbar-brand {
    left: 16px;
  }
}

However, it's recommended to consider a more comprehensive solution. Refactoring the custom CSS added to the k8s website. We have big custom css (>1000 lines ) overriding the default docsy! might be necessary to avoid interfering with the default docsy styling. It's advisable to minimize overrides to essential elements, aligning with the purpose of using docsy. This approach ensures a cleaner separation between documentation content and web development concerns.
Page to Update:
https://deploy-preview-45056--kubernetes-io-main-staging.netlify.app/ar/

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dipesh-rawat]

/area web-development

[Gauravpadam]

@mboukhalfa is it an issue with all RTL languages?

[Gauravpadam]

In that case, we'll need a more flexible solution than just changing the css positions; I've got something in mind

[mboukhalfa]

@mboukhalfa is it an issue with all RTL languages?

yes it is

[mboukhalfa]

In that case, we'll need a more flexible solution than just changing the css positions; I've got something in mind

Can you elaborate what a flexible solution would be ?

[sftim]

/area localization

/remove-kind bug
We don't have RTL support yet, so it's more a feature request (see #22730 for the overall feature request).

[sftim]

We have big custom css (>1000 lines ) overriding the default docsy! might be necessary to avoid interfering with the default docsy styling.

See #41171 for an issue about reducing our level of customization. It's useful work that we have not yet staffed.

[chalin]

Hi all: if you could upvote google/docsy#1442 that would help it get some traction.

[mboukhalfa]

Hmm I think I found the issue it seems we are using ml-md-auto class to push the menu always to the right side however this classes are not supporting direction change as show in the issue so when we switch to RTL the logo go to the other side but the menu keep its place instead of moving to left side

website/layouts/partials/navbar.html

Line 4 in 95ca859

<div class="td-navbar-nav-scroll ml-md-auto" id="main_navbar">

twbs/bootstrap#22780 (comment)

Probably using d-flex flex-row-reverse in the nav instead of flex-column flex-md-row can help having the same effect but then we need to deal with the logo differently there is a room for improvement there I think it is not a good idea to include the logo with css as a background to some element ! we can just follow the theme and add few customization to have the current rendering

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.