AkkomaGang/akkoma-fe
5
13
Fork 64
Code Issues 82 Pull requests 20 Projects Releases 1 Wiki Activity

Use FEP-c16b: Formatting MFM functions #410

Open
ilja wants to merge 11 commits from ilja/akkoma-fe:use_fep-c16b_formatting_mfm_functions into develop
pull from: ilja/akkoma-fe:use_fep-c16b_formatting_mfm_functions
merge into: AkkomaGang:develop
Conversation 5 Commits 11 Files changed 9 +29
2 changed files with 29 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit ba4ae5badb - Show all commits

1
src/components/status_body/status_body.scss
View file

@ -12,6 +12,7 @@
}
.emoji {
--_still_image-label-scale: 0.5;
/* NOTE: We also use this value hard-coded in src/components/status_content/mfm.scss */
--emoji-size: 38px;
}

28
src/components/status_content/mfm.scss
View file

@ -63,14 +63,35 @@
.mfm-x2 {
--mfm-zoom-size: 200%;
/*
emoji is normally 38px (see src/components/status_body/status_body.scss
we want x2 to be ~100px, so we enlarge (100px/38px) ~= 2.63
*/
.emoji {
--mfm-emoji-zoom-size: 2.63;
}
Oneric commented 2024-08-25 01:15:18 +00:00
Outdated
Review
Copy link

I think the whole emoji size scaling setup is overly complicated. Just setting --mfm-emoji-zoom-size: 2.63; etc as here in all relevant cases and using this with a default of 1.0 directly in the base emoji height definition would achieve the same effect as now but avoid manually overriding height directly and --nested-base-emoji-size for some MFM effects.

However, while i appreciate the effort which went into preserving Akkoma’s old emoji scaling exactly (except for nested scaling which previously was a noop), this scaling behaviour is not compatible with Foundkey, iceshrimp and likely all other keys and imho leads to a jarring discrepancy as emoji get scaled noticeable more than text. Foundkey and IceShrimp set the emoji height to 2em instead of a fixed pixel value which means they’ll get automatically be scaled together with and by the same amount as text without any emoji-specific scaling logic. Imho we should adopt this too; improving portability and simplifying our logic at the same time.

I think the whole emoji size scaling setup is overly complicated. Just setting `--mfm-emoji-zoom-size: 2.63;` etc as here in all relevant cases and using this with a default of `1.0` directly in the base emoji `height` definition would achieve the same effect as now but avoid manually overriding `height` directly and `--nested-base-emoji-size` for some MFM effects. However, while i appreciate the effort which went into preserving Akkoma’s old emoji scaling exactly *(except for nested scaling which previously was a noop)*, this scaling behaviour is not compatible with Foundkey, iceshrimp and likely all other keys and imho leads to a jarring discrepancy as emoji get scaled noticeable more than text. Foundkey and IceShrimp set the emoji height to `2em` instead of a fixed pixel value which means they’ll get automatically be scaled together with and by the same amount as text without any emoji-specific scaling logic. Imho we should adopt this too; improving portability and simplifying our logic at the same time.
❤️ 1
ilja commented 2024-11-01 13:27:40 +00:00
Outdated
Review
Copy link

set the emoji height to 2em instead of a fixed pixel value

Yes! I didn't understand why I needed extra CSS for emoji while Foundey didn't ^^' Using em works perfectly, thx!

One problem I saw with this, as you say, *key uses 2em. But Akkoma uses 38px, which corresponds to ~2.9px. So that means that we'd have smaller emoji than what people are used to on Akkoma-fe. I see two options

  • We set emoji at 2em, and people have to live with it (personally I prefer them a bit bigger)
  • We keep 38px for emoji, but when a zoom (x2, x3, x4, tada) is used, we override to --emoji-size: 2em;. In normal situations, emoji will be 38px as they are now. When a zoom is used, the emoji will be e.g. 2em * 200%. For tada, it will start at 2em, so smaller than "normal", but then it grows bigger bc that's what tada does.

When I try, this looks OK for me. It may cause things to be slightly off for things like mfmArt, but if we want to be completely compatible with the most advanced mfmArt, we have to change a lot more I'm afraid. So the question then becomes how far we want to go with that.

I now pushed a new commit with the second option, because it looks best to me, but it can still be changed if needed.

> set the emoji height to 2em instead of a fixed pixel value Yes! I didn't understand why I needed extra CSS for emoji while Foundey didn't ^^' Using `em` works perfectly, thx! One problem I saw with this, as you say, *key uses 2em. But Akkoma uses 38px, which corresponds to ~2.9px. So that means that we'd have smaller emoji than what people are used to on Akkoma-fe. I see two options * We set emoji at 2em, and people have to live with it (personally I prefer them a bit bigger) * We keep 38px for emoji, but when a zoom (x2, x3, x4, tada) is used, we override to `--emoji-size: 2em;`. In normal situations, emoji will be 38px as they are now. When a zoom is used, the emoji will be e.g. `2em * 200%`. For tada, it will start at `2em`, so smaller than "normal", but then it grows bigger bc that's what tada does. When I try, this looks OK for me. It may cause things to be slightly off for things like mfmArt, but if we want to be completely compatible with the most advanced mfmArt, we have to change a lot more I'm afraid. So the question then becomes how far we want to go with that. I now pushed a new commit with the second option, because it looks best to me, but it can still be changed if needed.
Oneric commented 2024-11-01 15:26:32 +00:00
Outdated
Review
Copy link

i was thinking of continuing to retain the current base size for non-MFM posts, but use 2em for MFM posts only.
This way scaling remains striaghtforward and we’re more compatible while the majority of posts (not-MFM) doesn't change at all

i was thinking of continuing to retain the current base size for non-MFM posts, but use `2em` for MFM posts only. This way scaling remains striaghtforward and we’re more compatible while the majority of posts (not-MFM) doesn't change at all
ilja commented 2024-11-02 16:28:16 +00:00
Outdated
Review
Copy link

That one has crossed my mind too, but also has its problems (and worse imo).

From a code-complexity perspective; We now need a way for css to know what posts are mfm and not. It's doable, we can add a class somewhere with what content they were written in (or at least that it's MFM). But that's more complexity than what I did now (just one extra line in the css that already handles the zoom), so not an advantage in that regard, on the contrary.

