Page MenuHomePhabricator

Setting language to anything other than "en" changes default edit-window font from monospaced to sans-serif
Closed, ResolvedPublic

Description

Setting language to en-gb from en changes the default edit-window front monospaced.


Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54453

Details

Reference
bz53734

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:48 AM
bzimport set Reference to bz53734.
Peachey88 created this task.Sep 4 2013, 5:40 AM

I am unable to reproduce this bug with given information.

I can see this on en.quote, though in opposite direction (probably due to different OS defaults). What I did:

  1. Chromium in incognito mode (logged out, without special fonts settings in the browser)
  2. Open http://en.wikiquote.org/wiki/Special:Random?uselang=en-gb&action=edit and http://en.wikiquote.org/wiki/Special:Random?action=edit
  3. Observe the first page carefully, or type something like ".... [newline] mmmm" in both to check if it is monospaced)

For me en-gb is non-monospaced while the default is.

Also on TWN, https://translatewiki.net/w/i.php?title=Gender&action=edit&uselang=en vs. https://translatewiki.net/w/i.php?title=Gender&action=edit&uselang=en-gb (logged in in Firefox and logged out in Chromium; note that as unregistered user it's only a view source text area).

  • Bug 53832 has been marked as a duplicate of this bug. ***

Is this being worked on? Just how hard is it *not* to change fonts?

Copying my thoughts from bug 39560:

…and here we go again. The textarea on MediaWiki.org has “font-family:
sans-serif;” style inline when using Czech [cs], see e.g.
http://www.mediawiki.org/w/index.php?title=Project:Sandbox&action=edit&uselang=cs

My guess is I9dd87f44 (or
https://github.com/santhoshtr/jquery.webfonts/commit/1f67cf2bf9ac435a6772eb66f080b118c0e10661).

I switched my preferences to make the textarea always use monospaced font,
which seems to stop ULS from messing with the textarea for now.

This is not exclusive to "en-gb". If I change the "uselang" parameter to any of "pt", "pt-br", "zh", "ru" or "ml", I get "sans-serif". The only code which seems to result in monospaced font is "en".

  • Bug 53759 has been marked as a duplicate of this bug. ***
ori added a comment.Sep 8 2013, 7:40 PM

In jquery.webfonts.js:

if ( !fontFamily ) {
    // If there is no explicit font for this language, it will
    // inherit the webfont for the parent.  But that is undesirable here
    // since language is different. So inherit the original font of the
    // element. Define it explicitly so that inheritance is broken.
    // element
    fontFamily = webfonts.originalFontFamily;
}

The logic you're seeing is this:

  • There's no font to apply for this language.
  • If we don't specify a font, the element could inherit a webfont from a parent.
  • So we have to explicitly specify the default font.
  • The default font is the font-family for body, which is 'sans-serif'.

The catch is this: most browsers do not apply inherited font-family styles to form elements by default, as a way of protecting the consistency of input interfaces.

To prevent this special-casing of form elements, you have to explicitly specify:

input, select, textarea {

font-family: inherit;
font-size: inherit;
font-weight: inherit;

}

References:
http://www.komodomedia.com/blog/2006/10/css-trickery-part-5-inheritance/
http://stackoverflow.com/questions/6520689/font-family-is-not-inherited-to-the-form-input-fields

The easy way to fix this would be to exempt form elements in the if ( !fontFamily ) { /* ... */ } block in jquery.webfonts.js.

If we move in the direction of explicitly specifying fonts, it would be arguably better / more correct to specify that form elements should inherit font styles. But the existence of this bug demonstrates that this would be surprising to users.

I think it'd be best to fix it in jquery.webfonts.js and then start a separate bug thread to discuss the second option.

I also note that I think the if ( !fontFamily ) ... check is overzealous; it should only explicitly apply the default font stylings to elements are descendants of elements that have a WebFonts specified. DOM manipulation is expensive, even if it is a no-op from the perspective of the page's appearance. It should be possible to be a bit cleverer about inheritance and only apply the defaults when absolutely required.

The monospace font style applied to the form fields comes from the user agent(browsers) and not from any style sheets. The monospace is undefined for many scripts like non-latin languages. I need to find a solution, that does not affect latin script, but make sure font is actually applied for scripts that does not have monospace defined.

Put it in otherwords, if the language is any script where monospace is not defined, what we see is expected result. But surprising to languages with monospace as the bug report says.

Change 83972 had a related patch set uploaded by Nikerabbit:
Fix monospace font usage for input fields for latin scripts

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

  • Bug 54210 has been marked as a duplicate of this bug. ***

Parser always replaces font-family to sans-serif for <span lang="chu-Cyrs" style="font-family: Bukyvede, 'Times New Roman'>.

Andrey: No idea who your problem is directly related to this bug report... Small testcase welcome (e.g. on a page on test2.wikipedia.org) so others could try to reproduce.

(In reply to comment #13)
A closing doublequote (") is missing in your sample. The correct example:
<span lang="chu-Cyrs" style="font-family: Bukyvede, 'Times New Roman'>abc</span>

<span lang="chu-Cyrs" style="font-family: Bukyvede, 'Times New Roman'">
abc
</span>

(In reply to comment #14)

Andrey: No idea who your problem is directly related to this bug report...
Small testcase welcome (e.g. on a page on test2.wikipedia.org) so others
could
try to reproduce.

https://test2.wikipedia.org/wiki/Bug_53734

Any estimations as to when this can be fixed? It's quite annoying when editing tables and other stuff where it's desirable to put the correct amount of whitespaces in order to better see through the code.

This is being tracked in Mingle: https://mingle.corp.wikimedia.org/projects/internationalization/cards/3719

We have an open patch in Gerrit: https://gerrit.wikimedia.org/r/#/c/83972/

The patch is waiting for more testing and integration tests. The integration test task is currently assigned to Amir, who comes back to work later this week.

Change 89624 had a related patch set uploaded by Amire80:
WIP: Edit area monospace font test

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

Change 89624 abandoned by Amire80:
WIP: Edit area monospace font test

Reason:
Will make another commit.

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

Change 89624 restored by Amire80:
WIP: Edit area monospace font test

Reason:
trying to rebase

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

Change 83972 merged by jenkins-bot:
Fix monospace font usage for input fields for latin scripts

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

Change 89624 merged by jenkins-bot:
Edit area monospace font test

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

Is this bug fixed now?

Works for me now on mediawiki.org. Thanks!