plfn
4 Noviembre, 2020 10:33
1
eg: 漢字かんじ
Furigana don’t affect element height/layout, and the container hides overflow. For example:
Changing style on .topic-body .cooked to be overflow: visible fixes this, though that might also let intentional/annoying overflows through.
This is on latest Firefox (83.0b6) on macOS. Cannot reproduce on Chrome (67).
6 Me gusta
I think we can convert the margin-top: 15px from .regular.contents to be padding-top: 15px on .cooked instead… that would allow us to keep the same spacing and hide overflow, but allows 15px of additional overflow on top (which should be plenty of space for Furigana)…
I need to check to make sure the switch doesn’t cause other issues, but I don’t see any obvious roadblocks…
6 Me gusta
I’ve got a change in our queue for review
master ← awesomerobot:furigana-overflow
merged 05:03AM - 09 Nov 20 UTC
Discussion here: https://meta.discourse.org/t/furigana-at-top-of-comment-get-cut… -off/169206
Switching from margin on `.topic-body .regular` to padding on `.cooked` retains the same visual spacing, and gives vertically overflowing text a little extra space before it's cropped by `overflow: hidden`.
I did a little testing and this seems safe... this comment gave me second thoughts:
> // this ensures consistent top margin on topic posts even if the first line of a post
> // is a top-margin-less element like a list or image.
but it's old and no longer true due to:
```css
> *:first-child {
margin-top: 0;
}
```
(all first children of `.cooked` have their `margin-top` removed)
The above first-child CSS was in `compose.scss` but isn't limited to the composer, so I moved it to `topic-post.scss` and removed a dupe.
2 Me gusta
This has been merged, you can see it in action with this example:漢字かんじ
2 Me gusta
codinghorror
24 Noviembre, 2020 02:00
6
This topic was automatically closed after 5 days. New replies are no longer allowed.
Thanks for reporting this!