It also means that input method now has an effect on the end result. But input method should purely be a client thing imo, transforming input into a proper representation. With MFM we couldn't do that, hence the work that this PR is part of. Bringing back the requirenment for knowing the input method and doing special handling goes against the "raison d'être" of this work for me.

There's also the fact that it may not be obvious to people why a custom emoji is smaller in some cases and bigger in others. Not all posts who are marked as having MFM are always MfmArt. So in those cases you'd have a perfectly normal-looking post, but suddenly the emoji have a different size than what people expect. This is internally inconsistent and I fear this will bring more confusion.

That one has crossed my mind too, but also has its problems (and worse imo). From a code-complexity perspective; We now need a way for css to know what posts are mfm and not. It's doable, we can add a class somewhere with what content they were written in (or at least that it's MFM). But that's more complexity than what I did now (just one extra line in the css that already handles the zoom), so not an advantage in that regard, on the contrary. It also means that input method now has an effect on the end result. But input method should purely be a client thing imo, transforming input into a proper representation. With MFM we couldn't do that, hence the work that this PR is part of. Bringing back the requirenment for knowing the input method and doing special handling goes against the "raison d'être" of this work for me. There's also the fact that it may not be obvious to people why a custom emoji is smaller in some cases and bigger in others. Not all posts who are marked as having MFM are always MfmArt. So in those cases you'd have a perfectly normal-looking post, but suddenly the emoji have a different size than what people expect. This is internally inconsistent and I fear this will bring more confusion.
Oneric commented 2024-11-02 16:48:58 +00:00
Outdated
Review
Copy link

