Last modified: 2008-12-25 00:14:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1941 - CSS tweak for Safari
CSS tweak for Safari
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
Macintosh Mac OS X 10.3
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: css
  Show dependency treegraph
Reported: 2005-04-22 02:23 UTC by imeowbot
Modified: 2008-12-25 00:14 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Lingala characters in edit mode using Safari is now failing (133.17 KB, image/jpeg)
2008-12-24 18:49 UTC, Gerard Meijssen

Description imeowbot 2005-04-22 02:23:16 UTC
Safari defaults to a proportional typeface in textareas, which is really annoying when editing preformatted text, tables and so on.  It would be 
nice if  textarea { font-family: monospace; } was added to the default style sheets so that Safari acts like the rest of the world.
Comment 1 Schnargel 2005-06-17 10:24:47 UTC
On the other hand mostly normal text will get edited, where a proportional font is better. If there's a need for a change and for the sake of equal appearance I 
would make it a user preference so everyone can choose between a monospaced and proportional font (hoping all browsers support a font change there).
Comment 2 Ilmari Karonen 2008-12-13 08:50:06 UTC
Fixed in r44528.
Comment 3 Ilmari Karonen 2008-12-13 08:56:24 UTC
Ideally, we should have the ability to vary the font used in the textarea depending on whether the text being edited is preformatted or not.  Absent such fancy tricks, though, monospaced is the safe default, even if it may not look as nice.  It would be a good idea to offer a gadget to make the font proportional again, though.  (This is trivial to do, just override the style with a more specific CSS rule.)
Comment 4 Nihiltres 2008-12-24 01:19:35 UTC
Blargh. This change prevents me from distinguishing en (–) and em (—) dashes in edit mode, which is very annoying. I don't think that we should be switching from the browser default here: this is a non-bug. I'm sure that this issue would ideally be covered by a preferences option, with the default being browser default (because that's least likely to fail for any given browser). Such a preference option would allow people so concerned with tables, who use Safari, to choose for themselves how the interface works without screwing up the user interface for people who edit normal prose. For the record, I prefer multispace despite *plenty* of work with tables.

In the meantime, I'll go fiddle with my monobook.css.
Comment 5 Michael Zajac 2008-12-24 02:23:33 UTC
What the hell?  We're editing English text with markup, not PHP code!  The minority doing table work can paste text into a real editor. 

Now you've made Safari default to 11-pixel Courier in Wikipedia and Wiktionary.  This is far less readable, makes many diacritics (macrons, breves, and háčeks) and some punctuation (tildes and hyphens) completely indistinguishable, and much text in foreign scripts still shows up in a proportional font anyway.

How many editors have been clamouring for this so-called “fix”?  Please roll back the change on English Wikipedia and Wiktionary.
Comment 6 MZMcBride 2008-12-24 03:12:27 UTC
| foooo     = bar
| parameter = baz

Things like that line up in a monospace font. They don't line up in a non-monospace font, which looks ugly. (Not that people should be spending time lining up equals signs, but that's beside the point.)

The reality is that MediaWiki wikis are a mix of both code (template, table, etc.) and non-code (prose, etc.). Every code text editor I've ever used has the default as a monospace font because it makes things easier when dealing with code.

Both Opera and Firefox default to a monospace font. And you can just as easily change Safari's preferences to determine which fixed-width font it uses if Courier isn't your bag.

If there is a clamoring for a textareas to be non-monospace, make a gadget so that Opera, Firefox, and Safari users can enable the option if they'd like to. But for MediaWiki's purposes, I think achieving consistency here is best. Recommend re-closing as RESOLVED.
Comment 7 2008-12-24 03:18:42 UTC
Eh, it was the behavior in Safari which was not normal. The fix pushed out today addresses that and brings all editors into the same "world" with regard to font displayed in the edit area.
Comment 8 Michael Zajac 2008-12-24 09:09:52 UTC
MZMcBride, do you use Safari?  Wikipedia articles are not “code”.  They are text, annotated with markup.  The edit field is not a “code text editor”, but you're welcome to use one.  Safari users have chosen a better designed browser, so you can suggest that we use Opera or Firefox, but please don't deign to bring our browser down to the lowest common denominator.  There is no clamoring either way—we've been happy with our browser for years, until the powers that be deigned to implement this “fix.”  Do you honestly believe that 11-pixel Courier is better than the browser's default?

locke, we don't want to be “fixed” to fit into your “normal.”  
Comment 9 2008-12-24 10:59:05 UTC
Mike, please stop reopening this bug. The bug has been fixed. If you want another change, open a new bugzilla entry. You'll accomplish nothing by constantly reopening this bug. Further, if you believe a proportional font should be used in the textarea for editing articles you should gain consensus on Wikipedia before opening a new bugzilla entry.

