Last modified: 2008-12-25 00:14:19 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.
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).
Fixed in r44528.
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.)
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.
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.
{{Template | 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.
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.
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.”
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.
Of course, people who are really annoyed by the monospace font in the textarea can always change the font in their user CSS.
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.
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.
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.
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?
How does this change affect the presentation of the ln.wikipedia ? Thanks, GerardM
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.
Reverted in r45005 due to regression in Lingala plus other concerns raised, pending further review/discussion.
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.
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.
WebKit's (Safari's) [http://hell.meiert.org/core/css/safari-3.1.2.css default style sheet] ([http://meiert.com/en/blog/20070922/user-agent-style-sheets/ 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.
(Note I've closed this bug WONTFIX and am syncing the revert to live sites now.)
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.