From a code-complexity perspective; We now need a way for css to know what posts are mfm and not

If it wasn’t dropped as part of this change we already have that via the .mfm class. In fact this change is part of the client-side overrides I’m applying atm to make MFM post behave better.

current MFM CSS overrides for reference 
    /* Slow default down until Akkoma parses parameters again */
    ._mfm_spin_ {
        animation: mfm-spin 2.0s linear infinite !important;
    }
    
    /* Nested Tags use calc(var(--mfm-zoom-size) / 2 + 50%)
     * With zoom-size being:
     *  - x4: 600%
     *  - x3: 400%
     *  - x2: 200%
     */
    ._mfm_x2_ ._mfm_x4_,
    ._mfm_x3_ ._mfm_x4_,
    ._mfm_x4_ ._mfm_x4_ {
        font-size: 350%;
    }
    ._mfm_x2_ ._mfm_x3_,
    ._mfm_x3_ ._mfm_x3_,
    ._mfm_x4_ ._mfm_x3_ {
        font-size: 250%;
    }
    ._mfm_x2_ ._mfm_x2_,
    ._mfm_x3_ ._mfm_x2_,
    ._mfm_x4_ ._mfm_x2_ {
        font-size: 150%;
    }
    
    .mfm .emoji /*img*/ {
        height: 2em !important;
        vertical-align: middle;/**/
    }

It also means that input method now has an effect on the end result.

Input methods already have an effect on the end result, e.g. MFM is rendered as an inline block, line spacing differs between MFM,Markdown and BBCode,plain text, plain text quotes get coloured while in Markdown and MFM it gets shifted, set in faint text /Or italics atm) and a bar is added, etc

Each input method is a different typeset language and to get the same result across different input methods, different input is required (if possible at all).
MFM in particular comes with stricter expectations on what constitutes a correct display and is defined by *key instances. One of those requirements being 2em-sized emoji.

> From a code-complexity perspective; We now need a way for css to know what posts are mfm and not If it wasn’t dropped as part of this change we already have that via the `.mfm` class. In fact this change is part of the client-side overrides I’m applying atm to make MFM post behave better. <details> <summary>current MFM CSS overrides for reference</summary> ```css /* Slow default down until Akkoma parses parameters again */ ._mfm_spin_ { animation: mfm-spin 2.0s linear infinite !important; } /* Nested Tags use calc(var(--mfm-zoom-size) / 2 + 50%) * With zoom-size being: * - x4: 600% * - x3: 400% * - x2: 200% */ ._mfm_x2_ ._mfm_x4_, ._mfm_x3_ ._mfm_x4_, ._mfm_x4_ ._mfm_x4_ { font-size: 350%; } ._mfm_x2_ ._mfm_x3_, ._mfm_x3_ ._mfm_x3_, ._mfm_x4_ ._mfm_x3_ { font-size: 250%; } ._mfm_x2_ ._mfm_x2_, ._mfm_x3_ ._mfm_x2_, ._mfm_x4_ ._mfm_x2_ { font-size: 150%; } .mfm .emoji /*img*/ { height: 2em !important; vertical-align: middle;/**/ } ``` </details> > It also means that input method now has an effect on the end result. Input methods already have an effect on the end result, e.g. MFM is rendered as an inline block, line spacing differs between MFM,Markdown and BBCode,plain text, plain text quotes get coloured while in Markdown and MFM it gets shifted, set in faint text /Or italics atm) and a bar is added, etc Each input method is a different typeset language and to get the same result across different input methods, different input is required *(if possible at all)*. MFM in particular comes with stricter expectations on what constitutes a *correct* display and is defined by \*key instances. One of those requirements being `2em`-sized emoji.
ilja commented 2024-11-03 06:40:36 +00:00
Outdated
Review
Copy link

