Fix documentation field-list label rendering

[nightcityblade]

What do these changes do?

Adds a small CSS rule for Sphinx field-list labels so labels such as Parameters: keep enough width instead of rendering as a cramped vertical column.

Are there changes in behavior for the user?

No runtime behavior changes. Documentation pages should render parameter labels more readably.

Is it a substantial burden for the maintainers to support this?

No. This is a small documentation stylesheet adjustment with minimal maintenance impact.

Related issue number

Fixes #4127.

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is .
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the CHANGES/ folder
  • name it <issue_or_pr_num>.<type>.rst (e.g. 588.bugfix.rst)
  • if you don't have an issue number, change it to the pull request
    number after creating the PR
    • .bugfix: A bug fix for something the maintainers deemed an
      improper undesired behavior that got corrected to match
      pre-agreed expectations.
    • .feature: A new behavior, public APIs. That sort of stuff.
    • .deprecation: A declaration of future API removals and breaking
      changes in behavior.
    • .breaking: When something public is removed in a breaking way.
      Could be deprecated in an earlier release.
    • .doc: Notable updates to the documentation structure or build
      process.
    • .packaging: Notes for downstreams about unobvious side effects
      and tooling. Changes in the test invocation considerations and
      runtime assumptions.
    • .contrib: Stuff that affects the contributor experience. e.g.
      Running tests, building the docs, setting up the development
      environment.
    • .misc: Changes that are hard to assign to any of the above
      categories.
  • Make sure to use full sentences with correct case and punctuation,
    for example:

    Fixed issue with non-ascii contents in doctest text files
    -- by :user:`contributor-gh-handle`.

[codspeed-hq]

Merging this PR will not alter performance

✅ 72 untouched benchmarks
⏩ 72 skipped benchmarks¹

---

_{Comparing nightcityblade:fix/issue-4127-css (352718c) with master (8b8b245)}

Footnotes

1. 72 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.94%. Comparing base (1c472b5) to head (352718c).
⚠️ Report is 356 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #12585      +/-   ##
==========================================
+ Coverage   98.77%   98.94%   +0.16%     
==========================================
  Files         128      131       +3     
  Lines       44890    46683    +1793     
  Branches     2383     2421      +38     
==========================================
+ Hits        44340    46189    +1849     
+ Misses        390      369      -21     
+ Partials      160      125      -35     

Flag	Coverage Δ
Autobahn	22.45% <ø> (?)
CI-GHA	98.91% <ø> (+0.27%)	⬆️
OS-Linux	98.66% <ø> (+0.29%)	⬆️
OS-Windows	97.02% <ø> (+0.30%)	⬆️
OS-macOS	97.92% <ø> (+0.31%)	⬆️
Py-3.10.11	97.41% <ø> (+0.25%)	⬆️
Py-3.10.19	?
Py-3.10.20	97.90% <ø> (?)
Py-3.11.14	?
Py-3.11.15	98.15% <ø> (?)
Py-3.11.9	97.67% <ø> (+0.30%)	⬆️
Py-3.12.10	97.76% <ø> (+0.30%)	⬆️
Py-3.12.12	?
Py-3.12.13	98.24% <ø> (?)
Py-3.13.12	?
Py-3.13.13	98.46% <ø> (?)
Py-3.14.3	?
Py-3.14.3t	?
Py-3.14.4	97.69% <ø> (?)
Py-3.14.5	98.20% <ø> (?)
Py-3.14.5t	97.54% <ø> (?)
Py-pypy3.11.13-7.3.20	?
Py-pypy3.11.15-7.3.22	97.41% <ø> (?)
VM-macos	97.92% <ø> (+0.31%)	⬆️
VM-ubuntu	98.66% <ø> (+0.29%)	⬆️
VM-windows	97.02% <ø> (+0.30%)	⬆️
cython-coverage	37.91% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bdraco]

@aiolibsbot review

[aiolibsbot]

PR Review — Fix documentation field-list label rendering

Small, low-risk CSS-only change with a changelog fragment. The mechanics are fine — selector is valid, no behavioral or security risk, codecov/codspeed are green. Two things worth addressing before merge: (1) the rule lives in logo-adjustments.css, which is a misnomer for a field-list fix; (2) there's no visual verification (screenshots or rendered preview) that the rule actually fixes #4127 across the documentation. The min-width: 6em value also deserves a quick sanity check on narrow viewports and in the actual Sphinx theme to ensure no regressions on shorter labels or mobile rendering. Not blocking, but a brief screenshot or rendered-docs link would make this easier to approve.

---

🟢 Suggestions

1. Selector scope and theme considerations (`docs/_static/css/logo-adjustments.css`, L8-10)

The selector .field-list>dt is broad — it will apply to every Sphinx field list across the documentation (parameters, returns, raises, custom info fields, etc.). A min-width: 6em may help typical cases but could cause issues for short labels in narrow viewports/mobile, or interact poorly with theme-specific styling. Consider:

1. Verifying behavior in the actual Sphinx theme this site uses (Alabaster/RTD/etc.) — some themes already style dt.field-odd/dt.field-even with their own widths.
2. Testing at narrow widths to ensure the min-width doesn't trigger horizontal overflow on mobile.
3. Adding a brief comment in the CSS explaining the rationale (fixes Documentation formatting is... unusual #4127, prevents cramped vertical rendering) so a future reader knows why this exists.

Also note this CSS file is named logo-adjustments.css — a field-list rule is unrelated to the logo. Either rename to something generic (e.g. custom.css) or split into a separate stylesheet for clarity.

.field-list>dt {
  min-width: 6em;
}

2. Changelog attribution should be aiolibsbot (`CHANGES/4127.doc.rst`, L1-2)

Per the repo's attribution convention for bot-drafted PRs, the :user: handle in the changelog fragment must match the PR-author handle (the GitHub account opening the PR), not the requester/fix-issue reporter. If nightcityblade is the PR author on GitHub, this is correct. If the PR is being opened by aiolibsbot on behalf of the requester, update the trailer to :user:aiolibsbot``.

-- by :user:`nightcityblade`.

3. No visual verification provided

The PR description states documentation should render more readably but doesn't include before/after screenshots. For a pure-CSS doc fix, a screenshot pair (or a link to a built docs preview) is the easiest way for reviewers to validate that the rule actually solves issue #4127 without regressing other field-list usages (e.g. :raises:, :returns:, custom info fields). Consider attaching screenshots or running make doc and linking the rendered output.

---

Checklist

• No hardcoded secrets
• Input validation at boundaries
• Changelog fragment present and well-formed
• Selector scoped appropriately — suggestion ＃1
• Visual verification (screenshots / rendered preview) provided — suggestion ＃3
• File naming reflects content — suggestion ＃1

---

Summary

Small, low-risk CSS-only change with a changelog fragment. The mechanics are fine — selector is valid, no behavioral or security risk, codecov/codspeed are green. Two things worth addressing before merge: (1) the rule lives in logo-adjustments.css, which is a misnomer for a field-list fix; (2) there's no visual verification (screenshots or rendered preview) that the rule actually fixes #4127 across the documentation. The min-width: 6em value also deserves a quick sanity check on narrow viewports and in the actual Sphinx theme to ensure no regressions on shorter labels or mobile rendering. Not blocking, but a brief screenshot or rendered-docs link would make this easier to approve.

---

Automated review by Kōan352718c