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
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
I can see this on en.quote, though in opposite direction (probably due to different OS defaults). What I did:
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).
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".
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:
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
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>
(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.
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
Change 89624 abandoned by Amire80:
WIP: Edit area monospace font test
Reason:
Will make another commit.
Change 89624 restored by Amire80:
WIP: Edit area monospace font test
Reason:
trying to rebase
Change 83972 merged by jenkins-bot:
Fix monospace font usage for input fields for latin scripts