I should maybe rephrase myself. We get an object who has a content field. It also has a source field. Currently we use the source field, and that causes problems. This whole excercise here is about making it so that the content can be used without requiring the source field.

Afaik, the differences you mention don't have anything to do with the source (i.e. stated input method) field at all, they are purely derived from the content. The only exception is MFM, and that's what this is trying to fix.

MFM in particular comes with stricter expectations on what constitutes a correct display and is defined by *key instances. One of those requirements being 2em-sized emoji.

I certainly do not have the expectation of emoji to suddenly look different, and I very much believe it will only cause more confusion. Emoji are federated just like any one else federates them, so there's no special expectation there. There's is also no specific mention of 2em on https://misskey-hub.net/en/docs/for-users/features/mfm/

Besides, if that's really the case to make, that the content should look like it does on Misskey; how far should this be taken? Because there's more than just "emoji are 2em size". Should the text font be different? Should the spacings be different? Should we render the spacing differend? Heck, should the width of the content be changed? And so on... If yes, then we dissagree on a very fundamental level which I do not see how to resolve.

I should maybe rephrase myself. We get an object who has a `content` field. It also has a `source` field. Currently we use the `source` field, and that causes problems. This whole excercise here is about making it so that the `content` can be used without requiring the `source` field. Afaik, the differences you mention don't have anything to do with the `source` (i.e. stated input method) field at all, they are purely derived from the content. The only exception is MFM, and that's what this is trying to fix. > MFM in particular comes with stricter expectations on what constitutes a correct display and is defined by *key instances. One of those requirements being 2em-sized emoji. I certainly do not have the expectation of emoji to suddenly look different, and I very much believe it will only cause more confusion. Emoji are federated just like any one else federates them, so there's no special expectation there. There's is also no specific mention of `2em` on https://misskey-hub.net/en/docs/for-users/features/mfm/ Besides, if that's really the case to make, that the content should look like it does on Misskey; how far should this be taken? Because there's more than just "emoji are `2em` size". Should the text font be different? Should the spacings be different? Should we render the spacing differend? Heck, should the width of the content be changed? And so on... If yes, then we dissagree on a very fundamental level which I do not see how to resolve.
ilja commented 2024-11-03 07:59:14 +00:00
Outdated
Review
Copy link

Maybe a more important question; Do you consider this a blocking issue? If not, I'd like to keep it for now, as I do consider it a strict improvement regardless, and then see what people think.

Maybe a more important question; Do you consider this a blocking issue? If not, I'd like to keep it for now, as I do consider it a strict improvement regardless, and then see what people think.
}
.mfm-x3 {
--mfm-zoom-size: 400%;
/*
emoji is normally 38px (see src/components/status_body/status_body.scss
we want x3 to be ~150px, so we enlarge (150px/38px) ~= 3.95
*/
.emoji {
--mfm-emoji-zoom-size: 3.95;
}
}
.mfm-x4 {
--mfm-zoom-size: 600%;
/*
emoji is normally 38px (see src/components/status_body/status_body.scss
we want x4 to be ~200px, so we enlarge (200px/38px) ~= 5.26
*/
.emoji {
--mfm-emoji-zoom-size: 5.26;
}
}
.mfm-x2,
@ -78,6 +99,10 @@
.mfm-x4,
.mfm-tada {
font-size: var(--mfm-zoom-size);
.emoji {
--nested-emoji-base-size: calc(var(--emoji-size) * var(--mfm-emoji-zoom-size));
height: var(--nested-emoji-base-size);
}
.mfm-x2,
.mfm-x3,
@ -85,6 +110,9 @@
.mfm-tada {
/* only half effective */
font-size: calc(var(--mfm-zoom-size) / 2 + 50%);
.emoji {
height: calc(var(--nested-emoji-base-size) * var(--mfm-emoji-zoom-size) / 2);
}
.mfm-x2,
.mfm-x3,