Page MenuHomePhabricator

[SPIKE] How to make source editors' font-size responsive
Open, MediumPublic3 Estimated Story PointsSpike

Description

Original title: WikiTextEditor uses 13px font while VisualEditor uses the skin's default
The report has been expanded to address the same issue surfacing in DiscussionTools that affects more users:
T251469: Evaluate how the text in the input window appears

Problem statement

Source editors are fixed to using 13px font-size regardless of the skin's and the browser's chosen font-size.
The font-size in the source editor can become disproportionate to the overall font-size, resulting in degraded UX.

Solution

The general solution would be:

  1. Inherit the font-size from the skin, thus rendering the edited text with the same font-size as the surroundings.
  2. In case of monospace fonts which tend to occupy more space at the same font-size setting: use ~90% of the font-size inherited from the skin. Status quo:
    • Vector: 13px/14px ~= 92.86%
    • MonoBook: 13px/12.7px = 102.36%
    • Modern: 13px/13px = 100%
    • Timeless WTE, WTE2010: 15.2px/15.2px = 100% (after my initial fix T247325#6034393)
    • Timeless WTE2017: 13px/15.2px = 85.53% (pending fix T247325#6049054)

Patches on this task demonstrate the 90% monospace, 100% otherwise solution.
Individual skins can be customized, for ex. Vector would use 12.6px font-size with this generic approach, which might be undesirable.

Original report

Initially reported for the Timeless skin (T247325), the rest use miniature fonts anyway and Minerva overrides the font-size in <p> tags.

Steps to Reproduce:
  1. WTE2010: https://www.mediawiki.org/wiki/2017_wikitext_editor?action=edit&useskin=timeless
  2. enable "New wikitext mode"
  3. WTE2017: https://www.mediawiki.org/wiki/2017_wikitext_editor?veaction=editsource&useskin=timeless
Actual Results:

Hard-to-read 13px font-size.

Expected Results:

Readable 15.2px font-size (inherited from the skin) for sans and serif editfont.
About 10% smaller font-size for monospace fonts: the same text is rendered in about the same area at ca. 90% font-size as with serif and sans fonts.

Screenshots

Good:

WTE2017-tiny-font-Minerva-good-size.png (1×1 px, 189 KB)
WTE2017-tiny-font-Minerva-good-size-2.png (798×1 px, 95 KB)

Bad vs Good:

WTE2017-tiny-font-bug-Timeless.png (734×1 px, 182 KB)
WTE2017-tiny-font-VE-good-size.png (812×1 px, 295 KB)

Details

The offending css rule is (loaded into a <style> tag):

.mw-editfont-monospace, .mw-editfont-sans-serif, .mw-editfont-serif {
    font-size: 13px;
}

The patch that added it: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/396005/5/resources/src/mediawiki/mediawiki.editfont.css
The cause: T182320: Fix textarea editor's edit font size
textarea elements set an inconsistent font-size in old browsers. (Not in today's Chrome, idk about others)

For historical reasons we've allowed inconsistent browser-default styles to apply to textarea#wpTextbox1

Early approach
  1. 2017WTE has no textarea element (only divs). The selector should be more specific: .textarea.mw-editfont-*
  2. Just reset the textarea element's font-size to the parent's: font-size: inherit; That will be the skin's chosen default.
  3. The second patch addresses an error (details) in CodeMirror that was revealed by this change.

Event Timeline

Restricted Application added subscribers: Masumrezarock100, Aklapper. · View Herald Transcript

Change 572765 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Inherit the skin's default font-size from parent element on textarea.mw-editfont-* and .mw-editfont-* .oo-ui-inputWidget-input elements.

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

This needs to be checked against CodeMirror highlighting because thats very finicky.

This needs to be checked against CodeMirror highlighting because thats very finicky.

Thanks for mentioning that. There is some multi-layered black magic there.

.CodeMirror {
	font-family: monospace;
}
.CodeMirror pre { /* Each line */
	font-family: inherit;
	font-size: inherit;
}

The rest you can imagine: a multi-layered connondrum where inheriting the bigger font-size makes everything smaller (pre elements involved). Affects the WTE2017.
The WTE2010 with CodeMirror highlighting is unaffected due to a style="font-size:<calculated>" attribute.

Fix: .CodeMirror { font-family: monospace, monospace; }
This seems to be missing from T176636: Unify CSS font stack of monospace-styled elements across products

Why is syntax highlighting done with a monospace font in the first place?
It should be consistent with the other editor modes, using the user's editor font preference, thus the fix is to remove the rule:
.CodeMirror { font-family: unset; }
This changes the highlighted mode's font back to the expected editor font, affecting the WTE2010. Might surprise someone, hopefully positively.

WTE2017

Note: the WTE2017 still uses monospace font after this due to .mw-editfont-monospace being added to the editor. Not a concern of this task.

In Minerva WTE2017 with highlighting is completely fallen apart, which I assume nobody used or tested if that's not reported.

It requires the above font-family fix and additionally:
.skin-minerva .ve-init-mw-desktopArticleTarget .CodeMirror { padding: unset; }

Testing

Test on live servers: https://userstyles.org/styles/180301/wikipedia-source-editor-font-size-fix

Tested: WTE2010 and WTE2017
With skins: Timeless, Minerva, Vector, MonoBook, Modern.
Modern skin fails to load WTE2017 (enable "New wikitext mode"): unrelated.

Change 572876 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/extensions/CodeMirror@master] Fix the font-family: monospace; caused font-size mess-up and remove the unnecessary padding in MinervaNeue skin.

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

Demian moved this task from Backlog to Change CSS on the CSS board.

Unreadable 13px font-size.

I don't think 13px counts as unreadable.

Readable 15.2px font-size (inherited from the skin).

Monospaced textarea's have never inherited the font size from the content area or UI, I don't see a need to change that generally.

If Timeless wants to override the mw-editfont-* rules then it should do so within the skin itself.

Unreadable 13px font-size.

I don't think 13px counts as unreadable.

In Timeless, where the base font-size is 15.2px, this small font-size is not editor-friendly (try it).. The purpose is to provide an easy-to-use editing interface, for that it should be easy to read.

13px is close to Vector's 14px article font-size and MonoBook's 12.7px font-size, not an issue there. Minerva has its own way to inherit the default 16px.
Good:

WTE2017-tiny-font-Minerva-good-size.png (1×1 px, 189 KB)
WTE2017-tiny-font-Minerva-good-size-2.png (798×1 px, 95 KB)

Bad vs Good:

WTE2017-tiny-font-bug-Timeless.png (734×1 px, 182 KB)
WTE2017-tiny-font-VE-good-size.png (812×1 px, 295 KB)

Readable 15.2px font-size (inherited from the skin).

Monospaced textarea's have never inherited the font size from the content area or UI, I don't see a need to change that generally.

WTE2017 does not use a textarea.

Note, that editors should follow the "Edit area font style" setting in https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-editing
In this case, using monospace regardless of that setting is also a bug that I haven't spent time to report and fix.

Also note that WTE 2010 and 2017 in Minerva (16px) and Visual Editor in all skins does inherit the default font-size (try it.).

If Timeless wants to override the mw-editfont-* rules then it should do so within the skin itself.

Note that Timeless is currently unmaintained and won't fix in the foreseeable future this and other bugs reported (and patched) recently.

This is a bug in WTE, not Timeless. A css class that has the font in its name, should not choose a font size, that's a different concern.
The 13px value chosen is historical, arbitrary: this is the value closest to what browsers force when using font-family: monospace;.
Also note that this patch only affects WTE 2017, which is used by very few people. WTE 2010 is not affected: there is a font-size: 13px style attribute on both the textarea and the sibling .CodeMirror element.

I would rather we kept the same font-size between the various wikitext editors for now. There may be a case to increase it for serif, but that will affect a very small number of users who ever change that preference.

CC @matmarex @Volker_E

I would rather we kept the same font-size between the various wikitext editors for now. There may be a case to increase it for serif, but that will affect a very small number of users who ever change that preference.

Thank you for the various feedback highlighting use-cases that were affected by the first proposal.
This is Work-In-Progress now to reevaluate the approach.

I've added fixing this bug in Timeless as a subtask. This ticket is no longer a bug report, just a normal ticket. I'd suggest changing the type as I don't seem to have that option.

This is not a bug in the rest of the 5 active skins, but a weird, inconsistent css rule that I'd like to discuss:

  • in MonoBook it makes the editor font-size 0.3px bigger (probably nobody noticed or cared).
  • in Modern the editor font-size is the same as the article's.
  • in Vector the editor's font-size is 1 pixel smaller than the article's.
  • in Minerva this is circumvented by setting paragraph font-size to the default, which is counterintuitive.

The focus is the inconsistency in relation to article font-size. The css rule affects all skins, but it is made for Vector, specifically.

JTannerWMF moved this task from Untriaged to Freezer on the Editing-team board.
JTannerWMF added a subscriber: JTannerWMF.

Thanks for bringing this to our attention @Demian, unfortunately, we can't prioritize this at this time.

@JTannerWMF thanks, there's not much to do about it atm. The only severely affected skin is Timeless.
The child task T247325 has a ready, tested patch for the Timeless skin, awaiting review, that can be merged.
The rest of the skins aren't noticeably affected by this for various reasons.

Demian renamed this task from 2017WTE uses 13px font, while VE uses the skin's default to WikiTextEditor uses 13px font while VisualEditor uses the skin's default.Jun 15 2020, 12:18 AM

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 605435 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [WIP] [CSS] Make source editor font-size relative to browser font-size

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

Change 605442 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] [CSS] Move 'mediawiki.editfont.less' into 'mediawiki.less'

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

Change 605443 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [WIP] [CSS] Serve .mw-editfont-* styles on all pages

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

Demian moved this task from Freezer to Next Quarter on the Editing-team board.
Demian changed the subtype of this task from "Bug Report" to "Spike".

The issue of inconsistent (tiny) font-size came up in DiscussionTools reply-widget: T251469: Evaluate how the text in the input window appears.

There are some software design decisions to be made, therefore setting this task to spike and CC @Esanders, @matmarex.

The font-size used in the text editor should adapt to the base font-size used by the skin. That's 14px for Vector, 15.2px for Timeless, 16px for Minerva. (Can also be changed by browser setting and user styles.)

The .mw-editfont-* styles involved are

  1. defined in core's mediawiki.editfont.css
  2. loaded by VE and DT asynchronously when the tools load - after the skin's stylesheets, thus overriding rules with the same specificity.

I've submitted patches that approach this from 2 different angles:

  1. in core: making the editor font-size relative to the skin's font-size (90% for monospace, 100% for serif and sans).
  2. in skin: setting exact font-size for editor, in DT: not including the font-size rules in the extensions's bundle, thus not overriding the skin's preference.

These aren't mutually exclusive, the two can be combined.

Please discuss the approach to take.

Demian renamed this task from WikiTextEditor uses 13px font while VisualEditor uses the skin's default to [SPIKE] How to make source editors' font-size responsive.Jul 6 2020, 4:08 AM
Demian raised the priority of this task from Low to Medium.
Demian updated the task description. (Show Details)
Demian set the point value for this task to 3.

Change 609797 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [DEMO] Font update: Use default 16px article font-size in Vector

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

Wrong task ID, patch belongs to other task.

[Resetting assignee due to inactive user account]

I would rather we kept the same font-size between the various wikitext editors for now. There may be a case to increase it for serif, but that will affect a very small number of users who ever change that preference.

This. VE should just do whatever the other editors do/remain consistent with the skins themselves, if even applicable (a lot of them don't really seem to care to begin with).

Now I might have some unhappy words about CodeMirror, but as far as I'm concerned, as a skin person, VE is actually doing just fine here already?

Change 605443 abandoned by Jdlrobson:
[mediawiki/skins/Vector@master] [WIP] [CSS] Serve .mw-editfont-* styles on all pages

Reason:

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

Change 605435 abandoned by Jdlrobson:
[mediawiki/skins/Vector@master] [WIP] [CSS] Make source editor font-size relative to browser font-size

Reason:
275 days old wip patch

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