Also, it's unhelpful of you to act like you speak for all Safari users when clearly you don't.
Comment 10 Roan Kattouw 2008-12-24 13:47:39 UTC
Of course, people who are really annoyed by the monospace font in the textarea can always change the font in their user CSS.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-24 14:00:50 UTC
Is there any good reason that anything should actually need to line up in MW text boxes?  Templates and tables, maybe, but only a minority of editors work extensively with those.  More often than not, for complicated templates and tables, each item (cell/parameter) is put on a new line anyway.  The only argument I can see here is that it might cause fights as Safari users break other people's pretty-printing without noticing that it was supposed to be aligned in the first place, but this presentational difference has been the status quo since *forever*, and apparently no such fights have broken out.

I don't see why we should be overriding browser defaults here.  Proportional fonts are ugly.  Safari made the aesthetic choice to make textareas proportional, and its users are used to that.  We shouldn't override that decision (or any other platform/browser convention) without a very clear reason.

I'm reopening again.  I'd like to not reclose until we get word from Brion or Tim or someone.
Comment 12 Michael Zajac 2008-12-24 16:05:24 UTC
Locke, was consensus gained on Wikipedia to “fix” this bug in the first place?  I see no evidence that it was filed and resolved under the requirements that you are now placing on me.

And exactly who ''is'' speaking for Safari users? This is aimed explicitly at Safari, but I don't even know that its requester or supporters depend on it.  I've been using Safari as my main browser to edit Wikipedia for 4-1/2 years now.  Who else in this conversation mainly uses Safari?

Roan, the problem is that suddenly Safari's defaults are specifically overridden, and the result is worse.  The proportional font is not a “bug,” it's a ''feature''.  Anonymous editors and the great majority who can't or won't use CSS are being handed a lame deal by being forced to stare at 11-pixel Courier.
Comment 13 EVula 2008-12-24 16:10:23 UTC
As near as I can tell, this is affecting *every* wiki; any argument that this is a good thing and that users should just modify their personal CSS is ridiculous. This really needs to be re-fixed soon.
Comment 14 Michael Zajac 2008-12-24 17:23:39 UTC
According to the discussion at [[w:Wikipedia:Village_pump_(technical)#Textarea_font_change]] this changes the monospace font chosen by Opera and IE6, but IE7 continues to use a proportional font.  It doesn't look like this change was tested nor its effects anticipated.  

How about roll it back, make it work right, test it, present the results, and then see if ''any'' of the ''affected'' editors want this?
Comment 15 Gerard Meijssen 2008-12-24 17:46:22 UTC
How does this change affect the presentation of the ln.wikipedia ?
Comment 16 Gerard Meijssen 2008-12-24 18:49:48 UTC
Created attachment 5617 [details]
Lingala characters in edit mode using Safari is now failing

Safari used to be the only browser that supported the Lingala characters. After the recent change it is now failing.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-24 19:10:16 UTC
Reverted in r45005 due to regression in Lingala plus other concerns raised, pending further review/discussion.
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-24 20:04:04 UTC
Also note that while it would be trivial for individual sites that wanted this behavior to have it, by adding the one line of CSS to their site stylesheet, it's *impossible* for an individual site to undo it without hardcoding different values for different browsers using JS hacks or something.  "Restore browser defaults" is not possible in CSS by any means I know of, and I doubt very much it's possible by some means I don't know of.
Comment 19 Brion Vibber 2008-12-24 21:52:14 UTC
Safari currently defaults to 13pt Courier New for its base monospace font, which IMO ends up feeling too small in the textarea. (It's actually the same height as the sans-serif default, but "feels" smaller because of the difference in widths.)

Given the negative response, and the very very few actual active demands for this change, my inclination is that this isn't actually a problem that needs to be fixed.

People who want to change the font from the browser default can override their user styles in the browser or on-wiki. ASCII art isn't really in "native" use on-wiki and isn't an overriding concern.
Comment 20 Michael Zajac 2008-12-24 21:56:24 UTC
WebKit's (Safari's) [ default style sheet] ([ referrer]) includes <code>textarea { font: -webkit-small-control; }</code>, which resolves to "Lucida Grande" font.  This is a top-notch screen font with the broadest Unicode support.  

Mess with this and you can't help but break someone's capability to enter text in their own language.

Comment 21 Brion Vibber 2008-12-24 22:00:17 UTC
(Note I've closed this bug WONTFIX and am syncing the revert to live sites now.)
Comment 22 Michael Zajac 2008-12-25 00:14:19 UTC
FYI: on Safari/Mac the default monospace font is Courier 13 (Apple's, not MS's C. New), and in Wikimedia's inheritance realm that seems to resolve to Courier 11px when monospace is applied to the edit field.

Note You need to log in before you can comment on or make changes to this bug.