- Before #6813, there were no `kbd`s in the UI, but now we have a few. Currently they do not have any special styling other than font family+size. But markup did have pretty good styling.
- This PR makes that styling used globally.
- The only concerning property is `background-color`, which uses a variable with `-markup-` in it, but I do not find this as a significant scope violation. We have many CSS variables but seemingly not enough generic ones.
Co-authored-by: floss4good <floss4good@disroot.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7958
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
This has been introduced in the cherry-picked commit from https://github.com/go-gitea/gitea/pull/34072
To me, adding this seems to be a bug as it forces a hard stop to any overflow nested within a markup div.
Why should it be removed again?
Because otherwise (wide) markdown tables might look super odd because the column breaking/wrapping logic is strange (likely related to the "anywhere" strategy being used).
- [Example of current state with `overflow-wrap`](https://codefloe.com/devxy/helm-rdepot/src/branch/main/charts/rdepot)
- [Example with `overflow-wrap` being removed](https://codefloe.com/devxy/helm-rdepot/src/branch/main/charts/rdepot)
| Current | Patched |
|---------|---------|
|  |  |
The initial change in Gitea was motivated to resolve issues of content overflow caused by the expandable file list tree view they introduced lately. However, this seem to have caused the whole README to overflow in their case, which doesn't apply to Forgejo.
When removing this in Forgejo, only large markdown content (i.e. tables) are allowed to overflow. The whole README div will not overflow (I tested this with an extreme markdown table case).
These tables are then horizontally scrollable, similar to how GitHub handles this.
If the expandable tree view is going to be added to Forgejo, this should then be handled entirely differently. This specific change is not a solution.
I've also checked other value settings to `overflow-wrap` but none had any or any desirable effect.
I did not check all other possible CSS-related options for overflow*, but this might as well be a different task per se.
For the reasons outlined above, I am quite certain this change should be reverted (again).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7945
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
This Fixes#3962 by adding `!important` to the margin of the heading in the rendered markdown.
In the current behaviour, the margin-top was always overridden by a global css-rule. This is prevented by this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4076
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
Adds a feature similar to this https://github.blog/changelog/2021-11-24-specify-theme-context-for-images-in-markdown/ , by adding styles to elements which `src` or `href` attribute ends with `#light-mode-only` or `#dark-mode-only`. To improve compability, the github variants with the `gh-` prefix are also contained.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3985
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
1. Distinguish inline an block code with new CSS variable
`--color-markup-code-inline`
2. Various color tweaks, better contrast from background
(cherry picked from commit 662eb4b0852f9ce2c161e7fea5ac66bf912fc9f6)
---
- Revert the changes of #2874.
- Add more contrast to the inline block for light and dark theme.
(cherry picked from commit 662eb4b0852f9ce2c161e7fea5ac66bf912fc9f6)
It's too thick
I made it match GitHub's size
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
(cherry picked from commit 5f5b5ba6e3e50ba5385e6cbf5957d4b73805769b)
Currently, checkboxes are positioned as absolute. This positioning
causes the input to overlay an element that has been floated within the
editor. Floated elements are useful if you want your text to wrap around
this element. This PR fixes the overlaying of checkboxes by removing the
absolute positioning, updating the `ul` padding, and
displaying`.task-list-item` `flex` to ensure inputs and the associated
label are on the same line.
Screenshots:
Before:
<img width="762" alt="Screenshot 2023-09-01 at 3 40 59 PM"
src="570247c7-7f5c-4697-bfc9-ad4655e37991">
After:
<img width="762" alt="Screenshot 2023-09-01 at 3 42 20 PM"
src="db53df45-1294-4eee-84c0-b21ac4fdf805">
---------
Co-authored-by: rafh <rafaelheard@gmail.com>
## Changes
- no more hardcoded `border-radius`es (apart from `0`)
- no more value inconsistencies
- no more guessing what pixel value you should use
- two new variables:
- `--border-radius-medium` (for elements where the normal border radius
does not suffice)
- `--border-radius-circle` (for displaying circles)
---------
Co-authored-by: silverwind <me@silverwind.io>
It was caused by updating `asciinema-player`, the upstream changed the
CSS class prefix:
`40505e479e`
<details>
<summary>Before:</summary>
<img width="1320" alt="image"
src="b91a2cf5-c1da-43d6-bac2-bc278728b11e">
</details>
<details>
<summary>After:</summary>
<img width="1311" alt="image"
src="c9872d25-e0bb-43d4-8b1e-d87c6b03c0a2">
</details>
Close#20976Close#20975
1. Fix the bug: the TOC in footer was incorrectly rendered as main
content's TOC
2. Fix the layout: on mobile, the TOC is put above the main content,
while the sidebar is put below the main content
3. Auto collapse the TOC on mobile
ps: many styles of "wiki.css" are moved from old css files, so leave
nits to following PRs.
There was some recent discussion about this in Discord `ui-design`
channel and the conclusion was that
https://github.com/go-gitea/gitea/issues/24305 should have fixed their
OS font installation to have semibold weights.
I have now tested this 601 weight on a Windows 10 machine on Firefox
myself, and I immediately noticed that bold was excessivly bold and
rendering as 700 because browsers are biased towards bolder fonts. So
revert this back to the previous value.
This change makes the CSS for `<video>` in markup match that of `<img>`,
and also allows additional attributes to be used. This way the width,
padding, alignment should work equally well for both.
Ran most of the Less files through the Less compiler and Prettier and
then followed up with a round of manual fixes.
The Less compiler had unfortunately stripped all `//` style comments
that I had to restore (It did preserve `/* */` comments). Other fixes
include duplicate selector removal which were revealed after the
transpilation and which weren't caught by stylelint before but now are.
Fixes: https://github.com/go-gitea/gitea/issues/15565
