This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
Confusingly, the page mediawiki:monobook.css is also applicable for MySkin!
I have found the tabs to be extremely confusing. It has taken me 2 days to finally figure out that the leftmost tab is more or less randomly labeled (ok, ok, I know there's logic behind it, but it took me 2 days to figure it out--sort of--). Some of the labels used are not consistent with standard conventions. And the behavior isn't always consistent with standard conventions.
Elf | Talk 17:00, 3 Jun 2004 (UTC)
Most of this isn't changed in the stylesheet.
Angela . 17:53, 3 Jun 2004 (UTC)
Angela, I think you missed the point on #3. To any user familiar with standard interfaces, it looks like a tab, and the expectation is that it will behave like a tab. Elf's observations are on-target. If they are not really tabs, then they should not look like tabs, or else confusion will result. I like the idea of using tabs to get to the various pages associated with the content page, but this implementation needs some work.
There is a somewhat complex relationship between the content page, the talk page for the content, the edit page for the content, the history of the content, the edit page for the talk page of the content, and the history of the talk page of the content. The current tabbed presentation only obscures or confuses that relationship.
The Watch option should be an option box -- as it is under the standard skin. I can't think of any way to present Move other than either as a command button (like "Save page" is now), or as a tool in the toolbox box.
There is, perhaps, a better place to put each of these individual points, but I think we're using this page right now to discuss what the English Wikipedia-specific style sheet should be like. For now, let's keep these all together here. - Rholton 19:22, 3 Jun 2004 (UTC)
Point #1 is very valid. Some more consistency would be nice, why not use 'article' for articles and 'content page' for everything else? (and 'user page' for userpages) ✏ Sverdrup 19:57, 3 Jun 2004 (UTC)
F sourceforge request] would be better. I disagree everything should be done on this page. Changing the interface text is not the same as changing the stylesheet. It will be a lot easier to do if separate discussions are kept on the correct talk pages. Angela . 20:01, 3 Jun 2004 (UTC)
I rather agree with Rholton on #3: since those things are buttons, not tabs, they should look like buttons, not like tabs.
Jorge Stolfi 14:26, 5 Jun 2004 (UTC)
I agree on #3 as well, and would like to suggest something else. I believe that the "watch" and "move" tabs at the top - which are, as has already been said, not rightfully tabs - belong in the toolbox on the left. (It should also be noted that, consistency aside, they are not used very often, at least not by yours truly.) On the other hand, "What links here" and "Related changes" belong alongside the tabs of the top - it would also be nice to be able to use tabs to get back to the article, rather than "< MediaWiki talk:Monobook.css". Other than that, the new skin is truly amazing. -- Itai 13:27, 6 Jun 2004 (UTC)
The look like tabs, but they do not behave like tabs on, say Amazon, or most good sites using them. The most important thing however is that they will not in any near future behave as tabs should because of the relative slowness of the Wikipedia compared to, say Amazon. In other words, though tabs are in theory a great interface facilitator (I agree completely with Steven Krug on this and I think everybody involved with the usability issues should read his slim book Don't make me think, by the way) they should be completely scrapped for Wikipedia. There are a lot of other usability issues, and the Wikipedia should really go through some usability testing with a few think-alouds, but all this is secondary to the tab problem. AlainV 03:58, 8 Jun 2004 (UTC)
I have also been confused by tabs, and still is sometimes. I can't tell exactly why, but the previous comments certainly give good indications. There is room for improvements, but this is probably a very difficult user interface design work. Marc Mongenet 05:57, 10 Jun 2004 (UTC)
It does not have to be so in our case, since we are not a commercial site, depending absolutely on originality and perfect branding to drive all the customers to us and keep them. All we have to do is copy navigation practices on the average of good plain web sites (the average implies getting knowledge but also avoiding lawsuits that occur when you copy a single good site or two), adapt the general things to our variations and test it. Then after testing, do changes and tests again. And that's it. Web navigation design and Usability testing of Web interfaces are not rocket science. AlainV 02:07, 11 Jun 2004 (UTC)
Well, designing something that works well enough, like the current interface, is maybe not rocket science. But designing a really good interface for a site like Wikipedia is rocket science. For instance, while editing this comment, I could select an "edit" link, what does it edit? There is a "search" box with a "Go" and "Search" buttons, what does it mean? What is a "mediawiki"? Marc Mongenet 03:12, 2004 Jun 12 (UTC)
Issues related to default fonts.
Kudos for using relative font sizes. Default is a small font size, however; too small for comfort. So I can change my browser settings for this site but when I then click on an external link, the fonts there are overwhelmingly large. Sure, an experienced Wiki user can change his/her skin, but most readers will be hit and run, looking for info, not to settle in and customize their interfaces. I *like* the sizes of headings; relative sizes are now much clearer between the different levels of headings and much different from body text, esp. with the hairline for the top-level headers. Elf | Talk 17:41, 3 Jun 2004 (UTC)
So--I guess voting has been suggested:
Make body text larger
Body text size is fine
Do not interfere with my prefered font size duly set in my browser settings
See also Let Users Control Font Size in Jakob Nielsen's well-regarded Alertbox usability column.
Can't consider size separately from font family
I think the diff font size could use some increasing as well. Dori | Talk 13:09, Jun 5, 2004 (UTC)
I withdrew my larger vote. On reflection, it's more the greater line spacing than the text size which is the issue for me. Jamesday 20:51, 5 Jun 2004 (UTC)
I think changing the font size of the body of a whole page is always a bad idea. I did not notice the problem immediately because a long time ago I switched to a browser that let me override this kind of web design error... But most visitors use other browsers and visit Wikipedia only for a few minutes: this renders all argument about wikipedia user preferences, user style sheets (!) and so on, null and void. The only way to present Wikipedia in the visitor preferred font size is by not changing it. The current CSS is by construction presenting Wikipedia in a font about 20% too small. Marc Mongenet 04:48, 10 Jun 2004 (UTC)
See also: Wikipedia talk:Serif or sans-serif
Don't specify a font. Leave as browser default
Combine serif texts with sans-serif menus
Arial Unicode MS for characters that are buggy in Verdana, else back to Verdana
For background on the font issues, please see [1] and [2]. The short version is that browsers do not behave consistently today and gwicke is using one possible workaround. But it's not a perfect workaround because it depends on how well the assumptions of the workaround match the specific display you're using. It's to be expected that different people will see different sizes - it's partly a browser/platform/dispaly difference. that is, it's not only people liking different sizes - people may be seeing different sizes for the same settings. Jamesday 07:24, 5 Jun 2004 (UTC)
That’s true—but it does not excuse overwriting the users’ settings... quota
The HTML math looks much worse in the new font. ✏ Sverdrup 11:00, 5 Jun 2004 (UTC)
Everything looks much worse in the new font. quota
These are the font-family settings of the current top ten web sites according to alexa, checked with the firefox dom inspector for body text:
None of them specifies no font-family, none of them serif fonts. Looks like a trend to me. -- Gabriel Wicke 20:36, 9 Jun 2004 (UTC)
Concerning Gabriel Wicke's list… So the "most popular" sites should tell us what font to use here? Well, let's see…
I'm sure you're not arguing that, if Wiki uses sans-serif, it will be massively popular. The fact is, sites become popular because of their content (or their viral infection rate), not because of their fonts. Common users (the ones who wouldn't know CSS from CBS) are completely helpless to affect how a site looks, and are at the mercy of the Powers That Be. If they want the content, they must put up with the format. The most popular sites will almost always be the ones who content is so critical (or so wired-in to basic computer use) that users have little choice about using it; e.g., the Microsoft Strategy that is so amply illustrated by this list.
If you're interested in Wikipedia user opinions, the vote above suggests so far an overwhelming majority want the browser default font, which is serif for anyone who hasn't customized their browser settings. Of course, one should keep in mind that this survey is heavily biased toward users who are Wiki-comfortable enough to…
If these informal Wiki votes were being done in a social sciences course, we'd flunk on our inability to recognize massive systemic biases. And I'd bet good money (if I had it) that the vast majority of non-bold and new users would prefer to keep the interface simple until they get more comfortable with the content and the practices of participating in Wikidom.
Concerning older≠wiser's point, if familiarity breeds readability preference, then serif (which all the browsers use as a default body text font) would be the logical choice unless and until Wiki spends considerably more effort testing article appearances and locks down formats and layouts like the commercial sites do. Since the latter is absurd and the former ain't gonna happen soon, I again recommend we make the old Standard skin (with its serif fonts) the Wiki default skin. This prevents no one from selecting a fancier skin or changing any skin's font or other CSS attributes, but it puts the onus of extra work on the people who are prepared for and knowledgeable about it, not those who have enough trouble just learning to use Wiki. -- Jeff Q 05:13, 10 Jun 2004 (UTC)
What we're doing currently:
Keyword basesize, 123% Verdana/Bitstream Vera Sans/sans-serif
Only sans-serif specified (defaults to Arial in IE), else the same. Arial is harder to read for a given nominal size, appears at least 10% smaller. Certainly needs compensation if kept, but those using Verdana would have too big fonts then.
Same in Firefox linux, default font for sans-serif is Bitstream Vera Sans:
This is my proposal if we should keep the sans-serif/Arial setting
No font size specified at all, browser setting is used
'Medium' font size in IE (can't be adjusted apart from those larger/smaller steps)
--
Gabriel Wicke 14:13, 5 Jun 2004 (UTC)
The italics are very difficult to read (most prominently perceived in the Recent Changes edit summaries) KRS 17:38, 13 Jun 2004 (UTC)
If anyone else is bothered by the H3 level being bolder than H2 the following will fix it:
Don't know if it should be applied en-wikipedia-wide. Dori | Talk 13:53, Jul 12, 2004 (UTC)
The main problem I've seen here is that visited edit links are the same colour as visited articles. Which means if you have clicked on an edit link it is no longer possible to tell whether the article exists or not. -- sannse (talk) 17:49, 3 Jun 2004 (UTC)
I would suggest the colour scheme presented at Wikipedia:Village_pump#Link_colours as best, which also seems to address sannse's problem. -- Michael Warren 18:00, 3 Jun 2004 (UTC)
I'm not sure about stubs, but the other default colours were: a { color: #0000FF; } a:active, a:visited { color: #800080; } a.new { color: #CC2200; } a.interwiki, a.external { color: #3366BB; } - which is slightly different from the example mentioned above. This doesn't solve the visited edit link problem though -- sannse (talk) 16:49, 4 Jun 2004 (UTC)
While the default colors look normal on other pages, because of the shady backgrounds they look excessively bright on the Wikipedia pages. So, either change both foreground and background, or leave it be. Personally I think that the somewhat shaded backgrounds and text colors are fine. At one point we had something that was too pastel to be readable, but it's pretty much okay nowadays. -- Shallot 00:09, 4 Jul 2004 (UTC)
Return to MediaWiki 1.2 defaults
Don't return to MediaWiki 1.2 defaults
No icons by default
Icons by default
Other
I was among those who voted for underlined by default (I have since changed my mind), but now there is a bug and removing the check from the "Underline links" option does not change the behavior. Should we force it on users this way (this also seems to negate browser settings)? Dori | Talk 03:48, Jun 4, 2004 (UTC)
Yes this awful. If I want underlines on links I can set my browser to put them there. Why on earth does Wiki force the ungly things on users? Shall we change italic emphasis to all-capitals, next? And, as a next step, monospace fonts everywhere (green, on a black background, of course). quota
I wish I had known of a vote. This is disastrous! Little horizontal lines everywhere cutting through the text! AHHHHHHHH! My browser's no-underlining of links is even superceded by this! Ackbar! -- AquaRichy 07:04, 4 Jun 2004 (UTC)
a { text-decoration: inherit }
? --
Gabriel Wicke 10:45, 5 Jun 2004 (UTC)/* remove the ugly, recently-reinstated link underlines */ a { text-decoration: none; } a:hover { text-decoration: underline; }
My vote is that link underlining in the default skin should respect the user's browser settings. Ditto for link colors (except of course for the external and missing-article link colors, which are not defined by the browser and so must be chosen Wikipedia.) Jorge Stolfi 13:16, 4 Jun 2004 (UTC)
(moved from the village pump)
I've had link underlining turned off in my preferences for some time now, and yet as I use WP it seems to turn on and off, apparently at random. Surely this is happening to others? – Smyth\ talk 15:43, 23 Dec 2004 (UTC)
Okay, I have determined a pattern:
So we seem to have that refreshing always results in a nonunderlined page, while normal browsing randomly tends towards an underlined one.
I realise some or all of this problem may be client-side, in which case I'd be glad if someone explained it to me. I use Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Galeon/1.3.17 (Debian package 1.3.17-1)
. –
Smyth\
talk 15:58, 23 Dec 2004 (UTC)
Its good that the underlining has gone out of the monobook format. However, the blue has gone back again to being light blue. It was/ is very tough to read the light blue becuase of the lack of contrast, the darker blue was much more readable. Also the continuity between words in a page will be better if the colours are closer in value ( meaning dark/light). Now the continuity is not there. For all these reasons can we have a dareker colour please?
Is it under discussion? Can we have a page in which all the changes are recorded for the four major schemes when a change is made by the developer/ user who makes the change so that we can give our comments? The reactions are very scattered and no one seems to counterreact for any reaction. KRS 11:17, 10 Jun 2004 (UTC)
P.S. the top tabs are of a darker blue with a good contrast. Either the same shade can be used(it looks like cobalt blue/slightly like ultramarine blue)in the place of all the lighter blues or if a different one is required then Prussian Blue can be used. Or the top tab can be the lighter blue( there is very little of it, only a few words) or Prussian blue and the rest can be the colour which is now the top tab colours.
Ideal design - Background Vs. words should have the most contrast, non linked words vs linked words should have a contrast that does not affect too much the continuity of the reading process and is lesser than the background vs. words contrast. What exists now- background vs. link contrast- too less, link word vs. ordinary word contrast too much. KRS 11:31, 10 Jun 2004 (UTC)
For some strange reason, clicking on an article link that I haven't visited before causes it to sprout an "external link" icon behind it (possibly rearranging the paragraph as it shifts the following text over).
This link isn't there if I reload a page, so it's not simply a "visited link" indicator. I assume this is a bug? -- pne 08:04, 15 Jun 2004 (UTC)
(Non-article = talk:, as well as user:, wikipedia:, special:, MediaWiki:, template:, category:, and their talk pages)
Should be the same color as other non-article pages
Should be the same color as article pages
Yet a third color (suggest one if you like; not part of poll)
Recently, as viewed by me with Safari 1.2.2, the text on certain pages, including this one, has acquired an annoying light-blue background tint. I find this quite irritating. I work quite hard to get all the monitors I use set for a pleasing-to-me color temperature of 5500 degrees, and I do not want Wikipedia undoing this by adding bluish casts to my nicely-tuned white. It reminds me of a magazine I read as a kid called "Children's Digest"—does it still exists\?—which was printed on a sort of light-snot-colored paper that they insisted was "eye-ease paper." How can I turn this off? Dpbsmith 11:16, 4 Jul 2004 (UTC)
I don't know why but the little person icon bugs me. It ought to go. When I see something like it on a web page, I brace myself to see some links titled "Solutions", "Partners", etc. -- Yath 10:06, 5 Jun 2004 (UTC)
/* supress the person icon by your username */ li#pt-userpage { background: none }
blankfaze | •• 23:26, 5 Jun 2004 (UTC)
Please have the server insert HEIGHT and WIDTH tags for images so the page doesn't jump around when it is loading. -- User:Juuitchan
Try it yourself. Log in, and links are underlined, log out, and they are not. This is useless, I think we should give up changing the default skin if we are not changing it for everybody, it's just silly to log in and discover 20 small tweaks that make the overall UI much better. ✏ Sverdrup 07:54, 4 Jun 2004 (UTC)
.pBody a { text-decoration: none; }
#bodyContent a { text-decoration: underline; }
I expect that this will eventually change to reflect the decision here, since we are trying to decide what that default look should be. Jamesday 20:30, 5 Jun 2004 (UTC)
Monobook's line heights are just too big in tables and in the side bar. Reducing them to 1em or 1.2em gives a much better layout. Lupo 09:08, 4 Jun 2004 (UTC)
[[Image:MiniDachshund1 wb.jpg|thumb|right|Black and tan Miniature smooth-haired dachshund]]
The votes on the images can be found at Meta:Thumbnailed images archive for the overall appearance and Meta:Thumbnailed images/Feature Poll. Preferences for white (same as page) or pastel (different from page) border color were 50-50 split; the icon for the link to image description page is the one being used, a magnifiying glass for a "bigger version" of the image was favored but "bigger version" isn't implemented. Jamesday 20:39, 5 Jun 2004 (UTC)
the excessive border elements have caused me to not use |thumb| in many cases. Badanedwa 23:42, Jun 24, 2004 (UTC)
I find having the interlanguage links at the bottom of the sidebar a nuisance. Part of Wikipedia's strengths is the fact that many articles exist in several languages, and we should emphasize on that, not hide it! (I usually have to scroll—and I have a big screen!— to see them.) It would be relatively easy to have them back at the top of the article, either above the top "tabs" or just below them, but above the first header. Lupo 09:08, 4 Jun 2004 (UTC)
I like them in the sidebar and would hate to have them back at top. Some articles have dozens of languages linked, meaning users with low resolution monitor settings would have half their first screen being a list of links to different language versions of the article. -- mav 04:35, 12 Jun 2004 (UTC)
It appears to me that the option of printable pages has disappeared. They also appeared to be the most saveable pages (if I wanted to save the article). Not popular enough? - Nilmerg 11:59, 4 Jun 2004 (UTC)
Now that the blue is darker, it is much better. However, the contrast between unvisited and visited links is almost nonexistent, the violet has to be made darker or a different hue altogether can be tried.
By the way, what's with the underlines for links suddenly appearing and as suddenly disappearing? KRS 13:20, 4 Jun 2004 (UTC)
While section editing is really convenient for serious contributors, they are distracting for people trying to read the encyclopedia. Not only do these people have keep reading "edit," attempts to copy/paste the text will also copy in the edit link. A serious contributor is most likely a user and and serious reader is most likely not logged in. Please do not make section editing available for anons. -- Jiang 21:44, 4 Jun 2004 (UTC)
*.editsection { position: relative; top: 1em; }
I know this goes beyond CSS, but I would like a div element containing the whole editable section. (Actually, most of this section would need changes in the HTML too.)
Alternatively, we could just disable section editing for anons in the article namespace and leave it available elsewhere. -- Jia ng 21:10, 28 Jun 2004 (UTC)
I am REALLY, REALLY happy with the new Monobook skin and MediaWiki 1.3, especially after instituting several User css changes. I like the skin, I like the font changes, and like the new features.
However, there is one nagging problem that I have. In the old software, there was edit/history/watch/whatlinkshere links at the bottom and side of the page. Now they're at the top only. I would really like to see these links at the top, bottom, and side, or AT LEAST at the top and bottom.
I've found often that when reading an article, especially long ones, I find myself looking intuitively for the link at the bottom. This is a small problem, but a nag nonetheless.
Anyone else have feeling on this? blankfaze | •• 05:37, 5 Jun 2004 (UTC)
Yes
No
Maybe
I was looking for a place to ask about this - finally I've found one! I have seen a new style page, when I logged in to Wikipedia from work or from the local library - but it is inconsistent. Sometimes you get it, sometimes you don't.... What's going on? I assume this is to do with a new stylesheet that you're trialing - is there any info posted anywhere?
For the record, I'm logged in at home using Safari 1.2 on Mac OSX 10.3.2. At work inevitably they use Internet Explorer on Windows ('98, I think).
If it is a Mac OSX compatibility issue, perhaps Mac users ought to have the opportunity to comment about the so-called "new look" - at some point!
Agendum 17:30, 5 Jun 2004 (UTC)
I notice the liberal use of the word "obvious" in this debate on styles. I feel compelled to suggest that the word "obvious" almost never applies in a discussion among a diverse population. When someone calls something "obvious", it nearly always says more about their own background and biases than about any universal truth. -- Jeff Q 05:29, 9 Jun 2004 (UTC)
The larger space between lines not only disturbs some text all by itself, but it has secondary effects as well. The 1.3 software apparently changes how ends-of-line and blank lines are handled. Under 1.2, a newline (in the generic sense) would break a paragraph, indented line, or list item without adding extra whitespace between lines. One or more blank lines would do the same, but add a blank line between. Thousands of pages count on this formatting.
Under 1.3, the single line-break gets absorbed into the previous paragraph, for ordinary text. (I think this is bad, based on existing use, but I can see the argument for it.) However, because of the new style, indented lines and list items are properly broken but get a virtually-undetectable difference in separating space based on whether they have single break or one or more blank lines. This causes major problems for some text, like the following two dialog segments from Wikiquote:Buffy the Vampire Slayer:
Under 1.2, it was clear these were two separate quotes. Under 1.3, you can't really tell where the division is without looking closely or considering the context. (The confusion is even more apparent when looking at a long list of these quotes.) I used this Wikiquote example because it's compact, but List of self referential songs is a great Wikipedia example of a page whose size seemingly tripled and became horribly mal-formatted using the new software and styles. Any page that uses indented lines for song excerpts and/or HTML "pre" style formatting, and any page that counts on the difference between single line-breaks and blank line spacing is going to suffer from these problems.
This is all because someone thought that extra space looked nice using the new font that is also such a hot point of contention. Please keep the customizations and whimsical style choices out of the default style! -- Jeff Q 05:36, 9 Jun 2004 (UTC)
dd
element (definition data) which was intended for defining a term; when the colon is used without a semicolon, you essentially have a definition with no term, used purely for the purpose of achieving some indentation. Unfortunately, the only other sort-of appropriate HTML tag we have is blockquote
, which is block-level and cannot be nested (which makes it useless for nested indentations like we use on talk pages). It'd work for quotations like the Buffy one above, though. (Do we have wikicode for blockquote, or does it have to be in HTML?) There's
a little discussion of this on meta. I agree with you, Jeff, that whatever style attributes are screwing up the spacing should be eliminated, until we use definition lists only for things that are actually definition lists; it plays havoc with the other things we're using it for at the moment. --
Wapcaplet 17:53, 12 Jun 2004 (UTC)A meta-comment: note that the graphical beauty of a document matters only when a new user opens it for the first time, and then only before he or she starts reading the text or using the buttons. After that fleeting moment, only three things matter: readability, readability, and readability.
That is why any book that is meant to be read (and not just looked at) is printed with serif fonts, black on white, with little or no decoration. Even a simple rule at the top of each page will begin to bother the reader, subliminarly, after a few dozen pages. That is why good books have "clean" page layouts, and no frames around illustrations and figure captions.
Graphical decoration is ok when it conveys useful information such as section boundaries, list items, links, etc.. However, the most efficient clues for that task are spacing and indentation, then font size and weight. (One serious problem with the current Wikipedia layouts -- both "monobook" and "standard" -- is that the spacing below sub-section headers is just as big as that below section headers.) Marking off sections with rules or color bars may already be in the negative payoff zone, more distracting than helpful.
Sans serif fonts look better than serif ones, which is why they are used in advertisements, brochures, flyers -- and their WWW equivalents. The neat looks of a sans-serif text are good at catching the attention of passers-by, which is THE main goal of avertising. However, compared to serif fonts of the same height, they are noticeably harder to read. That is not a problem in advertising, where the text has to be short and eye-catching -- but is a major problem for texts longer than a couple of paragraphs.
As I see it, the negative reactions to the monobook skin (above) are due not to locally fixable bugs, but rather to a single global problem: the skin was not designed for readability, but only to look nice. For example, the increased font size and line spacings give it a neat and "airy" look, but they also mean that less text fits in the page, which is bad. (BTW, the standard skin too wastes screen estate with all that whitespace between paragraphs.) Ditto for the subtly colored links without underlines: they make the page look cool, but make it hard for the reader to notice the link.
Whikipedia pages need not grab the reader's attention, but must be easy to read; thus they should be optimized for readability. The standard skin was already close to optimum in that regard; the only improvements I can think of are: (1) reduce the inter-paragraph space (2) reduce the space after subsection headers, (3) reduce the Wikipedia logo image to half its current size or smaller (except on the main page). Changes in other items, like like font and link colors, are more likely be for the worse than for the better.
All the best,
Jorge Stolfi 00:37, 10 Jun 2004 (UTC)
I'll admit that I don't care much for the new default look, so I excercised my freedom of choice & stayed with the old standard look. However, doing so has led to some issues:
Thanks, llywrch 04:45, 12 Jun 2004 (UTC)
I love the new skin, but I've also grown to love having the quickbar on the right side. Is fixing this feature planned? Or is it not being implemented for some specific reason? -- Danny Rathjens 09:00, Jun 12, 2004 (UTC)
Sannse and I were talking or IRC about the effect that the ability to have one's own settings might mask some site-wide problems. What is meant by this is that people find a problem, they are told to fix it in their own monobook.css, they do and they forget about it. New users are left out as they don't know about the many fixes that crop up. Ideally, the worst problems should be fixed in the site-wide file. Unfortunately, the only way for this to work out would be for people to keep having votes on changes. Also, at which point do we implement the changes that are supported? Have some of these changes been rendered moot because things have been fixed on the project-wide (main.css) file? Comments, opinions? Dori | Talk 13:50, Jun 12, 2004 (UTC)
The main page uses hardcoded background colours for the featured articles, the table at the top of the page [that says "Welcome Newcomers"], and the In the News box. As a visually-impaired user who prefers light colours on dark colours, this interferes with my ability to view Wikipedia. Please consider moving the background colours and formatting into the CSS sheets. Aphrael Runestar 00:59, 2004 Sep 14 (UTC)
I've seen quite a bit of fulmination here about how much more readable serif faces are as compared to sans, usually with a none-too-thinly-veiled hint that the rest of us are idiots for not knowing this.
No question that it all sounds completely logical. The serifs, we are told, are like little hooks, you see; they serve to "guide the eye" along the line of text, making reading easier. One imagines the eye, cleverly fooled by these little curlicues into following the straight and narrow path and digesting the words as easily as if they'd been lubricated with cod-liver oil. From screen, to brain, with a minimum of interference.
It's perfectly intuitive. Unfortunately, it's not like that at all.
We have an intuition that reading text should be something like listening to speech: a linear and serial process, moving ahead left-to-right as we listen to speech from past-to-future. We imagine that the brain sees a word, say "rutabaga", and grasps it first letter-by-letter, always strictly left-to-right, before putting together the word as a whole: "hmm, there's an 'r'... and a 'u'... and a 't'...."
But the eyes do not scan text like an old-fashioned typewriter, going left to right in a horizontal straight line, then snapping back to the carriage return and repeating. Studies with eye-cameras (devices that watch you watching something else, calibrated so that they can show the path your eyes take over a page like the chalk drawings of a football coach) have proven this conclusively. Your intuition that you read this way is irrelevant; a few minutes looking at optical illusions should prove to you that what you consciously think your eyes are doing has little bearing on what they actually do.
Instead of this imagined linear, repetitive process, the eyes actually do something far more interesting. They first sweep over an entire chunk of text consisting of two or three lines, in a vaguely flattened diagonal direction, from upper-left to lower-right, to get a general sense of orientation and bearing. They pause and fixate briefly on guidepost elements like punctuation, boldface and italics (and, one would assume today, links as well) and capitals, getting the overall sense of the "shape" of the chunk being read. Then they hopscotch from word to word, reading them, not letter-by-letter, but by overall shape and "color" (meaning the overall amount of grey defined by the black and white of the word's letter shapes). The eye then makes repeated passes over words that aren't recognized in this fashion, making whorls and spirals until finally, yes, reading letter-by-letter for unfamiliar words. But the point is, for most words we "read" in body text, we don't read them letter-by-letter at all.
This is why when we misread words, we misread them as other words, not as jumbles of letters. It's aslo why we do so well raednig wrod jmubles when the oevraell shape of the word — as defneid by the fisrt and lsat letters, alnog with the plceamnet of the acesnders and dsecneders — is held cosnsitent.
If serifs truly performed the function claimed, to guide the eye along the line of text — and if that were actually a desirable function in reading body text — one would imagine the type of triple-ruled text one sees in first-grade reading textbooks to be the easiest text to read of all. But it isn't; to the contrary, for an accomplished reader, it's maddening.
Putting aside the question of overall readability of serif versus sans faces (and I think the argument can be made that evidence does not show serifs are even more readable on paper), Wikipedia is not the first website to grapple with the question of which is more readable on-screen.
In reviewing examples online of sites and institutions that have made a determination on the serif vs. sans question, one is immediately struck by a fundamental difference. Those that come on the side of serifs do so by fiat, simply repeating the conventional wisdom that "serifs are more readable." They often give as evidence the "fact" mentioned above that the serifs "guide the eye."
While there are cases of sites coming down on the sans side for equally erroneous reasons (sans faces are "cleaner" or "more modern"), many sites have decided on sans because of usability studies — i.e., they have tried both in labs and have discovered which work best. A few examples:
I strongly believe that logged-in users should have a choice in the matter. If they believe that serifs work better for them, then they should be able to see serifs. I'm not myself a good enough web designer to know whether building a beautiful website precludes just letting browser options rule, though I know several web designers who assure me that that is unfortunately the case.
There are readability questions that are clearly answered by evidence — for instance, that extremely wide columns of text are more difficult to read than narrow ones, or that proportional typefaces are more easily read than monospaced ones.
But can we please drop this old chestnut that serif faces are always more "readable" than sans? The conjecture has no evidentiary basis.-- TreyHarris 00:54, 13 Jun 2004 (UTC)
Trey, I was not arguing from ideology, but from experiment. Sans-serif in sites like Google never bothered me, but I tried standard and monobook in Wikpedia, and I defintely find standard easier on the eyes. (For one thing, monobook's table of contents is too big.) That may be true just for my browser and font settings, I don't know. Ditto for the background color - white works best for me, and I see no flicker. Perhaps it also has to do with my CRT's resolution and refresh rate?
Jorge Stolfi 06:54, 13 Jun 2004 (UTC)
I would like to vote for serif fonts to at least for article text. I won't quote any readability studies, I'll just say that I found Wikipedia harder read after the font change. More important however is the fact that any article is extremely wide by default. It should probably be changed to something a lot less wide. (Maybe we can have articles in 2 column modes)
Previously, the sans-serif default resulted in in-line equations that clashed with the serif font used by TeX for equations. I noticed today that inline <math> now uses a serif font, but there are still problems.
Please just stick with the browser default typeface and point size, which seems to be the overwhelming consensus here. This will use a consistent serif font for the vast majority of users, and those users who want to play with fonts can muck around with stylesheets.
—Steven G. Johnson 16:32, Jun 13, 2004 (UTC)
Yesterday, I could recognize which words were changed in an edit-diff. Today I can not. Is there some preference I ought to change to get this feature back again?
--
Ruhrjung 02:51, 2004 Jun 12 (UTC)
.diffchange {color: red;}
#content
and #sitesub
as top-level tags: should it be within one of those? (You will gather that my knowledge of CSS is strictly limited, much like I assume the majority of Wikipedians :-) --
Phil |
Talk 14:36, Jun 21, 2004 (UTC)Holy, somebody just changed the diff to a ginormous fontsize! How can I change it back? ".diffchange {size: NOT-OVERSIZED"? ;-) -- Menchi 03:48, 12 Jun 2004 (UTC)
<span style="color: red">diff text goes here</span>
<span class="diffchange">diff text goes here</span>
Was the recent drop in the font size in the two parallel diff text columns (using Standard skin) part of this change? It suddenly became smaller and now I have to lean forward in my chair to peer at the screen and see what changed. Was that discussed anywhere? Can I change it back on my own? –Hajor 13:36, 12 Jun 2004 (UTC)
Polling on this page started on 3 June so I strongly suggest that items with 75% or more support on 3 July will be implemented that day. We can, however, continue to vote and may even change some settings based on new votes. -- mav 05:26, 26 Jun 2004 (UTC)
Something in MediaWiki appears to be broken, and
this change makes it much more apparant. The styles in
MediaWiki:Monobook.css are being imported even though I'm using "MySkin", not Monobook. Since this file now overrides my default background and link colours, but not some other things, everything looks quite awful. Would it be possible to revert these changes until the MediaWiki bug is fixed, or perhaps move them to MediaWiki's style/monobook/main.css
where they'll only affect Monobook users?
—Lady Lysiŋe Ikiŋsile |
Talk 15:51, 2004 Jul 3 (UTC)
테스트
Somehow related: how can I set my favourite colors for non-article backgrounds overriding the mediawiki:monobook.css in my User css? The copy, paste and change the color value method doesn't work. -- till we ☼☽ | Talk 23:03, 6 Jul 2004 (UTC)
I don't understand why the message "From Wikipedia, the free encyclopedia" was ever removed from the monobook skin. Are there any objections to adding it back in using #siteSub { display: inline; font-size:120%;font-weight:normal;}
? It already appears in the other skins.
Angela
. 06:19, 16 Jul 2004 (UTC)
I suggest ca-edit a{font-weight:bold !important;}
is added to make the "edit this page" link bold. This is being used on the
German Wikipedia and makes it more obvious to newcomers that they can edit a page.
Angela
. 11:11, 17 Jul 2004 (UTC)
It's a good change I think, the edit link had somewhat disappeared with the new skin -- sannse (talk) 20:00, 21 Jul 2004 (UTC)
What would be the proper procedure for proposing a change to font colours (as this has already been voted on)?
Acegikmo1 17:40, 23 Jul 2004 (UTC)
Can we make the monobook css file include autoflow for pre sections? The bottom one is autoflowed:
IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF this is useful for: * pasting preformatted text; ENDIF
IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF this is useful for: * pasting preformatted text; ENDIF
If you resize your window so it wraps, you can see that the bottom one has a scroll bar instead of resizing the whole page uglily with an overlapping border. I know I can put this in my personal monobook.css (and i will) but it should be global shouldn't it? - Omegatron 17:04, Aug 2, 2004 (UTC)
There are workarounds for IE. Setting the width of the pre section sort of works:
WITH pre style="{ overflow:auto; width:95%; }" IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF this is useful for: * pasting preformatted text; ENDIF
SAME PRE STYLE BUT WITHOUT A LONG LINE IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF
http://www.magpiebrain.com/archives/2004/04/19/ie_and_overflow_auto gives a better description. - Omegatron
Also I think the old and new columns of the diff page should each be put in a div, which could be autoflowed, to avoid long foreign page names making the diff page super wide. I tried just doing it with CSS, but each line is a different table cell, so it wouldn't really work, giving each long line its own scrollbar. - Omegatron 14:16, Aug 10, 2004 (UTC)
On hi.wikipedia.org the default of monobook skin is not working correctly. I had to go change it to an older 'blue' to be able ot use the links. I like the monobook style - if it would work. What do I need ot change. I see references to 'user can change' the .css files - where are these. I tried using the myskin option under preferences and got a while linear page without any formatting. Any help - pointers about some basic discussion about this topic would be helpful. Shree 17:09, 11 Aug 2004 (UTC)
MSN TV may garble pages.
MSN TV Viewer 2.8 (Build 20) fails spectacularly due to its willingness to @import and subsequently destroy stylesheets. Additionally, an @import that again performs an @import will so confuse the engine that nothing (worth viewing) renders, such as when the user stylesheet @imports the MediaWiki stylesheet.
Fortunately, MSN TV 2.8 will use only the last @import within each <style> </style>. Thus, a workaround is to gather the @imports into a single <style> </style> with the addition of an MSN TV-safe @import. (In my tests I imported an empty file.)
Ex.
<style type="text/css" media="screen,projection">/*<![CDATA[*/ @import "main.css"; @import "user.css"; @import "null.css"; /*]]>*/</style>
MSN TV will ignore the first two stylesheets and process the third. It may be useful to install MSN TV-specific properties here. (BTW, the software seems to ignore media types.)
Not having the actual device, I was unable to verify if this problem affects the consumer (hardware) version of the MSN TV software. However, I believe the viewer (is said to) accurately represent the actual device software. Can somebody confirm if the actual hardware exhibits the described behavior?
-- John Robinson 09:18, 28 Aug 2004 (UTC) (PS: no idea if this is the right page for this--if not, please help me get it to the right people. Thank you.)
(none)
It looks like
li#ca-watch, li#ca-watch { margin-left: 1.6em; }
should actually be
li#ca-watch, li#ca-unwatch { margin-left: 1.6em; }
— User:Mulad (talk) 06:39, Aug 29, 2004 (UTC)
moved from the village pump
I don't like the new green external links. Please change it back.
Crossposted from MediaWiki_talk:Fromwikipedia#Linking to Main Page —— Please Reply there
Would anyone have any objections to linking "Wikipedia, the free encyclopedia" to http://en.wikipedia.org/wiki/Main_Page ?
Why? Well...
I propose styling the link so MonoBook users simply see it as plain, ordinary text. I can't really see any downsides to this... can anyone else? Tom- 22:07, 31 Aug 2004 (UTC)
Okay, so now someone has switched off the little external link icons, and I want them back. How do I sepcify this in my personal CSS file? -- Phil | Talk 12:03, Oct 1, 2004 (UTC)
I have no objection against using the link color. However, in Mozilla at least, the override results in ugly spaces between links and consecutive characters. This makes the remedy worse than the disease. Unless that can be fixed, please do not override the link icons.-- Eloquence *
I wondered where the icons were too. I don't want to lose them! The arrow icons make it easy to spot external links. change the color if you want, but don't remove the icons. If I didn't want the icons I'd hide them in my monobook.css, but the icons have been around for a while now so people are used to them. the "plainlinks" class already exists for areas where icons are inappropriate anyway. [[User:Norm|No rm]] 19:19, 3 Oct 2004 (UTC)
This section was moved here from Wikipedia:Village pump (technical).
This has actually been an issue for me ever since the new Monobook skin was implemented; I just haven't complained about it yet. I'm sure there must have been others who have experienced this same problem, so sorry about bringing it up again, I just don't know where discussion of this bug is. Anyway, the bug is this: the "Watch" tab at the top of the screen always appears below the other tabs, and then, when I move my mouse pointer over the tabs, all the tabs at the top move away from their horizontal row and instead stack vertically in the top left, just to the right of the Wikipedia globe image. I'm using IE6 on WinXP in an 800x600 res. -- Lowellian 06:59, Oct 4, 2004 (UTC)
Andrewa, unfortunately your workaround didn't work for me. However, your suggestion gave me the idea that it was basically a stylesheet problem, so then I delved into the monobook stylesheet. The odd thing about this bug is that it looks like there's plenty of blank space in an 800x600 res to fit in all the tabs, but nevertheless the display screws up by "wrapping" the tabs for some inexplicable reason. After studying the code for a while, I was able to locate the source of the problem:
#p-cactions { ... width: 76%; ... }
The above line applies only to the tabs at the top of the page, and to no other elements on the page. The problem the width statement creates problems is that 76% of the width of a 800x600 screen is not enough to hold all the tabs. Therefore, I then changed my stylesheet by adding this line to my personal monobook.css page:
#p-cactions { width: 100%; }
Now the tabs display properly in an 800x600 resolution! (Even better: this change does not create problems—or even change the display at all—in larger resolutions. In fact, I don't understand why the stylesheet developers even chose to make the width 76% in the first place; unless I'm missing something, it should always have been 100%. 100% doesn't screw up the column to the left, either.)
Anyway, thanks for the comments. You helped me find a solution.
-- Lowellian 05:25, Oct 7, 2004 (UTC)
Argg, okay, I spoke too soon. There is a slight problem with what I posted above, and now I see why the stylesheet developers chose to post a value less than 100%. It creates blank space to the right of the page, so that in an 800x600 res a horizontal scroll bar will appear at the bottom of the window. However, though 100% does not work, the following does (without being so wide as to create a horizontal scroll bar), and it fixes the stacking tabs problem.
#p-cactions { width: 80%; }
Now it works! (I think.)
-- Lowellian 05:35, Oct 7, 2004 (UTC)
Until your submission is actually implemented, I've added my patch to MediaWiki:Monobook.css. It's a simple one-line patch, and after having tested it for nearly a month, it seems to not create other problems. — Lowellian ( talk)[[]] 07:16, Oct 25, 2004 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
Confusingly, the page mediawiki:monobook.css is also applicable for MySkin!
I have found the tabs to be extremely confusing. It has taken me 2 days to finally figure out that the leftmost tab is more or less randomly labeled (ok, ok, I know there's logic behind it, but it took me 2 days to figure it out--sort of--). Some of the labels used are not consistent with standard conventions. And the behavior isn't always consistent with standard conventions.
Elf | Talk 17:00, 3 Jun 2004 (UTC)
Most of this isn't changed in the stylesheet.
Angela . 17:53, 3 Jun 2004 (UTC)
Angela, I think you missed the point on #3. To any user familiar with standard interfaces, it looks like a tab, and the expectation is that it will behave like a tab. Elf's observations are on-target. If they are not really tabs, then they should not look like tabs, or else confusion will result. I like the idea of using tabs to get to the various pages associated with the content page, but this implementation needs some work.
There is a somewhat complex relationship between the content page, the talk page for the content, the edit page for the content, the history of the content, the edit page for the talk page of the content, and the history of the talk page of the content. The current tabbed presentation only obscures or confuses that relationship.
The Watch option should be an option box -- as it is under the standard skin. I can't think of any way to present Move other than either as a command button (like "Save page" is now), or as a tool in the toolbox box.
There is, perhaps, a better place to put each of these individual points, but I think we're using this page right now to discuss what the English Wikipedia-specific style sheet should be like. For now, let's keep these all together here. - Rholton 19:22, 3 Jun 2004 (UTC)
Point #1 is very valid. Some more consistency would be nice, why not use 'article' for articles and 'content page' for everything else? (and 'user page' for userpages) ✏ Sverdrup 19:57, 3 Jun 2004 (UTC)
F sourceforge request] would be better. I disagree everything should be done on this page. Changing the interface text is not the same as changing the stylesheet. It will be a lot easier to do if separate discussions are kept on the correct talk pages. Angela . 20:01, 3 Jun 2004 (UTC)
I rather agree with Rholton on #3: since those things are buttons, not tabs, they should look like buttons, not like tabs.
Jorge Stolfi 14:26, 5 Jun 2004 (UTC)
I agree on #3 as well, and would like to suggest something else. I believe that the "watch" and "move" tabs at the top - which are, as has already been said, not rightfully tabs - belong in the toolbox on the left. (It should also be noted that, consistency aside, they are not used very often, at least not by yours truly.) On the other hand, "What links here" and "Related changes" belong alongside the tabs of the top - it would also be nice to be able to use tabs to get back to the article, rather than "< MediaWiki talk:Monobook.css". Other than that, the new skin is truly amazing. -- Itai 13:27, 6 Jun 2004 (UTC)
The look like tabs, but they do not behave like tabs on, say Amazon, or most good sites using them. The most important thing however is that they will not in any near future behave as tabs should because of the relative slowness of the Wikipedia compared to, say Amazon. In other words, though tabs are in theory a great interface facilitator (I agree completely with Steven Krug on this and I think everybody involved with the usability issues should read his slim book Don't make me think, by the way) they should be completely scrapped for Wikipedia. There are a lot of other usability issues, and the Wikipedia should really go through some usability testing with a few think-alouds, but all this is secondary to the tab problem. AlainV 03:58, 8 Jun 2004 (UTC)
I have also been confused by tabs, and still is sometimes. I can't tell exactly why, but the previous comments certainly give good indications. There is room for improvements, but this is probably a very difficult user interface design work. Marc Mongenet 05:57, 10 Jun 2004 (UTC)
It does not have to be so in our case, since we are not a commercial site, depending absolutely on originality and perfect branding to drive all the customers to us and keep them. All we have to do is copy navigation practices on the average of good plain web sites (the average implies getting knowledge but also avoiding lawsuits that occur when you copy a single good site or two), adapt the general things to our variations and test it. Then after testing, do changes and tests again. And that's it. Web navigation design and Usability testing of Web interfaces are not rocket science. AlainV 02:07, 11 Jun 2004 (UTC)
Well, designing something that works well enough, like the current interface, is maybe not rocket science. But designing a really good interface for a site like Wikipedia is rocket science. For instance, while editing this comment, I could select an "edit" link, what does it edit? There is a "search" box with a "Go" and "Search" buttons, what does it mean? What is a "mediawiki"? Marc Mongenet 03:12, 2004 Jun 12 (UTC)
Issues related to default fonts.
Kudos for using relative font sizes. Default is a small font size, however; too small for comfort. So I can change my browser settings for this site but when I then click on an external link, the fonts there are overwhelmingly large. Sure, an experienced Wiki user can change his/her skin, but most readers will be hit and run, looking for info, not to settle in and customize their interfaces. I *like* the sizes of headings; relative sizes are now much clearer between the different levels of headings and much different from body text, esp. with the hairline for the top-level headers. Elf | Talk 17:41, 3 Jun 2004 (UTC)
So--I guess voting has been suggested:
Make body text larger
Body text size is fine
Do not interfere with my prefered font size duly set in my browser settings
See also Let Users Control Font Size in Jakob Nielsen's well-regarded Alertbox usability column.
Can't consider size separately from font family
I think the diff font size could use some increasing as well. Dori | Talk 13:09, Jun 5, 2004 (UTC)
I withdrew my larger vote. On reflection, it's more the greater line spacing than the text size which is the issue for me. Jamesday 20:51, 5 Jun 2004 (UTC)
I think changing the font size of the body of a whole page is always a bad idea. I did not notice the problem immediately because a long time ago I switched to a browser that let me override this kind of web design error... But most visitors use other browsers and visit Wikipedia only for a few minutes: this renders all argument about wikipedia user preferences, user style sheets (!) and so on, null and void. The only way to present Wikipedia in the visitor preferred font size is by not changing it. The current CSS is by construction presenting Wikipedia in a font about 20% too small. Marc Mongenet 04:48, 10 Jun 2004 (UTC)
See also: Wikipedia talk:Serif or sans-serif
Don't specify a font. Leave as browser default
Combine serif texts with sans-serif menus
Arial Unicode MS for characters that are buggy in Verdana, else back to Verdana
For background on the font issues, please see [1] and [2]. The short version is that browsers do not behave consistently today and gwicke is using one possible workaround. But it's not a perfect workaround because it depends on how well the assumptions of the workaround match the specific display you're using. It's to be expected that different people will see different sizes - it's partly a browser/platform/dispaly difference. that is, it's not only people liking different sizes - people may be seeing different sizes for the same settings. Jamesday 07:24, 5 Jun 2004 (UTC)
That’s true—but it does not excuse overwriting the users’ settings... quota
The HTML math looks much worse in the new font. ✏ Sverdrup 11:00, 5 Jun 2004 (UTC)
Everything looks much worse in the new font. quota
These are the font-family settings of the current top ten web sites according to alexa, checked with the firefox dom inspector for body text:
None of them specifies no font-family, none of them serif fonts. Looks like a trend to me. -- Gabriel Wicke 20:36, 9 Jun 2004 (UTC)
Concerning Gabriel Wicke's list… So the "most popular" sites should tell us what font to use here? Well, let's see…
I'm sure you're not arguing that, if Wiki uses sans-serif, it will be massively popular. The fact is, sites become popular because of their content (or their viral infection rate), not because of their fonts. Common users (the ones who wouldn't know CSS from CBS) are completely helpless to affect how a site looks, and are at the mercy of the Powers That Be. If they want the content, they must put up with the format. The most popular sites will almost always be the ones who content is so critical (or so wired-in to basic computer use) that users have little choice about using it; e.g., the Microsoft Strategy that is so amply illustrated by this list.
If you're interested in Wikipedia user opinions, the vote above suggests so far an overwhelming majority want the browser default font, which is serif for anyone who hasn't customized their browser settings. Of course, one should keep in mind that this survey is heavily biased toward users who are Wiki-comfortable enough to…
If these informal Wiki votes were being done in a social sciences course, we'd flunk on our inability to recognize massive systemic biases. And I'd bet good money (if I had it) that the vast majority of non-bold and new users would prefer to keep the interface simple until they get more comfortable with the content and the practices of participating in Wikidom.
Concerning older≠wiser's point, if familiarity breeds readability preference, then serif (which all the browsers use as a default body text font) would be the logical choice unless and until Wiki spends considerably more effort testing article appearances and locks down formats and layouts like the commercial sites do. Since the latter is absurd and the former ain't gonna happen soon, I again recommend we make the old Standard skin (with its serif fonts) the Wiki default skin. This prevents no one from selecting a fancier skin or changing any skin's font or other CSS attributes, but it puts the onus of extra work on the people who are prepared for and knowledgeable about it, not those who have enough trouble just learning to use Wiki. -- Jeff Q 05:13, 10 Jun 2004 (UTC)
What we're doing currently:
Keyword basesize, 123% Verdana/Bitstream Vera Sans/sans-serif
Only sans-serif specified (defaults to Arial in IE), else the same. Arial is harder to read for a given nominal size, appears at least 10% smaller. Certainly needs compensation if kept, but those using Verdana would have too big fonts then.
Same in Firefox linux, default font for sans-serif is Bitstream Vera Sans:
This is my proposal if we should keep the sans-serif/Arial setting
No font size specified at all, browser setting is used
'Medium' font size in IE (can't be adjusted apart from those larger/smaller steps)
--
Gabriel Wicke 14:13, 5 Jun 2004 (UTC)
The italics are very difficult to read (most prominently perceived in the Recent Changes edit summaries) KRS 17:38, 13 Jun 2004 (UTC)
If anyone else is bothered by the H3 level being bolder than H2 the following will fix it:
Don't know if it should be applied en-wikipedia-wide. Dori | Talk 13:53, Jul 12, 2004 (UTC)
The main problem I've seen here is that visited edit links are the same colour as visited articles. Which means if you have clicked on an edit link it is no longer possible to tell whether the article exists or not. -- sannse (talk) 17:49, 3 Jun 2004 (UTC)
I would suggest the colour scheme presented at Wikipedia:Village_pump#Link_colours as best, which also seems to address sannse's problem. -- Michael Warren 18:00, 3 Jun 2004 (UTC)
I'm not sure about stubs, but the other default colours were: a { color: #0000FF; } a:active, a:visited { color: #800080; } a.new { color: #CC2200; } a.interwiki, a.external { color: #3366BB; } - which is slightly different from the example mentioned above. This doesn't solve the visited edit link problem though -- sannse (talk) 16:49, 4 Jun 2004 (UTC)
While the default colors look normal on other pages, because of the shady backgrounds they look excessively bright on the Wikipedia pages. So, either change both foreground and background, or leave it be. Personally I think that the somewhat shaded backgrounds and text colors are fine. At one point we had something that was too pastel to be readable, but it's pretty much okay nowadays. -- Shallot 00:09, 4 Jul 2004 (UTC)
Return to MediaWiki 1.2 defaults
Don't return to MediaWiki 1.2 defaults
No icons by default
Icons by default
Other
I was among those who voted for underlined by default (I have since changed my mind), but now there is a bug and removing the check from the "Underline links" option does not change the behavior. Should we force it on users this way (this also seems to negate browser settings)? Dori | Talk 03:48, Jun 4, 2004 (UTC)
Yes this awful. If I want underlines on links I can set my browser to put them there. Why on earth does Wiki force the ungly things on users? Shall we change italic emphasis to all-capitals, next? And, as a next step, monospace fonts everywhere (green, on a black background, of course). quota
I wish I had known of a vote. This is disastrous! Little horizontal lines everywhere cutting through the text! AHHHHHHHH! My browser's no-underlining of links is even superceded by this! Ackbar! -- AquaRichy 07:04, 4 Jun 2004 (UTC)
a { text-decoration: inherit }
? --
Gabriel Wicke 10:45, 5 Jun 2004 (UTC)/* remove the ugly, recently-reinstated link underlines */ a { text-decoration: none; } a:hover { text-decoration: underline; }
My vote is that link underlining in the default skin should respect the user's browser settings. Ditto for link colors (except of course for the external and missing-article link colors, which are not defined by the browser and so must be chosen Wikipedia.) Jorge Stolfi 13:16, 4 Jun 2004 (UTC)
(moved from the village pump)
I've had link underlining turned off in my preferences for some time now, and yet as I use WP it seems to turn on and off, apparently at random. Surely this is happening to others? – Smyth\ talk 15:43, 23 Dec 2004 (UTC)
Okay, I have determined a pattern:
So we seem to have that refreshing always results in a nonunderlined page, while normal browsing randomly tends towards an underlined one.
I realise some or all of this problem may be client-side, in which case I'd be glad if someone explained it to me. I use Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Galeon/1.3.17 (Debian package 1.3.17-1)
. –
Smyth\
talk 15:58, 23 Dec 2004 (UTC)
Its good that the underlining has gone out of the monobook format. However, the blue has gone back again to being light blue. It was/ is very tough to read the light blue becuase of the lack of contrast, the darker blue was much more readable. Also the continuity between words in a page will be better if the colours are closer in value ( meaning dark/light). Now the continuity is not there. For all these reasons can we have a dareker colour please?
Is it under discussion? Can we have a page in which all the changes are recorded for the four major schemes when a change is made by the developer/ user who makes the change so that we can give our comments? The reactions are very scattered and no one seems to counterreact for any reaction. KRS 11:17, 10 Jun 2004 (UTC)
P.S. the top tabs are of a darker blue with a good contrast. Either the same shade can be used(it looks like cobalt blue/slightly like ultramarine blue)in the place of all the lighter blues or if a different one is required then Prussian Blue can be used. Or the top tab can be the lighter blue( there is very little of it, only a few words) or Prussian blue and the rest can be the colour which is now the top tab colours.
Ideal design - Background Vs. words should have the most contrast, non linked words vs linked words should have a contrast that does not affect too much the continuity of the reading process and is lesser than the background vs. words contrast. What exists now- background vs. link contrast- too less, link word vs. ordinary word contrast too much. KRS 11:31, 10 Jun 2004 (UTC)
For some strange reason, clicking on an article link that I haven't visited before causes it to sprout an "external link" icon behind it (possibly rearranging the paragraph as it shifts the following text over).
This link isn't there if I reload a page, so it's not simply a "visited link" indicator. I assume this is a bug? -- pne 08:04, 15 Jun 2004 (UTC)
(Non-article = talk:, as well as user:, wikipedia:, special:, MediaWiki:, template:, category:, and their talk pages)
Should be the same color as other non-article pages
Should be the same color as article pages
Yet a third color (suggest one if you like; not part of poll)
Recently, as viewed by me with Safari 1.2.2, the text on certain pages, including this one, has acquired an annoying light-blue background tint. I find this quite irritating. I work quite hard to get all the monitors I use set for a pleasing-to-me color temperature of 5500 degrees, and I do not want Wikipedia undoing this by adding bluish casts to my nicely-tuned white. It reminds me of a magazine I read as a kid called "Children's Digest"—does it still exists\?—which was printed on a sort of light-snot-colored paper that they insisted was "eye-ease paper." How can I turn this off? Dpbsmith 11:16, 4 Jul 2004 (UTC)
I don't know why but the little person icon bugs me. It ought to go. When I see something like it on a web page, I brace myself to see some links titled "Solutions", "Partners", etc. -- Yath 10:06, 5 Jun 2004 (UTC)
/* supress the person icon by your username */ li#pt-userpage { background: none }
blankfaze | •• 23:26, 5 Jun 2004 (UTC)
Please have the server insert HEIGHT and WIDTH tags for images so the page doesn't jump around when it is loading. -- User:Juuitchan
Try it yourself. Log in, and links are underlined, log out, and they are not. This is useless, I think we should give up changing the default skin if we are not changing it for everybody, it's just silly to log in and discover 20 small tweaks that make the overall UI much better. ✏ Sverdrup 07:54, 4 Jun 2004 (UTC)
.pBody a { text-decoration: none; }
#bodyContent a { text-decoration: underline; }
I expect that this will eventually change to reflect the decision here, since we are trying to decide what that default look should be. Jamesday 20:30, 5 Jun 2004 (UTC)
Monobook's line heights are just too big in tables and in the side bar. Reducing them to 1em or 1.2em gives a much better layout. Lupo 09:08, 4 Jun 2004 (UTC)
[[Image:MiniDachshund1 wb.jpg|thumb|right|Black and tan Miniature smooth-haired dachshund]]
The votes on the images can be found at Meta:Thumbnailed images archive for the overall appearance and Meta:Thumbnailed images/Feature Poll. Preferences for white (same as page) or pastel (different from page) border color were 50-50 split; the icon for the link to image description page is the one being used, a magnifiying glass for a "bigger version" of the image was favored but "bigger version" isn't implemented. Jamesday 20:39, 5 Jun 2004 (UTC)
the excessive border elements have caused me to not use |thumb| in many cases. Badanedwa 23:42, Jun 24, 2004 (UTC)
I find having the interlanguage links at the bottom of the sidebar a nuisance. Part of Wikipedia's strengths is the fact that many articles exist in several languages, and we should emphasize on that, not hide it! (I usually have to scroll—and I have a big screen!— to see them.) It would be relatively easy to have them back at the top of the article, either above the top "tabs" or just below them, but above the first header. Lupo 09:08, 4 Jun 2004 (UTC)
I like them in the sidebar and would hate to have them back at top. Some articles have dozens of languages linked, meaning users with low resolution monitor settings would have half their first screen being a list of links to different language versions of the article. -- mav 04:35, 12 Jun 2004 (UTC)
It appears to me that the option of printable pages has disappeared. They also appeared to be the most saveable pages (if I wanted to save the article). Not popular enough? - Nilmerg 11:59, 4 Jun 2004 (UTC)
Now that the blue is darker, it is much better. However, the contrast between unvisited and visited links is almost nonexistent, the violet has to be made darker or a different hue altogether can be tried.
By the way, what's with the underlines for links suddenly appearing and as suddenly disappearing? KRS 13:20, 4 Jun 2004 (UTC)
While section editing is really convenient for serious contributors, they are distracting for people trying to read the encyclopedia. Not only do these people have keep reading "edit," attempts to copy/paste the text will also copy in the edit link. A serious contributor is most likely a user and and serious reader is most likely not logged in. Please do not make section editing available for anons. -- Jiang 21:44, 4 Jun 2004 (UTC)
*.editsection { position: relative; top: 1em; }
I know this goes beyond CSS, but I would like a div element containing the whole editable section. (Actually, most of this section would need changes in the HTML too.)
Alternatively, we could just disable section editing for anons in the article namespace and leave it available elsewhere. -- Jia ng 21:10, 28 Jun 2004 (UTC)
I am REALLY, REALLY happy with the new Monobook skin and MediaWiki 1.3, especially after instituting several User css changes. I like the skin, I like the font changes, and like the new features.
However, there is one nagging problem that I have. In the old software, there was edit/history/watch/whatlinkshere links at the bottom and side of the page. Now they're at the top only. I would really like to see these links at the top, bottom, and side, or AT LEAST at the top and bottom.
I've found often that when reading an article, especially long ones, I find myself looking intuitively for the link at the bottom. This is a small problem, but a nag nonetheless.
Anyone else have feeling on this? blankfaze | •• 05:37, 5 Jun 2004 (UTC)
Yes
No
Maybe
I was looking for a place to ask about this - finally I've found one! I have seen a new style page, when I logged in to Wikipedia from work or from the local library - but it is inconsistent. Sometimes you get it, sometimes you don't.... What's going on? I assume this is to do with a new stylesheet that you're trialing - is there any info posted anywhere?
For the record, I'm logged in at home using Safari 1.2 on Mac OSX 10.3.2. At work inevitably they use Internet Explorer on Windows ('98, I think).
If it is a Mac OSX compatibility issue, perhaps Mac users ought to have the opportunity to comment about the so-called "new look" - at some point!
Agendum 17:30, 5 Jun 2004 (UTC)
I notice the liberal use of the word "obvious" in this debate on styles. I feel compelled to suggest that the word "obvious" almost never applies in a discussion among a diverse population. When someone calls something "obvious", it nearly always says more about their own background and biases than about any universal truth. -- Jeff Q 05:29, 9 Jun 2004 (UTC)
The larger space between lines not only disturbs some text all by itself, but it has secondary effects as well. The 1.3 software apparently changes how ends-of-line and blank lines are handled. Under 1.2, a newline (in the generic sense) would break a paragraph, indented line, or list item without adding extra whitespace between lines. One or more blank lines would do the same, but add a blank line between. Thousands of pages count on this formatting.
Under 1.3, the single line-break gets absorbed into the previous paragraph, for ordinary text. (I think this is bad, based on existing use, but I can see the argument for it.) However, because of the new style, indented lines and list items are properly broken but get a virtually-undetectable difference in separating space based on whether they have single break or one or more blank lines. This causes major problems for some text, like the following two dialog segments from Wikiquote:Buffy the Vampire Slayer:
Under 1.2, it was clear these were two separate quotes. Under 1.3, you can't really tell where the division is without looking closely or considering the context. (The confusion is even more apparent when looking at a long list of these quotes.) I used this Wikiquote example because it's compact, but List of self referential songs is a great Wikipedia example of a page whose size seemingly tripled and became horribly mal-formatted using the new software and styles. Any page that uses indented lines for song excerpts and/or HTML "pre" style formatting, and any page that counts on the difference between single line-breaks and blank line spacing is going to suffer from these problems.
This is all because someone thought that extra space looked nice using the new font that is also such a hot point of contention. Please keep the customizations and whimsical style choices out of the default style! -- Jeff Q 05:36, 9 Jun 2004 (UTC)
dd
element (definition data) which was intended for defining a term; when the colon is used without a semicolon, you essentially have a definition with no term, used purely for the purpose of achieving some indentation. Unfortunately, the only other sort-of appropriate HTML tag we have is blockquote
, which is block-level and cannot be nested (which makes it useless for nested indentations like we use on talk pages). It'd work for quotations like the Buffy one above, though. (Do we have wikicode for blockquote, or does it have to be in HTML?) There's
a little discussion of this on meta. I agree with you, Jeff, that whatever style attributes are screwing up the spacing should be eliminated, until we use definition lists only for things that are actually definition lists; it plays havoc with the other things we're using it for at the moment. --
Wapcaplet 17:53, 12 Jun 2004 (UTC)A meta-comment: note that the graphical beauty of a document matters only when a new user opens it for the first time, and then only before he or she starts reading the text or using the buttons. After that fleeting moment, only three things matter: readability, readability, and readability.
That is why any book that is meant to be read (and not just looked at) is printed with serif fonts, black on white, with little or no decoration. Even a simple rule at the top of each page will begin to bother the reader, subliminarly, after a few dozen pages. That is why good books have "clean" page layouts, and no frames around illustrations and figure captions.
Graphical decoration is ok when it conveys useful information such as section boundaries, list items, links, etc.. However, the most efficient clues for that task are spacing and indentation, then font size and weight. (One serious problem with the current Wikipedia layouts -- both "monobook" and "standard" -- is that the spacing below sub-section headers is just as big as that below section headers.) Marking off sections with rules or color bars may already be in the negative payoff zone, more distracting than helpful.
Sans serif fonts look better than serif ones, which is why they are used in advertisements, brochures, flyers -- and their WWW equivalents. The neat looks of a sans-serif text are good at catching the attention of passers-by, which is THE main goal of avertising. However, compared to serif fonts of the same height, they are noticeably harder to read. That is not a problem in advertising, where the text has to be short and eye-catching -- but is a major problem for texts longer than a couple of paragraphs.
As I see it, the negative reactions to the monobook skin (above) are due not to locally fixable bugs, but rather to a single global problem: the skin was not designed for readability, but only to look nice. For example, the increased font size and line spacings give it a neat and "airy" look, but they also mean that less text fits in the page, which is bad. (BTW, the standard skin too wastes screen estate with all that whitespace between paragraphs.) Ditto for the subtly colored links without underlines: they make the page look cool, but make it hard for the reader to notice the link.
Whikipedia pages need not grab the reader's attention, but must be easy to read; thus they should be optimized for readability. The standard skin was already close to optimum in that regard; the only improvements I can think of are: (1) reduce the inter-paragraph space (2) reduce the space after subsection headers, (3) reduce the Wikipedia logo image to half its current size or smaller (except on the main page). Changes in other items, like like font and link colors, are more likely be for the worse than for the better.
All the best,
Jorge Stolfi 00:37, 10 Jun 2004 (UTC)
I'll admit that I don't care much for the new default look, so I excercised my freedom of choice & stayed with the old standard look. However, doing so has led to some issues:
Thanks, llywrch 04:45, 12 Jun 2004 (UTC)
I love the new skin, but I've also grown to love having the quickbar on the right side. Is fixing this feature planned? Or is it not being implemented for some specific reason? -- Danny Rathjens 09:00, Jun 12, 2004 (UTC)
Sannse and I were talking or IRC about the effect that the ability to have one's own settings might mask some site-wide problems. What is meant by this is that people find a problem, they are told to fix it in their own monobook.css, they do and they forget about it. New users are left out as they don't know about the many fixes that crop up. Ideally, the worst problems should be fixed in the site-wide file. Unfortunately, the only way for this to work out would be for people to keep having votes on changes. Also, at which point do we implement the changes that are supported? Have some of these changes been rendered moot because things have been fixed on the project-wide (main.css) file? Comments, opinions? Dori | Talk 13:50, Jun 12, 2004 (UTC)
The main page uses hardcoded background colours for the featured articles, the table at the top of the page [that says "Welcome Newcomers"], and the In the News box. As a visually-impaired user who prefers light colours on dark colours, this interferes with my ability to view Wikipedia. Please consider moving the background colours and formatting into the CSS sheets. Aphrael Runestar 00:59, 2004 Sep 14 (UTC)
I've seen quite a bit of fulmination here about how much more readable serif faces are as compared to sans, usually with a none-too-thinly-veiled hint that the rest of us are idiots for not knowing this.
No question that it all sounds completely logical. The serifs, we are told, are like little hooks, you see; they serve to "guide the eye" along the line of text, making reading easier. One imagines the eye, cleverly fooled by these little curlicues into following the straight and narrow path and digesting the words as easily as if they'd been lubricated with cod-liver oil. From screen, to brain, with a minimum of interference.
It's perfectly intuitive. Unfortunately, it's not like that at all.
We have an intuition that reading text should be something like listening to speech: a linear and serial process, moving ahead left-to-right as we listen to speech from past-to-future. We imagine that the brain sees a word, say "rutabaga", and grasps it first letter-by-letter, always strictly left-to-right, before putting together the word as a whole: "hmm, there's an 'r'... and a 'u'... and a 't'...."
But the eyes do not scan text like an old-fashioned typewriter, going left to right in a horizontal straight line, then snapping back to the carriage return and repeating. Studies with eye-cameras (devices that watch you watching something else, calibrated so that they can show the path your eyes take over a page like the chalk drawings of a football coach) have proven this conclusively. Your intuition that you read this way is irrelevant; a few minutes looking at optical illusions should prove to you that what you consciously think your eyes are doing has little bearing on what they actually do.
Instead of this imagined linear, repetitive process, the eyes actually do something far more interesting. They first sweep over an entire chunk of text consisting of two or three lines, in a vaguely flattened diagonal direction, from upper-left to lower-right, to get a general sense of orientation and bearing. They pause and fixate briefly on guidepost elements like punctuation, boldface and italics (and, one would assume today, links as well) and capitals, getting the overall sense of the "shape" of the chunk being read. Then they hopscotch from word to word, reading them, not letter-by-letter, but by overall shape and "color" (meaning the overall amount of grey defined by the black and white of the word's letter shapes). The eye then makes repeated passes over words that aren't recognized in this fashion, making whorls and spirals until finally, yes, reading letter-by-letter for unfamiliar words. But the point is, for most words we "read" in body text, we don't read them letter-by-letter at all.
This is why when we misread words, we misread them as other words, not as jumbles of letters. It's aslo why we do so well raednig wrod jmubles when the oevraell shape of the word — as defneid by the fisrt and lsat letters, alnog with the plceamnet of the acesnders and dsecneders — is held cosnsitent.
If serifs truly performed the function claimed, to guide the eye along the line of text — and if that were actually a desirable function in reading body text — one would imagine the type of triple-ruled text one sees in first-grade reading textbooks to be the easiest text to read of all. But it isn't; to the contrary, for an accomplished reader, it's maddening.
Putting aside the question of overall readability of serif versus sans faces (and I think the argument can be made that evidence does not show serifs are even more readable on paper), Wikipedia is not the first website to grapple with the question of which is more readable on-screen.
In reviewing examples online of sites and institutions that have made a determination on the serif vs. sans question, one is immediately struck by a fundamental difference. Those that come on the side of serifs do so by fiat, simply repeating the conventional wisdom that "serifs are more readable." They often give as evidence the "fact" mentioned above that the serifs "guide the eye."
While there are cases of sites coming down on the sans side for equally erroneous reasons (sans faces are "cleaner" or "more modern"), many sites have decided on sans because of usability studies — i.e., they have tried both in labs and have discovered which work best. A few examples:
I strongly believe that logged-in users should have a choice in the matter. If they believe that serifs work better for them, then they should be able to see serifs. I'm not myself a good enough web designer to know whether building a beautiful website precludes just letting browser options rule, though I know several web designers who assure me that that is unfortunately the case.
There are readability questions that are clearly answered by evidence — for instance, that extremely wide columns of text are more difficult to read than narrow ones, or that proportional typefaces are more easily read than monospaced ones.
But can we please drop this old chestnut that serif faces are always more "readable" than sans? The conjecture has no evidentiary basis.-- TreyHarris 00:54, 13 Jun 2004 (UTC)
Trey, I was not arguing from ideology, but from experiment. Sans-serif in sites like Google never bothered me, but I tried standard and monobook in Wikpedia, and I defintely find standard easier on the eyes. (For one thing, monobook's table of contents is too big.) That may be true just for my browser and font settings, I don't know. Ditto for the background color - white works best for me, and I see no flicker. Perhaps it also has to do with my CRT's resolution and refresh rate?
Jorge Stolfi 06:54, 13 Jun 2004 (UTC)
I would like to vote for serif fonts to at least for article text. I won't quote any readability studies, I'll just say that I found Wikipedia harder read after the font change. More important however is the fact that any article is extremely wide by default. It should probably be changed to something a lot less wide. (Maybe we can have articles in 2 column modes)
Previously, the sans-serif default resulted in in-line equations that clashed with the serif font used by TeX for equations. I noticed today that inline <math> now uses a serif font, but there are still problems.
Please just stick with the browser default typeface and point size, which seems to be the overwhelming consensus here. This will use a consistent serif font for the vast majority of users, and those users who want to play with fonts can muck around with stylesheets.
—Steven G. Johnson 16:32, Jun 13, 2004 (UTC)
Yesterday, I could recognize which words were changed in an edit-diff. Today I can not. Is there some preference I ought to change to get this feature back again?
--
Ruhrjung 02:51, 2004 Jun 12 (UTC)
.diffchange {color: red;}
#content
and #sitesub
as top-level tags: should it be within one of those? (You will gather that my knowledge of CSS is strictly limited, much like I assume the majority of Wikipedians :-) --
Phil |
Talk 14:36, Jun 21, 2004 (UTC)Holy, somebody just changed the diff to a ginormous fontsize! How can I change it back? ".diffchange {size: NOT-OVERSIZED"? ;-) -- Menchi 03:48, 12 Jun 2004 (UTC)
<span style="color: red">diff text goes here</span>
<span class="diffchange">diff text goes here</span>
Was the recent drop in the font size in the two parallel diff text columns (using Standard skin) part of this change? It suddenly became smaller and now I have to lean forward in my chair to peer at the screen and see what changed. Was that discussed anywhere? Can I change it back on my own? –Hajor 13:36, 12 Jun 2004 (UTC)
Polling on this page started on 3 June so I strongly suggest that items with 75% or more support on 3 July will be implemented that day. We can, however, continue to vote and may even change some settings based on new votes. -- mav 05:26, 26 Jun 2004 (UTC)
Something in MediaWiki appears to be broken, and
this change makes it much more apparant. The styles in
MediaWiki:Monobook.css are being imported even though I'm using "MySkin", not Monobook. Since this file now overrides my default background and link colours, but not some other things, everything looks quite awful. Would it be possible to revert these changes until the MediaWiki bug is fixed, or perhaps move them to MediaWiki's style/monobook/main.css
where they'll only affect Monobook users?
—Lady Lysiŋe Ikiŋsile |
Talk 15:51, 2004 Jul 3 (UTC)
테스트
Somehow related: how can I set my favourite colors for non-article backgrounds overriding the mediawiki:monobook.css in my User css? The copy, paste and change the color value method doesn't work. -- till we ☼☽ | Talk 23:03, 6 Jul 2004 (UTC)
I don't understand why the message "From Wikipedia, the free encyclopedia" was ever removed from the monobook skin. Are there any objections to adding it back in using #siteSub { display: inline; font-size:120%;font-weight:normal;}
? It already appears in the other skins.
Angela
. 06:19, 16 Jul 2004 (UTC)
I suggest ca-edit a{font-weight:bold !important;}
is added to make the "edit this page" link bold. This is being used on the
German Wikipedia and makes it more obvious to newcomers that they can edit a page.
Angela
. 11:11, 17 Jul 2004 (UTC)
It's a good change I think, the edit link had somewhat disappeared with the new skin -- sannse (talk) 20:00, 21 Jul 2004 (UTC)
What would be the proper procedure for proposing a change to font colours (as this has already been voted on)?
Acegikmo1 17:40, 23 Jul 2004 (UTC)
Can we make the monobook css file include autoflow for pre sections? The bottom one is autoflowed:
IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF this is useful for: * pasting preformatted text; ENDIF
IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF this is useful for: * pasting preformatted text; ENDIF
If you resize your window so it wraps, you can see that the bottom one has a scroll bar instead of resizing the whole page uglily with an overlapping border. I know I can put this in my personal monobook.css (and i will) but it should be global shouldn't it? - Omegatron 17:04, Aug 2, 2004 (UTC)
There are workarounds for IE. Setting the width of the pre section sort of works:
WITH pre style="{ overflow:auto; width:95%; }" IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF this is useful for: * pasting preformatted text; ENDIF
SAME PRE STYLE BUT WITHOUT A LONG LINE IF a line starts with a space THEN it will be formatted exactly as typed; in a fixed-width font; lines won't wrap; ENDIF
http://www.magpiebrain.com/archives/2004/04/19/ie_and_overflow_auto gives a better description. - Omegatron
Also I think the old and new columns of the diff page should each be put in a div, which could be autoflowed, to avoid long foreign page names making the diff page super wide. I tried just doing it with CSS, but each line is a different table cell, so it wouldn't really work, giving each long line its own scrollbar. - Omegatron 14:16, Aug 10, 2004 (UTC)
On hi.wikipedia.org the default of monobook skin is not working correctly. I had to go change it to an older 'blue' to be able ot use the links. I like the monobook style - if it would work. What do I need ot change. I see references to 'user can change' the .css files - where are these. I tried using the myskin option under preferences and got a while linear page without any formatting. Any help - pointers about some basic discussion about this topic would be helpful. Shree 17:09, 11 Aug 2004 (UTC)
MSN TV may garble pages.
MSN TV Viewer 2.8 (Build 20) fails spectacularly due to its willingness to @import and subsequently destroy stylesheets. Additionally, an @import that again performs an @import will so confuse the engine that nothing (worth viewing) renders, such as when the user stylesheet @imports the MediaWiki stylesheet.
Fortunately, MSN TV 2.8 will use only the last @import within each <style> </style>. Thus, a workaround is to gather the @imports into a single <style> </style> with the addition of an MSN TV-safe @import. (In my tests I imported an empty file.)
Ex.
<style type="text/css" media="screen,projection">/*<![CDATA[*/ @import "main.css"; @import "user.css"; @import "null.css"; /*]]>*/</style>
MSN TV will ignore the first two stylesheets and process the third. It may be useful to install MSN TV-specific properties here. (BTW, the software seems to ignore media types.)
Not having the actual device, I was unable to verify if this problem affects the consumer (hardware) version of the MSN TV software. However, I believe the viewer (is said to) accurately represent the actual device software. Can somebody confirm if the actual hardware exhibits the described behavior?
-- John Robinson 09:18, 28 Aug 2004 (UTC) (PS: no idea if this is the right page for this--if not, please help me get it to the right people. Thank you.)
(none)
It looks like
li#ca-watch, li#ca-watch { margin-left: 1.6em; }
should actually be
li#ca-watch, li#ca-unwatch { margin-left: 1.6em; }
— User:Mulad (talk) 06:39, Aug 29, 2004 (UTC)
moved from the village pump
I don't like the new green external links. Please change it back.
Crossposted from MediaWiki_talk:Fromwikipedia#Linking to Main Page —— Please Reply there
Would anyone have any objections to linking "Wikipedia, the free encyclopedia" to http://en.wikipedia.org/wiki/Main_Page ?
Why? Well...
I propose styling the link so MonoBook users simply see it as plain, ordinary text. I can't really see any downsides to this... can anyone else? Tom- 22:07, 31 Aug 2004 (UTC)
Okay, so now someone has switched off the little external link icons, and I want them back. How do I sepcify this in my personal CSS file? -- Phil | Talk 12:03, Oct 1, 2004 (UTC)
I have no objection against using the link color. However, in Mozilla at least, the override results in ugly spaces between links and consecutive characters. This makes the remedy worse than the disease. Unless that can be fixed, please do not override the link icons.-- Eloquence *
I wondered where the icons were too. I don't want to lose them! The arrow icons make it easy to spot external links. change the color if you want, but don't remove the icons. If I didn't want the icons I'd hide them in my monobook.css, but the icons have been around for a while now so people are used to them. the "plainlinks" class already exists for areas where icons are inappropriate anyway. [[User:Norm|No rm]] 19:19, 3 Oct 2004 (UTC)
This section was moved here from Wikipedia:Village pump (technical).
This has actually been an issue for me ever since the new Monobook skin was implemented; I just haven't complained about it yet. I'm sure there must have been others who have experienced this same problem, so sorry about bringing it up again, I just don't know where discussion of this bug is. Anyway, the bug is this: the "Watch" tab at the top of the screen always appears below the other tabs, and then, when I move my mouse pointer over the tabs, all the tabs at the top move away from their horizontal row and instead stack vertically in the top left, just to the right of the Wikipedia globe image. I'm using IE6 on WinXP in an 800x600 res. -- Lowellian 06:59, Oct 4, 2004 (UTC)
Andrewa, unfortunately your workaround didn't work for me. However, your suggestion gave me the idea that it was basically a stylesheet problem, so then I delved into the monobook stylesheet. The odd thing about this bug is that it looks like there's plenty of blank space in an 800x600 res to fit in all the tabs, but nevertheless the display screws up by "wrapping" the tabs for some inexplicable reason. After studying the code for a while, I was able to locate the source of the problem:
#p-cactions { ... width: 76%; ... }
The above line applies only to the tabs at the top of the page, and to no other elements on the page. The problem the width statement creates problems is that 76% of the width of a 800x600 screen is not enough to hold all the tabs. Therefore, I then changed my stylesheet by adding this line to my personal monobook.css page:
#p-cactions { width: 100%; }
Now the tabs display properly in an 800x600 resolution! (Even better: this change does not create problems—or even change the display at all—in larger resolutions. In fact, I don't understand why the stylesheet developers even chose to make the width 76% in the first place; unless I'm missing something, it should always have been 100%. 100% doesn't screw up the column to the left, either.)
Anyway, thanks for the comments. You helped me find a solution.
-- Lowellian 05:25, Oct 7, 2004 (UTC)
Argg, okay, I spoke too soon. There is a slight problem with what I posted above, and now I see why the stylesheet developers chose to post a value less than 100%. It creates blank space to the right of the page, so that in an 800x600 res a horizontal scroll bar will appear at the bottom of the window. However, though 100% does not work, the following does (without being so wide as to create a horizontal scroll bar), and it fixes the stacking tabs problem.
#p-cactions { width: 80%; }
Now it works! (I think.)
-- Lowellian 05:35, Oct 7, 2004 (UTC)
Until your submission is actually implemented, I've added my patch to MediaWiki:Monobook.css. It's a simple one-line patch, and after having tested it for nearly a month, it seems to not create other problems. — Lowellian ( talk)[[]] 07:16, Oct 25, 2004 (UTC)