docs: fix language option styling

[amareshsm]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:
Fixed language option styling.

What changes did you make? (Give an overview)

Due to the style change (pre[class*="language-"] to div[class*="language-"] - syntax-highlighter.scss) in #16606, language option styles were affected. Fixed by excluding the .language-switcher class.

Before	After

[netlify]

✅ Deploy Preview for docs-eslint ready!

Name	Link
🔨 Latest commit	d86c3f5
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/63946145a982750008ee7b36
😎 Deploy Preview	https://deploy-preview-16636--docs-eslint.netlify.app/user-guide/command-line-interface
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[harish-sethuraman]

Wasn't it part of design? I thought it was part of design 😅

[amareshsm]

Wasn't it part of design? I thought it was part of design 😅

No, it's not a part of the design.

[harish-sethuraman]

LGTM. Thanks

[chenxsan]

Absolutely that's a visual regression my pr introduced.

[nzakas]

Can we change this line to use “pre” instead of “div” and then revert the CSS?
https://github.com/eslint/eslint/pull/16606/files#diff-0e154e64478403222a01a7cb42c83ab07a2e01a90f65b5d0839b922570d4b03aR65

[chenxsan]

Can we change this line to use “pre” instead of “div” and then revert the CSS? https://github.com/eslint/eslint/pull/16606/files#diff-0e154e64478403222a01a7cb42c83ab07a2e01a90f65b5d0839b922570d4b03aR65

Hi Nicholas, I'm afraid we can't simply change that and revert the respective css changes. The default fence rule of markdown-it will always return <pre><code></code></pre>. Replacing that div with pre will result in a nested pre like

<pre>
  <pre><code/></pre>
</pre>

which would introduce another styling problem.

It's possible to keep the original css class if I didn't implement the div wrapper in the beginning. Let me know if you want me to file a pull request to update it or prefer to merge this fix.

[nzakas]

Ah I see. I'm just not a fan of using :not() to fix this kind of an error -- we should have unique and non-overlapping CSS class names for the two different use cases like we did before.

[chenxsan]

Ah I see. I'm just not a fan of using :not() to fix this kind of an error -- we should have unique and non-overlapping CSS class names for the two different use cases like we did before.

Class name collisions seem inevitable when they're semantic :), especially when we have many contributors in open source projects.

How about renaming language-switcher to locale-switcher, which would require a few more changes than the current fix in this pull request:

[nzakas]

Class name collisions seem inevitable when they're semantic :), especially when we have many contributors in open source projects.

Yes but we didn't have any until this change. :) Managing exclusions tends to cause errors in the long-run because you need to keep track of them.

Can't we just add the language- class here and have it work like it used to?

[chenxsan]

Class name collisions seem inevitable when they're semantic :), especially when we have many contributors in open source projects.

Yes but we didn't have any until this change. :) Managing exclusions tends to cause errors in the long-run because you need to keep track of them.

Can't we just add the language- class here and have it work like it used to?

Sure. That was my plan when I said above I can file another pull request to update it:

[harish-sethuraman]

@amareshsm shall we close this in favour of #16669 I think both of the PRs are solving the same problem?

[amareshsm]

@amareshsm shall we close this in favour of #16669 I think both of the PRs are solving the same problem?

yes once the PR is ready we check and close this PR.

[amareshsm]

Closing this in favor of #16669