Page MenuHomePhabricator

Evaluate how the text in the input window appears
Open, Needs TriagePublic

Description

I received reports about problem with the text size in the input window. It looks, that the character type and size depends on local settings (OS, browser, ?) and in some cases it is so small that not readable.

This image depicts how much the characters are smaller compared to the normal character size used on the page. (The same characters are relative bigger for me, but still one size smaller than the normal character size on the page. And instead of sans, I see it with serif characters; which I like.)

IMG_3702.jpg (701×750 px, 158 KB)

Do we have an influence on this?

Proposed solution and patches in: T245476: [SPIKE] How to make source editors' font-size responsive

Event Timeline

Same issue pops up in source editors: T245476: [SPIKE] How to make source editors' font-size responsive

Cause: .mw-editfont-* classes on the textarea's parent div force the font-size to 13px.
That rule was added for historical reasons, unfortunately it's not relative to the browser's font-size setting and it's too generic. At that time it didn't cause issues to many people.

The rule should be font-size: inherit; to use the skin's font-size and 90% for monospace as done in this patch (monospace fonts metrics are usually bigger).
Those rules can be overridden with more specific selectors for DiscussionTools similarly to the above patch.

The font (sans / serif / monospace) used in the editor depends on the user preference "Edit area font style".
If you prefer serif fonts like I do, you can use that for articles too with a font changer addon or my theme.

The font (sans / serif / monospace) used in the editor depends on the user preference "Edit area font style".

Thanks, I already forgot about this option in the Settings.

If you prefer serif fonts like I do, you can use that for articles too with a font changer addon or my theme.

Wow, that looks really cool! I will try it out :)

JTannerWMF moved this task from Untriaged to Next Quarter on the Editing-team board.

@matmarex will provide some context here and @iamjessklein will look into this when she has time.

The font in the reply box it meant to be exactly the same as in the normal editing interface. This seems to be working correctly for me, see this animated comparison of screenshots I just took (https://hu.wikipedia.org/wiki/Wikipédia:Kocsmafal_(egyéb)#Azerbajdzsán_hete_a_CEE_Tavasz_2020_keretében)

font match.gif (1×2 px, 277 KB)

If you're seeing different font sizes, then please take some screenshots of them, and we'll investigate.

The default monospace font in the editing interface is indeed a bit smaller than the article text. I don't know why, but my guess is that it was meant to "balance out" the larger width of the monospace characters.

But, I can see how this could be confusing with our "inline" preview. Maybe we should actually use a different font size in the reply box than the editing interface?

Either way this should be less important when we finish implementing visual editing for the reply box, as the visual editor font will be exactly the same as the article font.

The font in the reply box it meant to be exactly the same as in the normal editing interface.

It is. The problem is that the normal (source) editing interface uses 13px font-size regardless of the page's.

If you're seeing different font sizes, then please take some screenshots of them, and we'll investigate.

To see the issue change your browser's font-size or add the CSS rule body { font-size: 150% }.
The reason is detailed in T245476: [SPIKE] How to make source editors' font-size responsive
Tl;dr in the above comment: T251469#6095628

The default monospace font in the editing interface is indeed a bit smaller than the article text. I don't know why, but my guess is that it was meant to "balance out" the larger width of the monospace characters.

Yes, the bit wider monospace fonts are the reason to use the fixed 13px font-size, compared to Vector's 14px article font-size (~92.86%). This does not work well with non-monospace fonts and bigger skin/browser font-size. Related patch fixing this issue in Timeless's source editor is awaiting review (you might be the person who can merge it): T247325#6049054.
DiscussionTools might want to take a similar approach, albeit the specificity issues encountered in Timeless don't apply here.

But, I can see how this could be confusing with our "inline" preview. Maybe we should actually use a different font size in the reply box than the editing interface?

For monospace (.mw-editfont-monospace) I've found 90% of the article font-size to be a good fit. For sans and serif fonts 90% looks uncomfortably small, 100% works better.

Change 605435 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] Make source editor font-size relative to browser font-size

https://gerrit.wikimedia.org/r/605435

Change 605438 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] [editor] Editor font-size inherits the skin's font-size, 90% for monospace.

https://gerrit.wikimedia.org/r/605438

Change 605438 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] [editor] Editor font-size inherits the skin's font-size, 90% for monospace.

Reason:

This would be a disruptive change and we're not going to accept these patches. Sorry.

https://gerrit.wikimedia.org/r/605438