Discussing Fedora Docs website improvement

Do you have an idea what that means in terms of months / years / decades? And do you watch the discussion? I’m a bit unhappy with the current revamp of some pages. A great graphic design, but at times sparse information and lacking substance.

Our current page may look a bit old-fashioned, but compared to other distributions, it provides a good overview and a lot of significant information. I would like to preserve that very much.

Nor am I. It’s been a while since I’ve implemented a design in CSS. Anyway, if we’re pretty independent here, we can tackle it if we need to. We can keep it as is as long as we don’t have to add boxes for new issues or anything like that.

Dark mode toggle on top right is chef’s kiss. Contrast and visibility of future site are much more enhanced than AS-IS.

The new UI is now deployed in the production environment.

Our asciidoc documentation has also been updated with the latest changes.


I am resurrecting this older thread for 2 issues.

If you collapse the Docs Pages very narrow (e.g. a smartphone). then the TOC pushes itself between the title line and the author line. Usually will be between the author’s line and the first content line.

We discussed making the icons for editing and issue creation more visible. But we didn’t know how to design and to achieve that.

I would propose to enlarge the horizontal space between the icons and the language selector. This alone would make them more visually striking.

Additionally, I would suggest coloring the icons with the blue of the header bar. This increases the visibility further, but keeps the design character and elegance of the theme.

I hope neither is too much work.

1 Like

I pushed a new update with the following fixes & features on the prod documentation website:

  • added category system for quick docs (example)
  • fixed font size for h4 heading
  • fixed alignment issue in admonition blocks on Chrome
  • removed automatic hyphens from code blocks
  • fixed the embedded TOC position in mobile view

@pboy: I believe (1) should be fixed by now. Can you open a ticket in the documentation UI repo for (2)? It will be easier for me, or anyone else who wants to contribute, to keep track of those issues.



And No1 is fixed. Great!

1 Like

Today, I pushed a few minor changes in production, added by @ferdnyc.
Among them, the most notable one is the copy-to-clipboard button for code blocks (upper right when hovering):

Check the clipboard button on the upper right

There is also a special console codeblock that makes copy-pasting easier for command lines:

$ mkdir example
$ cd example

or using a literal paragraph (lines starting with a space):

 $ mkdir example
 $ cd example

In both cases, lines starting with $ are joined with && and the $ is removed.
From the previous example, the pasted text will become:

mkdir example && cd example

This also works with long split lines:

$ podman run -v $PWD:/antora:Z --rm -t antora/antora \
$ podman run -v $PWD:/antora:Z --rm -it antora/antora \
  --clean \

will become, once pasted:

podman run -v $PWD:/antora:Z --rm -t antora/antora version && podman run -v $PWD:/antora:Z --rm -it antora/antora --clean antora-playbook.yml

Note that the output lines (if any) are also removed.

Thank you again @ferdnyc for your contribution, I’m sure this will be very helpful for quick docs writers!


Would it be better to join them with ;? There may be cases where a non-zero return code should not halt the execution of the remaining commands.

Nice! This is great.

Just a suggestion: Simplify the syntax highlighting.

Syntax highlighting should help the reader understand the code. But non-semantic syntax highlighting does the opposite.

For console interaction, I recommend keeping it simple: distinguish only between what is typed by the user versus what is printed by the computer, like a classic O’Reilly book from the mid 90’s. For example, here is a mock-up of visually simpler syntax highlighting:

1 Like

Could you add this to our formatting documentation? Otherwise, I’m afraid that in half a year no one will find it.

It is so visible in code block. We just need to shout out loud in every event and comms about notable Docs improvements such as searchable docs, high impact PRs like this.