Page MenuHomePhabricator

Should Mediawiki UI change font-family for textareas?
Closed, DeclinedPublic

Description

The edit box on http://mwui.wmflabs.org/w/index.php?title=Main_Page&action=edit uses a proportional font, while the default for the user setting "Edit area font style" is "Browser default", which is a monospace font.

I did not test this as logged in user, but
.mw-ui-input {
font-family: inherit;
}

is more specific than the style generated by [1] and thus likely to override even explicit user preferences for the font style.

[1] https://git.wikimedia.org/blob/mediawiki%2Fcore.git/9665a657b005f3a5b882efff3dd5faeba73297d2/includes%2Fresourceloader%2FResourceLoaderUserCSSPrefsModule.php#L77


Version: unspecified
Severity: enhancement
URL: http://mwui.wmflabs.org/w/index.php?title=Main_Page&action=edit
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70194

Details

Reference
bz70028

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:43 AM
bzimport set Reference to bz70028.
bzimport added a subscriber: Unknown Object (MLST).

I think .mw-ui-input just shouldn't be applied to <textarea>s. Jon disagreed with me last time I brought it up, though.

I'm agnostic about which font to use in textareas / inputs or whether mw-ui-input should be applied solely to input elements and not text areas.

This is how we are currently using it in projects like Flow though, so it is good to be consistent.

Adding design for rationale and whether they want to rethink it in terms of Flow/elsewhere.

I actually like the .mw-ui-input style for <textarea>s, as you can easily recognize where the focus is. I don't know how many times I tried to select/paste/... text, and it failed because I didn't notice that the focus was somewhere else. It's just the font-family I don't like (and this is probably just because I'm used to that monospace font). But as bug 53734 was considered as major bug, and had 3 duplicates, I don't seem to be the only one who prefers monospace font for the edit box.

past experience shows that people are all but agnostic about font type on the wikieditor screen :)

I think using a monospace font is pretty important for "wikitext" textareas. Trying to place the cursor next to a '[' or, even worse, a '|', in a proportional font can be very annoying. It matters a lot less for "text" textareas (such as the Flow ones mentioned earlier, I guess, although they also accept wikitext input), since there tends to be fewer weirdly-sized characters in them.

Proportional font for the entire body text is also definitely problematic when editing a computer-science-related article with code samples, for obvious reasons. On the other hand, editing a liberal-arts-related article with a monospace font is a minor annoyance at worst. ;)

Bartosz, its a good point, I've changed the bug description to be more neutral until me make a decision on this.

Templates in wikitext are often formated with spaces to align the =-signs (for example [[de:Special:Upload]]). This doesn't work with proportional fonts. But for textboxes that don't take wikitext (at least not as the primary input), I think it is ok to switch to sans-serif (or whatever font is inherited).

(In reply to Michael M. from comment #0)

I did not test this as logged in user, but
.mw-ui-input {
font-family: inherit;
}

is more specific than the style generated by [1] and thus likely to override
even explicit user preferences for the font style.

This is tested. You are correct. The user preference ("Edit area font style") is applied to all textarea elements (textarea {} ), although that does not really match the description. Element selectors have lower specificity than class selectors (.mw-ui-input {} ).

We do not need to apply it to all textareas (that is not what the preference says).

However, we do need to either respect the preference for the main wikitext editing area, or remove the preference.

I suggest we make a .mw-ui-input-wikitext-page secondary class, that respects this preference. It should apply when you're editing a wikitext page (including section editing).

The 'page' distinction is under the theory that Flow will want its own class (without inheriting this font behavior), which may be justifiable considering it's a very different use case (messages with few if any templates as opposed to long pages or sections with templates sprinkled throughout).

(In reply to Matthew Flaschen from comment #8)

I suggest we make a .mw-ui-input-wikitext-page secondary class, that
respects this preference. It should apply when you're editing a wikitext
page (including section editing).

Actually, there should also be classes .mw-ui-input-javascript, .mw-ui-input-css, etc. which always use monospace. I don't think that users who change their settings to use a proportional font actually want this to apply to JS/CSS-code, too.

(In reply to Helder from comment #10)

See also
https://pt.wikipedia.org/wiki/WP:Café_dos_programadores#caixa_de_edi.C3.A7.
C3.A3o

It sounds like it may have been caused by a gadget depending on mediawiki.ui.input. When logged out (implying only default gadgets and preferences), https://pt.wikipedia.org/wiki/Special:Random?action=edit does not show the mw-ui-input styles yet (e.g. blue bar, etc.)

One of the notes there said something about the font size decreasing for them (maybe because the family is different), which is relevant if/when we look at turning this on more widely.

(In reply to Matthew Flaschen from comment #11)

The users affected in that were using this gadget
https://pt.wikipedia.org/wiki/Special:PrefixIndex/MediaWiki:Gadget-fastbuttons
which had a dependency on "mediawiki.ui.input":
https://pt.wikipedia.org/w/index.php?diff=40487124

In T72028#746191, @Mattflaschen wrote:

(In reply to Helder from comment #10)

See also
https://pt.wikipedia.org/wiki/WP:Café_dos_programadores#caixa_de_edi.C3.A7.
C3.A3o

It sounds like it may have been caused by a gadget depending on mediawiki.ui.input. When logged out (implying only default gadgets and preferences), https://pt.wikipedia.org/wiki/Special:Random?action=edit does not show the mw-ui-input styles yet (e.g. blue bar, etc.)

Hmph, same thing just happened again due to changes in InputBox extension (T92496). MediaWiki core is adding class="mw-ui-input" too eagerly, fixing that in T92496. Let's keep this bug about the design. :)

Mattflaschen-WMF claimed this task.

We're going to stop using MW UI in core, which means this is a moot point.