This is an archive of past discussions about MediaWiki:Common.css. 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.
Remove or demote Titus Cyberbit Basic in template unicode
Currently, Titus Cyberbit Basic is listed first in the Unicode template. However, this causes a lot of characters to not display at all (i.e. blank space appears instead) when surrounded with {{Unicode}}. An example is the blackboard bold chars on Blackboard bold. Surrounding them instead with {{IPA}} works for me, because some other font takes precedence; likewise if I de-install Titus Cyberbit Basic. If I use the Symbol viewer on MS Word, it doesn't show the blackboard bold chars in Titus Cyberbit Basic at all, but for some reason MSIE gets confused. Perhaps we can demote this font?
I see its been demoted one step below code2000, can someone check how it compares to the other fonts and decide if it shuld be demoted further. Plugwash00:20, 4 September 2006 (UTC)
Common.css vs Monobook.css
Since I last looked here, a lot of classes have been moved across from monobook.css to here. Colour declarations for classes such as wikitable and infobox should be in monobook.css as they are specific to that skin. ed g2s • talk09:44, 13 September 2006 (UTC)
Depends on whether, in a given situation, it would be better to have Monobook-y colors or no difference at all. They can be overridden in the other skins' stylesheets if someone's actually maintaining them; if they're not, plain text for infoboxes is much worse than colors that maybe clash with the skin. They have to be set off one way or another. Something like wikitable, yeah, color specs should probably go in Monobook.css, with the rest (margin, border, padding, weight, alignment) remaining here. —Simetrical (talk • contribs) 02:54, 14 September 2006 (UTC)
Sounds like the result of this recent addition near the top:
-moz-column-count:2;
column-count:2;
Does it only show up in a debugger console, or actually interrupt browsing with an error message? We should probably be very careful with using such CSS3 properties. Cheers. —MichaelZ. 2006-09-14 19:30 Z
According to the CSS standard unknown properties should be ignored (for future compatibility). It is strange that Firefox produces an error message instead of a warning or information message. Maybe a bug should be filed at mozilla.org? —Ruud22:57, 14 September 2006 (UTC)
If it's only in the console, then I guess Mozilla is ignoring it for purposes of rendering. I guess the console is simply recording the fact that a CSS property isn't recognized and is being ignored. Not a problem to leave it as is then, right? —MichaelZ. 2006-09-15 00:44 Z
Wiktable caption-side
Is this change really a good idea? Some tables are very long. This should probably only be applied to short tables, or none at all. The results don't look much like the captions on images, anyway. —MichaelZ. 2006-09-14 19:37 Z
I agree. This is absolutely not the way that table captions are supposed to function. Unless I am very much mistaken, they are more accurately described as 'titles' or 'labels' than as captions. I intend to revert this change within the day. If it is necessary to have the caption at the bottom of a table, move it there manually within the article, either by moving the line to the bottom of the table or by using this particular CSS tweak. Ingoolemotalk20:10, 14 September 2006 (UTC)
I would disagree. Captions are captions and titles can (should) be done using === headers === . For long talbes the browser would be responsible for replicating the caption on each page. —Ruud22:53, 14 September 2006 (UTC)
No they shouldn't. See the example at left. Headers are intended to divide a document into sections, not to provide titles for tables. Are you suggesting that the infobox at the right should have a source code along the lines of
What about at Young's modulus#Approximate values, where a header is already included before the beginning of the table with text in between?
And of course, there is a very practical argument: every single table ever made on this site that uses captions was written with the intent that the caption be placed at the top of the table. Presumably, moving the caption will destroy how the tables were intended to be displayed. Ingoolemotalk02:06, 15 September 2006 (UTC)
I mostly agree. The infobox is not a good example, because usually only in-article data tables use class=wikitable.
Why not make it modular? Create another class for academic-style tables with smaller captions at the bottom. Call it wt-academiccaption. Use it like so:
Agreed, although I would propose making the default caption on the top and the "new" one on the bottom since every table previously created assumed that. Can someone change this soon so we don't have to go and fix every table on wikipedia? --Dpryan22:52, 15 September 2006 (UTC)
Of course. The whole point of this is that it is 100% backwards-compatible. Existing tables remain the same, but to change the caption position an editor can add a second class to the class attribute. By the way, the same could be accomplished by adding style="caption-side:bottom;" to the table. —MichaelZ. 2006-09-16 14:17 Z
Infoboxes are indeed a nice exception, but they use another class anyway. Could you provide some examples where a large header above a wikitable would be preferable over a section header? —Ruud19:17, 15 September 2006 (UTC)
I have reverted the change for reasons of proper procedure: it was inadequately discussed before being implemented. <self-satire class="tension-relieving">Please do not make changes to this page unless said changes have been submitted in triplicate to the Office of Formatting, with all the appropriate signatures.</self-satire>
Anyway, I would like to raise some points.
Firstly, the caption element (wikitext: |+ Caption text) is, unfortunately, rarely used on Wikipedia. However, I have never run across a caption that was not used as a title. Sadly, I have no examples that I can provide off the top of my head, but it's enough to make it clear that forcing the captions to the bottom would disrupt how the pages were supposed to display.
Ruud, you make several good arguments about how captions should be used. However, for all their merit, they ignore that fact that the caption element is used as a title on Wikipedia whether we like it or not.
I think that if you look in any academic reference, most tables have both titles (as the <caption> element is currently used on Wikipedia) and image-style captions. Let me give you one example.
The history of Brazil has been marked by a strong dependence on the external sale of its natural resources. It has also been notable for concentrating almost entirely on the sale of a single raw material, such as sugar in the 17the century, gold in the 18th, and later cotton, coffee and rubber. In this table, the pattern of Brazil's exports can be clearly observed, in particular the meteoric rise of coffee exports during the late 19th century.
Brazilian exports by decade In million kilograms per annum
Resource
1800-1820
1820-1840
1840-1860
1860-1880
1880-1900
1900-1920
1920-1940
1940-1960
1960-1980
1980-2006
Gold
6.5
1.3
1.5
1.1
0.9
0.8
1.1
0.7
0.3
—
Cotton
0.6
1.2
6.4
8.9
5.2
2.1
1.9
0.4
0.1
0.2
Coffee
0.2
0.4
1.2
3.6
2.1
19.8
10.1
5.4
6.2
7.1
Rubber
—
—
—
—
1.2
5.4
6.7
12.7
6.2
1.3
In my mind, this is the most logical way to format a table. The syntax would be something like
{|
|+ class="wikitable_academiccaption"|Caption
|-
|
{| class="wikitable"
|+ Title of table
stuff
|}
|}
That's a table within a table—a hack way to add two captions to one table in my opinion, but according to the HTML standard "A TABLE element may only contain one CAPTION element"[1] It's just not meant to work that way. —MichaelZ. 2006-09-16 14:17 Z
inadequately discussed before being implemented
I've brought it up afewtimes and got no response. Someone changed the caption format, so I changed it too, and suddenly there's a discussion! Like magic! :-)
Anyway, they should be at the bottom because they serve the same purpose as captions in images. This is the same way they would be presented in a book. A big title at the top of a chart is not a caption, but a title. The font size should not be big and bold like a title, either.
"the CAPTION element's text should describe the nature of the table" [2]
"Provide a caption via the CAPTION element. A table caption describes the nature of the table in one to three sentences. Two examples:
Who says it would be that way in a book? It would depend on the design of the book, and in many cases on the intent and design of a particular table. Since all captions have been at the top to this point, they shouldn't be unilaterally and universally changed to the bottom. And tables are not the same as images, so I disagree with your logic that they should be labelled the same way. A table that's three screens long shouldn't have its label automatically moved to the bottom.
Individual tables should be changed if there's a good reason to do so. In my opinion, the bottom caption is more of a convention from academic papers and books, and may be appropriate in technical or academic articles or topics where figures, graphs, charts, and tables are all used similarly. —MichaelZ. 2006-09-16 14:17 Z
As far as I can remember, I've never seen a table with a "caption" (infoboxes not included). Also, the "caption" was not large and bold until recently. It would be nice to have a list of tables (not infoboxes) with captions. —Ruud22:30, 17 September 2006 (UTC)
You should really have only archived things that were "finished"; now they're just going to be brought up again. And August is too recent. — Omegatron00:54, 18 September 2006 (UTC)
No big deal. If old things do re-pop-up, put a pointer into the archive. I agree though that up to August might have been a bit too early. But no harm done, Siva1979 did it fine in principle. Leave it as it is for now. --Ligulem08:32, 18 September 2006 (UTC)
Well, Omegatron, I will take your suggestions into account in any future archiving which I may be involved in. Thanks for pointing this out to me. --Siva1979Talk to me19:09, 19 September 2006 (UTC)
References small
Please revert combination of references small and references 2-column. Some people prefer single-column small references, and there are articles with layout assuming they will be a single column. Also, the 2-column CSS does not render as 2 columns on some common browsers. Gimmetrow21:52, 24 September 2006 (UTC)
Could you point out several articles where single-column, small-references are preferable over two-column small-references? Single-column, small referces tend to look bad. I don't think there is much reason to trouble editors with choosing between three styles of references instead of opting for large ones in the case of a small refences list or small (two-column) ones in case of a large list of references. (The fact that only recent browsers can render two-columns isn't a problem at all: this change didn't affect older browsers in any way.) —Ruud22:05, 24 September 2006 (UTC)
It is preferable to those who prefer it. Some editors consider two column footnotes to "look bad" in nearly all circumstances, so for them single column is nearly always preferable. The fact that some browsers to not render two columns is a problem, as it results in two different layouts. Only the most conscientious editors will verify the layout of both versions is acceptable. Gimmetrow00:48, 25 September 2006 (UTC)
Please stop changing the reference style for individual articles. If there is a good reason for references to be in a small font or double columns (there isn't), then get a majority of people to support it and the style will be changed for all articles. It needs to be consistent. There should just be a huge site-wide vote for it. — Omegatron00:55, 25 September 2006 (UTC)
Is there a template that produces a TOC listing only the top-level sections within an article (i.e. sections whose headings are created using the == Heading == syntax)...? There seem to be a fair number of templates that include "TOC" in their names, so apologies in advance if I've missed the one that fits the bill. Thanks, David Kernow(talk)23:40, 13 October 2006 (UTC)
There isn't one, it would require css changes or changes to the mediawiki code. However, it wouldn't be hard to create one by adding some css to MediaWiki:Common.css, such as:
You might convince them to add it to Common.css if you explain it is purely aesthetic and fails gracefully (worst case scenario: it displays all the levels). Alternately, you can remove the TOC via __NOTOC__ and create your own menu with anchor links (will have to be updated manually as sections change). A third option is to remove the section headers and use large text (not advised). --Splarka (rant) 07:29, 14 October 2006 (UTC)
Thanks for your various pointers, Sparkla; I'm making a copy of your paragraph for possible future reference. Since the amount of code to be added seems minimal (and non-invasive), I wonder if it might be incorporated by the powers that be sooner rather later – assuming no objections. Which of the various routes (Bugzilla, Wikimedia, ...) do you think stands the best chance...?
Meanwhile, I'm happy to continue constructing the occasional manual TOC for those pages with many sub(sub)sections, but yes, it's not a long-term solution. Thanks again, David(talk)01:13, 16 October 2006 (UTC)
Best case scenario: This would be a temporary css solution, just to increase demand for it, and possibly have it supported natively (such as adding parameters to exclude headings, like <H4 toc="false">, or having __TOC__ variations like __TOC2__ __TOC3__ etc). In the same way that HiddenStructure was replaced by ParserFunctions. --Splarka (rant) 07:20, 16 October 2006 (UTC)
Apologies; I meant to add the rationale as well as copying the posts. It's for those pages with many (sub-)subsections where a standard TOC uses a significant amount of vertical space, but where hiding the entire TOC in the usual way would impede navigation. Regards, David Kernow(talk)19:11, 17 October 2006 (UTC)
An option to spesify TOC "depth" would be handy for some non-article pages (long lists of various kinds), for example we recently modified the WP:IFD process to make each new image listing a subsection in order to allow section editing (since it was sometimes hard to find a particular image you wanted to comment on on huge list). This meant the default TOC was rater useless because it became incredebly long (every image listed for the last 5 days showed up). We "solved" the problem with a manualy edited TOC template with a couple of parserfunctions to keep the date list up to date, but an option to controll the level of headers included in the TOC would have been ideal in that situation... I think it would be better to get it implemented on the software side rater than as a CSS hack though (something like __TOC:3__ to include header levels 1-3 only for example). --Sherool(talk)05:53, 23 October 2006 (UTC)
Hiding links with new .admin class
I think it's a really bad idea to introduce new elements in MediaWiki message pages and hide them using CSS display:none with yet another CSS hack class: [4]. I don't see the purpose of a delete link on the what links here page (MediaWiki:Linkshere). This simply distracts, especially the non-admins, which seems to be the reason why people go for yet another client side hiding venture. This is just confusing and complete unneeded as admins do have a delete tab on each page, which non-admins don't have. Since we have currently two admins who disagree with me, I won't do anything more against that. But I strongly suggest we refrain from relying on yet another client side hiding feature. See also Wikipedia:hiddenStructure for why this is a bad idea (it was specifically deemed as bad by Brion Vibber, as you can read on that page). --Ligulem12:10, 22 October 2006 (UTC)
This is not a case where css-incapable browsers will display some odd kind of formatting or incorrect words or whatever. There is no delete tab on the whatlinkshere page, and since that is the last page an admin is supposed to check before deletion, a delete link on that page is very helpful. It is hidden by default for all users, and admins who want the link can add it themselves in their personal css. If a browser cannot handle css, it will simply display the delete link for all users, which is not the end of the world. —Mets501 (talk)12:52, 22 October 2006 (UTC)
I sure know that there is no delete tab on on the what links here page. It's on the page itself (one click away). Deleting is an important action that needs quite some consideration, so I don't see the point to have it so prominent. What's so difficult to click back to the page you are deleting? We have had it like this for a long time already and I don't see the point in adding a delete link on other pages. Really, I don't see the point in creating this confusion. The tabs at the top of the pages are sufficient. --Ligulem15:32, 22 October 2006 (UTC)
If the admin has to do something to enable this anyways, the entire link could just as easily be added using DHTML (i.e. custom Javascript for the admin). If there is not already an obvious structural element in the DOM to attach the link to, one unobtrusive way to do this would be to stick and empty span with an agreed-upon id attribute and have Javascript build and insert the link into the span. This does introduce extra markup into the HTML, but it will not be visible on any browser unless content is put into it with DHTML. They "hook point" would look like this: <span id="specialDeleteLink"></span>. I don't see why blind non-admins should have to suffer a useless link to make things easier for any admin. Mike Dillon14:40, 22 October 2006 (UTC)
Great idea, but can you figure out a way to pass the article title to document.getElementById('specialDeleteLink').innerHTML? —Mets501 (talk)15:43, 22 October 2006 (UTC)
Hmmm. It looks like you could rely on this: <h1 class="firstHeading">MediaWiki talk:Common.css</h1>. You'd have to turn the spaces back into underscores and do a little bit more work, but I think JS code exists for that part (possibly in User:Lupin's popups code). Finding the "H1" elements with getElementsByTagName and getting the one with "firstHeading" should be reliable (considering this is on a special page). Mike Dillon16:43, 22 October 2006 (UTC)
I guess that solution is a little too specific to the "What links here" page. It won't work on the "Moved page" page. I suppose the same sort of thing could be done with a marker class on spans around the links to $1 and $2 in MediaWiki:Pagemovedtext, instead of using H1.firstHeading. In those cases, the page name could either be extracted from the URL or the link text of the <A> tag. This may seem a little difficult to get right, but fortunately it only has to be done once per special page type and can then be reused. Mike Dillon17:12, 22 October 2006 (UTC)
Class for inline list
For use in template:Navigation bar I'd like to add a class that makes list items inline, like the following:
.scrollbarlist li {
display: inline;
}
This would allow the "list" parameter to be specified as an explicit list of items, allowing traversal between them using the JAWS screen reader (as it stands, the entire list is a single list item). This would facilitate JAWS traversal in a logically 2-level list, like Template:Footer Olympic Champions 4x400 m Men. Sound reasonable? -- Rick Block (talk) 16:30, 22 October 2006 (UTC)
hiddenStructure again
We seem to have yet another problem of ignorance regarding accessibility issues. See the reasoning of User:MatthewFenton at Template talk:Hiddenref. Do we really need to rule over minorities? Do we really need to discuss this again? We had all this discussed at nauseum on WP:AUM and Wikipedia:hiddenStructure. Carl and I are currently removing the hiddenStructure hack from a pile of remaining templates (see User:Ligulem/work/templates using hiddenStructure). Once this is done, I think we should finally remove
/* hiddenStructure from Monobook - allows selective hiding of markup in templates */
.hiddenStructure {
display: none;
speak: none;
}
No. As long as there is a hiddenStructure definition in for example http://en.wikipedia.org/skins-1.5/monobook/main.css (which is loaded before common.css) we should override it here. Removing the current hiddenStructure override from Common.css currently would simply reenable hiddenStructure as it was before. Plus the current marking helps identifying residuals/reinsertions. --Ligulem08:41, 23 October 2006 (UTC)
So wait, let me understand, you've decided to disable a component that was put into the MediaWiki software by the developers? Brazen. Where was consensus reached that HiddenStructure needed to be made extinct? -- Netoholic@17:36, 23 October 2006 (UTC)
Every meaningful style rule added to Common.css is disabling (or modifying) a component that was put into the MediaWiki software by the developers. I have no idea why Gabriel Wicke added the class to his skin, but I join Brion et al. in saying that it's a bad method for accessibility.
The class is not, by the way, ever used in a default MediaWiki install, so removing it doesn't break existing behavior if all templates are fixed. —Simetrical (talk • contribs) 04:48, 24 October 2006 (UTC)
The only reason hiddenStructure has stuck around this long is that it isn't easily traceable (by just clicking on a link). Community consensus from the 'AUM wars' was entirely clear... as were the developers. Hiddenstructure was a bad method for solving a 'performance problem' which didn't really exist. There is nothing which can be done with hiddenstructure that can't be done with parser functions... except that hiddenstructure works improperly on some browsers. Which hardly ought to be our goal. See other info on hiddenstructure and why it has been eliminated here. --CBD22:44, 24 October 2006 (UTC)
span.texhtml
I would like to propose that the following be added to Common.css:
span.texhtml {
font-family: sans-serif;
}
This would make mathematical formulas coded with <math> tags identical to formulas coded with HTML. Currently (for me at least), the formulas written with <math> look smaller and harder to read than the rest of the text and other formulas (compare , the first written with <math> and the second in HTML). For comparison, here's how the three ways to code math formulas compare:
This has previously been brought up with the mathematics community, who rejected the idea and explained how to use a personal style sheet. --KSmrqT22:40, 28 October 2006 (UTC)
I know how to use a personal style sheet, but I don't only care how it looks for me: I want it to look good for everyone who logs on to Wikipedia. —Mets501 (talk)22:44, 28 October 2006 (UTC)
I applaud this; everybody is always saying how people should just "use their own stylesheet". I've got news for you: people who are suggesting changes here do this because it's for the better of the community. Instead of lazily suggesting that people who want something changed should just do it on their own, you should instead seek to refute a proposal with good arguments if you don't like it. —msikma <user_talk:msikma> 15:12, 29 October 2006 (UTC)
The people who say "use your own stylesheet" are saying it because the proposed change is not good for the community, and should not be implemented site-wide. If people insist on a change that is not beneficial for others, we tell them how to make that change for themselves only. — Omegatron15:23, 29 October 2006 (UTC)
Then they should use arguments. It's happened too often that people have said no to changes without giving any argument except "why do this when you can add it to your own stylesheet?" That's what I mean should stop. —msikma <user_talk:msikma> 20:45, 29 October 2006 (UTC)
I personally like this suggestion. It adds semantic value to the italics and so forth in plain text, rather than their just being meaningless ''. —Simetrical (talk • contribs) 01:57, 29 October 2006 (UTC)
I was thinking change the <math> to sans-serif. Then <math> tags would be used more because there'd be no reason not to use them, making all equations standardized. —Mets501 (talk)
I don't understand. The HTML generated by math tags is serif, just like the PNGs. You want to change the math tags to a sans-serif font so that they match regular characters? — Omegatron13:50, 29 October 2006 (UTC)
I want to make all math equations standardized. I think we should either discontinue HTML equations or make the equations with <math> tags render in sans-serif. I'd much prefer the former, but the latter is much easier to do with just one style-sheet change. —Mets501 (talk)15:22, 29 October 2006 (UTC)
The equations are standardized. You're trying to make them different. Currently, the PNG images are a serif font and the generated HTML (inside .texhtml) is a serif font. You're trying to unstandardize them. — Omegatron18:35, 29 October 2006 (UTC)
We'd need to mandate <math> tags for math first. Currently, either <math> or manual HTML like x are allowed. See Help:Formula#TeX_vs_HTML.
I would like to see <math> made mandatory, but every time this is discussed, it is rejected. It would especially be better when we switch to MathML.
Maybe shortening the tag to <m> or using a different syntax like TeX's $...$ (or {{m|...}} or pretty much anything; typing less-than signs is a chore) would make it more likely to be adopted everywhere. — Omegatron18:35, 29 October 2006 (UTC)
That's a good idea. Making the math markup shorter and mandating it for future use would be much better. Maybe two dollar signs ($$)? Two dollars signs are only used right now in 164 articles, those could be changed. —Mets501 (talk)19:11, 29 October 2006 (UTC)
The reason that <math> is not mandatory is that it often produces crappy output. Compare (<math>A^+ - A</math>) with A+ − A (''A''<sup>+</sup> − ''A''). It may also produce PNG unnecessarily, for instance (<math>x \leq 0</math>) in running text looks better as x ≤ 0 (''x'' ≤ 0). -- Jitse Niesen (talk) 23:57, 1 November 2006 (UTC)
And the reason it produces "crappy output" is because it is rendered in serif. If it was changed to sans-serif then it would produce text output identical to HTML formulae. —Mets501 (talk)01:30, 2 November 2006 (UTC)
I'm not talking about the font (in fact, I changed my monobook.css to have sans-serif). The problem is that there is too much spacing around the superscript. -- Jitse Niesen (talk) 01:42, 2 November 2006 (UTC)
That's because there is whitespace between the <i>A</i> and the <sup>+</sup>. Other than that, there is absolutely no difference between the two except the surrounding <span> on the generated version. It seems like the spacing thing would be pretty easy to fix; I can't see why you'd ever want a space between a base and its exponent. Mike Dillon02:08, 2 November 2006 (UTC)
Yes, the whitespace is the problem; sorry, I should have made that clear from the start. However, it's not obvious to me how to fix the spacing thing. It's produced by m:texvc, which is written in OCaml and in my opinion not so easy to read. Not all exponents produce a space, for instance, there is no space in (<math>A^2</math>). I guess it has to do with the fact that we do want space around the plus sign in . -- Jitse Niesen (talk) 06:21, 2 November 2006 (UTC)
''A''<sup>+</sup> − ''A'' is no substitution for <math>A^+ - A</math>. The latter is the only correct version because it more accurately describes that this piece of text is a mathematical formula. You should never destructively alter information for good looks, since this will make it difficult for future uses of the text. For example, if Wikipedia articles are ever put together as one large Texinfo bundle, the mathematical formulas will have to be in <math>, otherwise they will need to be manually converted for the Texinfo source to be proper. Therefore, I implore you to only use <math> for things like this, and then figure out a way to make <math> look better, should it be required. —msikma <user_talk:msikma> 13:04, 2 November 2006 (UTC)
I don't think it should be changed. It seems that most of the books I have, even the modern ones that use a sans-serif font for normal text, use a serif font for mathematical equations. It seems similar to how code examples are almost always printed in monospace. —msikma <user_talk:msikma> 15:12, 29 October 2006 (UTC)
But at normal point sizes, I don't really think that serif fonts look very good on the Web. The print stylesheet could keep them serif (although I'm not actually sure how to do that, since this overrides both print and nonprint stylesheets). —Simetrical (talk • contribs) 20:16, 29 October 2006 (UTC)
I do think that sans-serif fonts usually look better than serif fonts on a screen, but feel that modern operating systems make it no longer matter that much anymore. There are still people who don't have anti-aliasing set on, but I think that this will rapidly decrease, especially if Internet Explorer 7 becomes a default Windows update (which apparently turns on Cleartext rendering, I've heard). But, all in all, your point is correct; sans-serif mostly looks and reads better. —msikma <user_talk:msikma> 20:48, 29 October 2006 (UTC)
Come to think of it, few printed books use sans-serif at all, so of course they don't use it for equations. What books do you have that use sans-serif for normal text? —Simetrical (talk • contribs) 20:18, 29 October 2006 (UTC)
Mostly modern college textbooks. You're right that few do. I still don't think that it's appropriate to use sans-serif for this, though. Maybe we should ask the mathematics community. They rejected the idea before, so they must have had good reasons for it. —msikma <user_talk:msikma> 20:45, 29 October 2006 (UTC)
It seems like a good reason that mathematics are typically defined with serif characters, such as greek symbols and operators (as mentioned in that discussion). —msikma <user_talk:msikma> 22:02, 29 October 2006 (UTC)
It may be important to note that PNGs are almost never used inline, perhaps making it more important for texhtml to look like plain HTML than the PNGs. —Ruud11:29, 1 November 2006 (UTC)
CSS Class for Mini-talk-page templates
Please see "Suggestion" section at this discussion. I would like to request a new CSS class created to create smaller talk page templates. I quote User:Kirill Lokshin, "The class should basically copy over the formatting of the normal messagebox.standard-talk, but force the width down and add a float". Can this be done? Thanks, Ganeshk(talk)17:59, 4 November 2006 (UTC)
If some of the style-sheet information is shared with another class, then don't duplicate it in the CSS, but apply multiple classes instead. For example, class="messagebox mb-mini". —MichaelZ. 2006-11-05 03:38 Z
How is this supposed to work? I added the code to User:Jitse Niesen/monobook.css and tried to use it on User:Jitse Niesen/sandbox, but it does not work as I'd expected. The message boxes are indeed shrunk (small width, small font), but they are centered (horizontally) on the page, with the text starting under them. The line spacing is also too big. Could you please give an example of how we are supposed to use this class? -- Jitse Niesen (talk) 00:41, 6 November 2006 (UTC)
That's because the code is wrong! ;-) It should actually be:
Kirill, it works for me. However, the line spacing is still too big. According to DOM Inspector, the computed line-height is 19px and the font-size is 10.7333px. I don't know enough CSS to understand what's going on. The only relevant thing I can find is #content { line-height: 1.5em; } in skins/monobook/main.css.
I also think that the box should be a bit wider. How about 315px, which is the width of Template:Archives (included at the top of this talk page)? At the moment, we can fit only about 20 words in the box. The spaces between the words are also rather big, because there are only 3-5 words per line. -- Jitse Niesen (talk) 05:18, 7 November 2006 (UTC)
Jitse, Thanks for correcting me. I got it working in my sandbox. How do we add, cellspacing="0"? Without it the box looks big. Compare the one on the left (zero cellspace) with the one on the right. Please advise. -- Ganeshk(talk)06:14, 7 November 2006 (UTC)
(de-indent) "cellspacing" is called "border-spacing" in CSS. However, I'm not sure it is necessary. At the moment, I'm using
I think it makes sense to define the background colour in CSS, even though the messagebox class does not do this. I'll check tomorrow how it looks on my desktop. -- Jitse Niesen (talk) 12:40, 7 November 2006 (UTC)
Implementation
Jitse, I used your code. It works great. How shall we add this to the main CSS page? I would like to start using it. -- Ganeshk(talk)18:13, 7 November 2006 (UTC)
It does not affect any existing things, so there is no harm. I've added it now. See [5] for how to add the optional small parameter. —Mets501 (talk)19:30, 7 November 2006 (UTC)
Hard-coding navbox width here at 100% could cause some problems, especially because smaller navboxes often look much better than ones that fit the entire page. If there are no objections, I move that we remove this clause from the CSS, because I don't think it really does anything useful. I can't think of any possible advantages of guaranteeing that every navbox on the entire site has 100% width. Karl Dickmantalk21:22, 8 November 2006 (UTC)
I object: having multiple navboxes with different widths in the same article looks horrible, see User:R. Koot/navbox. 100% makes the navboxes have the same width as the category bar, making them stand out less, which is a good thing in my opinion. —Ruud22:05, 8 November 2006 (UTC)
I maintain that all the examples have too many navboxes. WikiProject Aircraft, for example, discussed writing a policy that would essentially limit the page footer to no more than one navbox. Although the policy has not yet been officially implemented (added to the standards pages and applied to the articles), it received virtually no objections. Karl Dickmantalk00:47, 9 November 2006 (UTC)
metadata
I have some trouble exactly defining what this class is ment to me used for, it's defined only as:
wich makes no sens at all (border and display:none for the fist, and defined for tables only for the second). I think it's ment to be like this:
.metadata {
display: none;
speak: none;
}
Off course this will require a lot of maintenance templates to be changed, as a lot of notices are defined as metadata. →AzaToth15:34, 14 October 2006 (UTC)
Thanks for pointing out the more widespread use of .metadata. I looked at Wikipedia:Catalogue of CSS classes to see what it said about .metadata and it doesn't match with the current usage in CSS. The note about .metadata was added by User:JesseW in March 2006. The description "Used to mark metadata that should not be printed (?)" seems to be an attempt to describe this rule in Common.css, which at that time did just what it does now, completely hides all tables of class .metadata while giving them a thin grey border when they made visible (for all media, not just print).
The creation of the Persondata project page and the addition of this CSS rule were done on December 22, 2005 by User:Kaldari. This is where it gets interesting. I looked at the history of {{Cleanup}} to see if it was using .metadata on the day this rule was added to the stylesheet. It was using the .metadata class and moreover, the template was also using a <table>! So on December 22, all cleanup notices became invisible in CSS browsers. On seeing this, User:Belandreverted{{Cleanup}} to a previous version that used a <div> on December 23 with the message "The blue box is no longer showing up for me; reverting to older non-broken version", not suspecting that the cause of the problem was really with the new CSS rule added by Kaldari.
That sounds fine to me. I just went with a more generic class name since I thought similar projects might also want to make use of the class, but that hasn't happened. I was not aware that there were any other templates using a class named "metadata". Sorry for the confusion. Kaldari06:57, 23 October 2006 (UTC)
Migrating from .metadata to .persondata will be a bit tricky. As best as I can figure out, the steps for such a migration would be:
Add new .persondata class
Edit Persondata template to use .persondata class
Wait until all 3,000 or so article caches have been refreshed (no idea how long this would take)
Remove the .metadata class
Two questions: Is this the best way to proceed? Is there a specific time-to-live for article caches or would we have to wait until every article has been edited or purged? Kaldari00:55, 25 October 2006 (UTC)
Most changes to templates go live immediately: all the appropriate pages are just purged from cache, and are rerendered the next time someone visits. The only exception is category links, since those take much longer to update; those are done on the job queue, as time permits (see Special:Statistics for how long the queue is at any given time). At least, that's my impression. —Simetrical (talk • contribs) 01:16, 25 October 2006 (UTC)
I'm not talking about .persondata, but #persondata. Since the id="persondata" is already on the template, there will only be the issue of CSS caching, about which browsers are pretty aggressive. I would change the CSS rule to "#persondata" first and remove class="metadata" in a day or two. Mike Dillon01:45, 25 October 2006 (UTC)
Persondata is now visible on Wiki pages, and causing some angst (e.g. a well-meaning user deleted the persondata from John Howard). I think this is due to the latest change to the commons.css. Rocksong09:13, 27 October 2006 (UTC)
Yes, this is now a major problem. Persondata is visible, and many users are deleting it from pages. We need to fix this right away. – Quadell(talk) (random)15:35, 27 October 2006 (UTC)
Kaldari's changes were sound. The problem was almost certainly CSS caching in the affected users browsers. I think there just needs to be a few days wait to let everyone pick up the latest version of Common.css and then the change to {{Persondata}} will be safe to make. The only reason Persondata would have started showing up is if the user's browser had not yet picked up the new .persondata classes. Internet Explorer in particular is very aggressive about caching CSS. Mike Dillon16:17, 27 October 2006 (UTC)
As I stated in Wikipedia talk:Persondata, I think we need to apply both classes to the template, for the time being. That way, anybody who has an old copy of the stylesheet in their cache won't see the persondata. After a while (months?) the extra class can be removed. —TheMuujTalk21:52, 27 October 2006 (UTC)
OK, I'll wait a month or so before making the switch. Unfortunately, it is not possible to assign two classes to the same template, but I'll be sure to wait an additional month or so before removing the .metadata class from Common.css. Does anyone know if there is a hard limit on how long Explorer will cache a CSS file? Kaldari22:32, 1 November 2006 (UTC)
As I have stated before, we can apply both classes to an element, so I went ahead and did so. My custom stylesheet works, as should most previous stylesheets. —TheMuujTalk03:30, 2 November 2006 (UTC)
Thanks for updating the {{Persondata}} template. The declarations for table.metadata and .metadata-label can be removed from MediaWiki:Common.css. For those who aren't keeping track of all this:
{{Persondata}} now has both .metadata and .persondata
That means it is hidden for anyone with an old copy of Common.css (without .persondata), since the template still has .metadata
It also means the template would be hidden for anyone with a new copy of Common.css if table.metadata were removed, since the template now has .persondata
For anyone who wants to see Persondata, this would similarly work whether or not table.metadata and .metadata-label were removed from Common.css, since the template still can be made visible using either of its two CSS classes
Once table.metadata and .metadata-label are removed from Common.css, all remaining coordination can be done within the Persondata project
It should be possible using search to find users with "table.metadata" in their monobook.css and tell them to change to table.persondata. Once that is done and the docs are updated, in a couple weeks the "metadata" classes can be removed from {{Persondata}}. Mike Dillon04:05, 2 November 2006 (UTC)
Don't remove .metadata just yet. I'm not convinced this is a better plan than our original course of action. For one thing not all browsers support multiple class definitions. I haven't researched this yet, but I know that at least Netscape 4 doesn't. We should try to make sure that the impact of this change is as minimal as possible. It may be that TheMuuj plan is the best course of action, but let's not rush into it without thinking everything through and getting agreement first. Kaldari05:51, 2 November 2006 (UTC)
Every browser created in the last 4-5 years supports multiple CSS classes. Netscape 4 is totally negligible. Having 10 years of web development experience, I can tell you that TheMuuj's plan is the best course of action. Mike Dillon15:19, 2 November 2006 (UTC)
Now that over a month has passed, does everyone think it is reasonably safe to remove the .metadata class? Kaldari19:35, 3 December 2006 (UTC)
Should be OK. We can try removing the "metadata" and "metadata-label" classes from the template first and see if anyone complains. It should have the same effect since it will make the CSS declaration have no effect. Perhaps a temporary link could be put into the template to tell people who are seeing it without enabling personal CSS where to report problems. Mike Dillon20:14, 3 December 2006 (UTC)
Unfortunately, search seems to not be working at the moment, so we can't see if there are still people with "table.metadata" in their CSS. Those people will stop seeing the Persondata box. I expect there probably are... Mike Dillon20:22, 3 December 2006 (UTC)
I just ran the search and it shows 175 hits for "table.metadata" in the User: namespace. Here's a list of all the people who seem to have "table.metadata" in their personal CSS (152 of them): User:Mike Dillon/.metadata users. So, if we make the change, Persondata may disappear for 152 editors who have enabled it. I didn't check if any of them had the CSS commented out. So, we might want to get a bot to leave a message on all of their talk pages. I don't think any bots have admin access to make the changes automatically. Mike Dillon17:39, 4 December 2006 (UTC)
Per the Wikipedia:Catalogue of CSS classes description ("Used to mark metadata that should not be printed (?)," which made sense), I have been using .metadata on cleanup templates. As it makes intuitive sense for notices to be defined as "metadata", I think we should just make the class do what is least surprising -- namely, don't print.
From monobook.css:
@media print {
/* Do not print edit link in templates using Template:Ed
Do not print certain classes that shouldn't appear on paper */
.editlink, .noprint, .metadata, .dablink { display: none }
#content { background: #FFFFFF; } /* white background on print */
}
I'm not sure if you missed it, but the reason may be that there is a more specific and conflicting use of this CSS involving the {{Persondata}} template. Once we've finalized cleaning up that template's use of this class, it will be fully in line with the stated use at Wikipedia:Catalogue of CSS classes. That being said, adding these changes for "@media print" would not really affect the Persondata usage since it is screen-oriented, so it may be safe to do now. Read my second message in this thread for the history of how we came to be in the current situation with this class. Mike Dillon05:48, 8 December 2006 (UTC)
They used to be bold when viewing diffs, but not when viewing a user's contribs. (This was before they existed on page histories) – Gurch12:25, 23 November 2006 (UTC)
Improving template code
We should start to improve the code used in templates to conform to good authoring practices. As a "free encyclopedia", wikipedia should do more than pay lip service to accessibility, especially when improving accessibility will also improve the code, reduce the size of the code, and require very little effort to implement. —MichaelZ. 2006-11-06 22:02 Z
Classes instead of id's
Disambiguation templates such as template:Disambig have <div class="notice metadata" id="disambig">. The #disambig id should be changed to a .dabnote class (changed the name to avoid confusion, and harmonize it with .dablink). There is no guarantee that only one disambig template will ever be added to a page, and HTML strictly requires id's to be unique on the page. The div tag would be <div class="notice metadata dabnote">. —MichaelZ. 2006-11-06 22:02 Z
This template message needs only a single div, with left padding and the image added in the background. Unfortunately, I can't enter an image into wikitext, so I can't show an example here, and this will have to be implemented as a class in the style sheet—that's the right way to do it anyway. The result will look the same in a visual browser, but avoid presenting screen readers with an un-summarized table to read or skip, and will reduced the amount of code in the page.
Min-height isn't supported by MS Internet Exploder 6 (nor, I think, by 7), but this is just a fallback to ensure modern browsers draw the box correctly. The notices will still draw acceptably even in MSIE, as long as they contain some text.
The wikitext of the template would be greatly reduced from this:
<div class="notice metadata" id="disambig">
{|style="background:none"
|style="vertical-align:middle;"|[[Image:Disambig gray.svg|30px]]
|style="vertical-align:middle;"|''This [[Wikipedia:Disambiguation|disambiguation]] page lists articles associated with the same title. If <!-- you are viewing this online as opposed to as a [[hard copy]] and -->an [[Special:Whatlinkshere/{{NAMESPACE}}:{{PAGENAME}}|internal link]] led you here, you may wish to change the link to point directly to the intended article.''
|}</div>
To this:
<div class="notice metadata dabnote">
This [[Wikipedia:Disambiguation|disambiguation]] page lists articles associated with the same title. If <!-- you are viewing this online as opposed to as a [[hard copy]] and -->an [[Special:Whatlinkshere/{{NAMESPACE}}:{{PAGENAME}}|internal link]] led you here, you may wish to change the link to point directly to the intended article.
</div>
Output of the page will have the following code reduced from this:
<div class="notice metadata" id="disambig">
<table style="background:none">
<tr>
<td style="vertical-align:middle;"><a href="Image:Disambig_gray.svg" class="image" title=""><img src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Disambig_gray.svg/30px-Disambig_gray.svg.png" alt="" width="30" height="23" longdesc="/wiki/Image:Disambig_gray.svg" /></a></td>
<td style="vertical-align:middle;"><i>This <a href="Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="Special:Whatlinkshere/Template:Disambig" title="Special:Whatlinkshere/Template:Disambig">internal link</a> led you here, you may wish to change the link to point directly to the intended article.</i></td>
</tr>
</table>
</div>
down to this:
<div class="notice metadata dabnote">
This <a href="Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="Special:Whatlinkshere/Template:Disambig" title="Special:Whatlinkshere/Template:Disambig">internal link</a> led you here, you may wish to change the link to point directly to the intended article.
</div>
That's a reduction from 817 characters to 413. On one of the busiest sites on the Internet, even such a small reduction multiplied by billions of page views will save someone the cost of a server somewhere. There are probably many other templates which could benefit from such optimization. —MichaelZ. 2006-11-06 22:02 Z
Thanks. This doesn't mean much, but to give an idea of the magnitude, if each of those pages were transmitted only once, then this change would save 27.33 MB of transfer. Anyway, the important principle is to always reduce code where there are only positive side-effects.
(That also means we should get this right the first time, and not revert-war over changes to the template :-))
(Q1) How do you count the transclusions without paging through 142 "what links here" listings? (Q2) Does that include the template's redirected synonyms, like template:Disambiguation? —MichaelZ. 2006-11-06 23:01 Z
Update: I changed the class name to dabnote, avoiding confusion with the id name, as well as harmonizing with .dablink and saving another byte. —MichaelZ. 2006-11-07 00:06 Z
Looks good to me. Making the site more accessible to all users, not just traditional browser users, is always a good thing. EVula05:26, 7 November 2006 (UTC)
A couple of issues:
The text is no longer vertically centered . . . because it's impossible to vertically center anything in CSS 2.1 except for table cells. That's not noticeable here unless you turn down font size a lot, at least not on my browser, but I note this because it's an issue for things like copyright templates.
While Template:Disambig is already protected, using this treatment for most other templates would mean a sysop would need to change the background image, and a normal user couldn't.
Using background-image means that the image's location won't be immediately obvious, since it's not clickable, and so it will be more confusing to change. That's why the software deliberately does not support easy use of unclickable images.
Tables are so ubiquitous as layout elements that I strongly suspect that no user agent actually assigns them semantic value (unlike pretty much every other semantic tag). I would welcome counterexamples, but until you come up with one this looks like a solution in search of a problem.
You could pare down the table markup as follows:
<table class="notice metadata dabnote">
<tr>
<td><a href="Image:Disambig_gray.svg" class="image" title=""><img src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Disambig_gray.svg/30px-Disambig_gray.svg.png" alt="" width="30" height="23" longdesc="/wiki/Image:Disambig_gray.svg" /></a></td>
<td>This <a href="Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="Special:Whatlinkshere/Template:Disambig" title="Special:Whatlinkshere/Template:Disambig">internal link</a> led you here, you may wish to change the link to point directly to the intended article.</td>
</tr>
</table>
That's 703 bytes, just over a third of your reduction. Byte count is not, of course, a major issue, at least not on the scale of a couple hundred bytes a page.
Web standards are not always the best choice. They just generally are. When they confer no benefit whatsoever, there's no point in sacrificing ease of use or even prettiness for their sake. By all means move inline style to classes, and change the id to a class, but don't move the image to CSS or change the table to a div. —Simetrical (talk • contribs) 21:41, 3 December 2006 (UTC)
I'm pretty sure the image clicking thing has more to do with providing one-click access to the image details to comply with the GFDL. Mike Dillon22:57, 3 December 2006 (UTC)
By the way, if you can't figure out how to get an element to behave as well as the table did, you can always just use display:table and make it behave like one. — Omegatron00:30, 4 December 2006 (UTC)
Many cleanup templates use the messagebox style and a table to align images. This table must have the attribute style="width:100%;background:none" to behave as expected. Can we add the following to common.css?
The stylesheet is perfectly valid CSS3, the validator doesn't seem to correctly validate anything beyond 2.0 (including the "vendor-specific extensions" from 2.1, also see the validator's README). —Ruud13:24, 17 December 2006 (UTC)
The larger the better. No problem with increasing to 92%. It just hope this change won't disturb the current wiki-peace about the fontsizes.... :] --Ligulem23:09, 18 December 2006 (UTC)
85%
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
90%
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
91%
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
92%
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
93%
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
100%
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
This is weird. When I poked around the css, I found content being 11pt. But it seems that 100% is actually 10pt. Anyone has an explanation?
8pt
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
9pt
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
10pt
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
11pt
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
OK, back to the original question. As long as the output is the same in both browsers, with default settings, that's good enough for me. That means 85% or 92%, but not 90%. However, I actually find 85% better. Just look at United States, there are 107 references! --ChoChoPK (球球PK) (talk | contrib) 20:06, 18 December 2006 (UTC)
Windows 98/Internet Explorer 6.0/ArialLinux/Firefox 2.0/Bitstream Vera Sans
Oh gee. Look at that screenshot with font hinting in Linux. So THAT's why that guy kept complaining that he found 90% too small, and that we should use 92% instead. He just doesn't like small text at all, he would rather have the references look almost the exact same as 100%. References are supposed to look small. They do look smaller now that we use a font size of 90%. But if we change it to 92%, that means that the references will appear almost completely identical to most Linux users (most distros have Bitstream Vera Sans and have font hinting set to medium/high). This reduces cross-platform consistency pretty badly. functionmsikma(user:UserPage, talk:TalkPage):Void11:47, 19 December 2006 (UTC)
This proposal is partly motivated by a desire for a consistent appearance, and to reduce the instances of style="font-size:XX%" on individual wikipages. {{FootnotesSmall}} is one of the larger systematic sources of font-size tags, and it sets font-size to 92%. The custodians/users of that template have been resistent to replacing style="font-size:92%" with class="references-small" within the template because of the 90%. Gimmetrow21:42, 20 December 2006 (UTC)
I'm talking about cross-platform consistency. If all font sizes for the references were at 90%, they'd be more consistent than if they were all at 92%. I believe that 85% may be even better. Again, I should mention that the purpose of having a smaller font for references is so that they look smaller... not so that they look nearly the exact same as normal text. That's really my gripe with this. functionmsikma(user:UserPage, talk:TalkPage):Void22:58, 20 December 2006 (UTC)
Allow me to reiterate my point. I want consistency between different browsers like everyone else here. So 90% is ruled out. So I am faced with the choice of 92% or 85%, where 85% will look the same as 90% in Firefox. I'm more inclined toward 85% because references are just supporting parts. Nobody reads references one by one as if they are texts. At least I don't. They are there just to prove the accuracy of things. --ChoChoPK (球球PK) (talk | contrib) 23:02, 20 December 2006 (UTC)
My point is that as it currently stands, some articles have 90% notes, and others have 92% notes. Even from the same browser some articles look different than other articles because not all are using the CSS class. If the CSS had 92%, we could eliminate one of the largest cases not using the CSS class. If that could be done without upsetting other things, great! If not, that's fine too. Gimmetrow23:46, 20 December 2006 (UTC)
We don't have to bend over backwards for things that don't have consensus. If consensus is against 92%, then change the template to 90%, and if someone gets ornery and refuses to accept consensus, follow the usual procedures. I'm agnostic on small refs, but I agree that 92% is basically indistinguishable from 100% on Firefox. —Simetrical (talk • contribs) 07:02, 21 December 2006 (UTC)
{{Infobox Country or territory}} correctly implements row groups (several rows enclosed by the same visible borders) with the first being mergedtoprow, the last being mergedbottomrow, and everything in between with mergedrow. Examples include {{{leader_title1}}}, {{{leader_title2}}} ... up to 5.
All these leader titles are optional. So any one of them could be the last one. {{Infobox Country or territory}} handles this by something like
This is to assume that editor will always fill the leaders with the correct sequence from 1 up. This may not be perfect, but good enough. However, I'm facing a difficulty with {{Infobox Currency}}, which is being sandboxed at User:Chochopk/Template sandbox 2. In the currency infobox, there are many row group where any attribute is optional, and there's no sequential dependency. The prime example is the subunit symbol. It is not at all unlikely that there is no symbol for subunit 1, but there is for subunit 2, like the case for the United States dollar. The same problem exists on nickname, ERM, used coins and banknotes, etc.
So I have no way of telling which row is the last row. Let's say that I don't insist on the 0.4-0.2-0.4 set up, I use 0.4-0.4-0.4. I have 2 ways of doing this:
write style="padding: 0 0.2em 0.4em 0.8em;" for many many rows in my infobox
add something like mergedrow2 or mergedrowThatCouldBeTheLastRow to the css with 0 0.2em 0.4em 0.8em
#1 is a hack and impractical to deploy widely to similar infobox, and I don't have the permission to do #2.
We should not be writing specific infobox classes, and definitely not overriding the colour. Can't you just use the mergedrows class? ed g2s • talk17:39, 24 December 2006 (UTC)
OK, I can use inline style, I'm fine with that. But what's up with the recent change about "moving style to monobook.css"? I use monobook and {{Infobox Country}} an {{Infobox Currency}} certainly look different. Isn't this supposed to be just a move? I don't see .infobox.geography anywhere. --ChoChoPK (球球PK) (talk | contrib) 21:00, 24 December 2006 (UTC)
Removal of styling information for wikitable and infobox classes
I have reverted this on the grounds that there seems to have been no discussion of this change at WP:VPT. Before making such drastic changes, please make sure that you actually have people who support your decision. So far, at least two of us have reverted you. Karl Dickmantalk22:54, 25 December 2006 (UTC)
Nothing's changed, I just moved the colour over to monobook, as the colour is skin specific. If you are using a different skin, then add the correct colours to the skin file. ed g2s • talk04:31, 26 December 2006 (UTC)
Removal of geography related classes
Re: [6], [7]. I cannot find discussion/consensus for these edits, at least not for the second one that removed a group of classes that are in use for example on prominent template:Infobox city ([8]). I suggest discussing such drastic changes before removing classes that are in use, especially on a holiday. I have thus reverted the second edit for now. --Ligulem23:43, 24 December 2006 (UTC)
ed g2s, I haven't researched to that extent for discussion or lack thereof, so I can't comment on that. But I don't think it matters that much how these classes came into Common.css. Removing them while they are still in broad use is not a good idea. At least you should have given due notice before removing these classes, so people would have had a chance to orphan them (if that would be the consensus, which I doubt). Jumping in here at Christmas and removing them seems a bit odd, but after all we can revert, which I have done, so I bear no grudges :-). On a second note: I'm not much of a web content specialist or Wikipedia site architect so I could be wrong, but I currently can't see what's that bad in having more style info in the style sheets instead of hard coding it into the infoboxes. Maybe a style for every individual infobox would be too much but these classes seem to cover a whole prominent group of boxes as I understand it (geography). --Ligulem09:49, 25 December 2006 (UTC)
Btw, #aaa is a little too dark, don't you think? I don't know why the original color #ccd2d9 isn't pure gray, but something close to that would be nice, like #d0d0d0. --ChoChoPK (球球PK) (talk | contrib) 03:17, 25 December 2006 (UTC)
Per above, the geography class is also used by template:Infobox country (and a few others). The colors came from a version of the country infobox. If the background colors are to be moved to the skin css files, that's fine with me - but it seems this should be done before deleting the color here. There are also a fair number of skins in addition to monobook, so there should perhaps be a default color here as well. -- Rick Block (talk) 03:39, 25 December 2006 (UTC)
The class itself has nothing to do with geography, if we need another type of general purpose infobox, give it a proper name.
The colours do not need to be changed. If they do then propose a change to the infobox class at monobook.css.
Common.css currently contains a comment "styles for geography infoboxes, e.g. countries, country subdivisions, cities, etc." and there is a ".infobox.geography" which is used as class="infobox geography" for example in Template:Infobox City. What's wrong with that naming? --Ligulem16:18, 25 December 2006 (UTC)
Because there's nothing geographic about the class, nor is there any reason why it should be limited to geography related infoboxes. It's just an infobox redesign. ed g2s • talk20:05, 25 December 2006 (UTC)
The class was started as a centralized place to keep fancier style information for templates like template:infobox country than just plain infobox. The country infobox had custom style information giving it quite a "prettyfied" look. Through a fair amount of discussion, I managed to get the editors at both the country and city infoboxes to agree to extract the style information to a centralized place. Given the extremely widespread use of the plain infobox style, I thought directly changing it was not appropriate. My master plan was (still is) to convert all georgraphy related infoboxes to use this style, see Wikipedia:Geographical infoboxes. Very few editors commented on this proposal, so it cannot be said to have widespread support. The style indeed does not have anything semantically to do with geography - although using it for all geography related infoxes seemed like an ambitious but not absurd goal. It could be called nearly anything as far as I'm concerned, perhaps prettyinfobox (mirroring prettytable). -- Rick Block (talk) 22:27, 25 December 2006 (UTC)
ed g2s: ".infobox.geography" for cities and countries fits quite well. If you disagree with that naming, then you can do so. I suggest we move on and you leave the style sheets as they are. Ok? --Ligulem23:08, 25 December 2006 (UTC)
I understand that the class itself is merely a css class and has nothing to do with geography. Using the class on a non-geographic infobox, such as {{Infobox Currency}} may be misleading, but misleading only by name. Technically, the syntax is still correct. Ideally, I would like to change the class to something like "prettyInfobox". But we need a way to exhaustively list all places, template or mainspace alike, that use infobox.geography. --ChoChoPK (球球PK) (talk | contrib) 00:53, 26 December 2006 (UTC)
For backward compatibility purposes, I suggest we simply add a more generic synonym for the style name. I'm OK with it, but it may be worth noting ChoChoPK's "prettyInfobox" suggestion does not exactly parallel "prettytable". -- Rick Block (talk) 16:25, 26 December 2006 (UTC)
I happen to agree with Rick Block and Liqulem. This change was discussed a while ago and agreed upon. This would have been the first complaint since then. I think that there is a majority that supports the class="infobox geography" and doesn't want it changed. my two cents. —MJCdetroit21:56, 26 December 2006 (UTC)
"geography" is an absolutely absurd name for a class. Just because it was developed on geography pages, it has nothing to do with geography. I know that's the infobox it was designed for, but as a classname it is completely meaningless. If we create a new infobox subclass everytime someone thinks they've made a prettier version for their set of infoboxes, we'll soon end up with a large and confusing set of classes. If this class builds on the infobox class in a useful way, we need to establish:
How it differs from the normal infobox.
Which of those differences we actually need.
What the class should be called, and when it should be used.
How it differs is that it's like a bordered infobox but with a default of left aligned (90%) text, without a "center" dividing line, and with different border treatment (spacing and color). User:CieloEstrellado created this version of the country infobox using completely inline styling (including font overrides and a non-CSS "not quite full width border" not reflected in the "geography" style) which apparently had reasonably strong support as an improvement over the previous version. It took some doing to get the country infobox folks to accept a css-based style. Do we actually "need" these differences? Well, I think there's a pretty good argument that "plain" infoboxes are simply too plain for many users' tastes. I don't think anyone is trying to defend "geography" as a name (I'm certainly not), but I don't really have a good suggestion for an alternative. bordered-leftaligned-nocenterdivider? The previously suggested prettyinfobox? I think it might be reasonable to make the border spacing change part of the default infobox, but I'd expect adding a default for left aligned and dropping the center dividing line would not be welcomed by at least some users. As to when it should be used, I'd start with geography related infoboxes but I'd be OK if it (gradually) spread to nearly all infoboxes. -- Rick Block (talk) 04:31, 27 December 2006 (UTC)
Ed: In reply to "geography" is an absolutely absurd name for a class. Just because it was developed on geography pages, it has nothing to do with geography: I disagree. I see nothing wrong with having an infobox class for a top level kind of articles. If you take a look at the main page you will notice that there is a link on the top right corner which reads geography, which is about places. Wikipedia is among other things about places and people. Now we sure can go specializing "infobox" for these kind of top level article areas. I'd rather would like to keep that name and not go for names like "bordered-leftaligned-nocenterdivider". That would be absurd. And diffcult to track for usage. So I repeat: let it be as it is for now. Starting with an infobox geography for a specialized infobox is a reasonable approach and we shouldn't kill such a venture in its start. Let's see how that develops. --Ligulem12:14, 28 December 2006 (UTC)
Just to be clear about it, bordered-leftaligned-nocenterdivider was not a serious suggestion, but merely meant to show the difficulty of coming up with a precise functionality-based name (which I think is what Ed 2gs would prefer). -- Rick Block (talk) 16:34, 28 December 2006 (UTC)
Can you make the horizontal lines not touching the left and right borders, without inline CSS? IMHO that style is better looking, but I prefer a centralized depository of style over prettiness. --ChoChoPK (球球PK) (talk | contrib) 05:44, 27 December 2006 (UTC)
You can do not quite full width horizontal lines (per cell) with CSS using the border-spacing attribute (see User:Rick Block/Template:Infobox Country), but this is not supported by IE (at least not IE 6, which is really not acceptable for this site). How it was done in the "prettified" country infobox was with a borderless table (but with horizontal separating lines) inside a bordered table, i.e. not using CSS. -- Rick Block (talk) 15:29, 27 December 2006 (UTC)
Yes. Anything you can do with a "style" attribute can be made into a CSS class (that's sort of the point of "style"). The problem is that CSS support varies by browser, so some of the fancier things (that are defined as "standard" CSS) can't be done in a way that works for all browsers. -- Rick Block (talk) 03:56, 28 December 2006 (UTC)
Why can't this be done with the .mergedrows classes then? Also the problem with the geography name is not only that it is bad, but that it paves the way for .science, .maths, .spanishfootballteam etc. We don't want to be creating a new infobox subclass everytime someone thinks they have a better design, we want one design for each purpose. This stylesheet is supposed to give consistency to common elements. ed g2s • talk18:25, 28 December 2006 (UTC)
<just kidding>Do we have a ".spanishfootballteam" portal :-)?</just kidding>. Seriously, trying to harmonize the infoboxes inside a field like geography is actually about reducing the differences of looks of infoboxes (BTW a difficult consensus building process which Rick Block has been doing). This is what CSS is supposed for, isn't it? Suggestion: can we agree that we disagree and that there is no consensus for the removal? --Ligulem00:00, 29 December 2006 (UTC)
Not really. Why should we have two different infobox classes? Why do geography infoboxes need to be different to other infoboxes? We don't have subject-based thumbnail classes, or subject-based TOC classes. This class only exists because something thinks they've made a better version of the infobox class, and while that may be the case, they should come here and discuss why it is better. If it is decided both versions are needed, then we should create a suitably named class. We don't create new classes for common elements everytime someone thinks they have a better version, or we'd have a mess of a site. ed g2s • talk
You know that everything can be done without using CSS at all. And that's actually what's happening. Editors hard code all style things into the templates and that's what exactly causes all these boxes making looking so differently. If you remove the classes here, you don't change the articles. People will resort to hard code everything into the templates again. --Ligulem00:20, 29 December 2006 (UTC)
Addendum: If we look for example at Category:Infobox templates#Category scheme there are roughly 17 top groups of infoboxes. Given the prevalence of infoboxes on Wikipedia, would it really be so bad to have a maximum of one CSS style for each these? If it is bad, is there a technical reason? I believe nobody is asking for a CSS class for each and every single infobox template. --Ligulem00:14, 29 December 2006 (UTC)
This whole conversation is kind of ironic since the reason I added this class in the first place was to increase the similarity of the various infoboxes used in articles that a single reader might well be expected to view in fairly rapid succession (e.g. some city, then some U.S. state, then a country). I'd be happy with banning template-specific styling to force the styles to be defined here. As it stands, as Ligulem mentions, chaos reigns because users customize infoboxes in individual templates. My guess is there are something on the order of 10,000 infobox templates. If we can create as few as 20 classes and eliminate custom styling within these templates I think we'll have accomplished a miracle. -- Rick Block (talk) 01:11, 29 December 2006 (UTC)
People hard code style because the current classes don't offer enough. We only need one class that works properly, with options for cell grouping etc. All the geography class does is some fancy cell grouping. And what makes you think it will stop at 20? We don't want to open up a stylesheet free-for-all. I will have a look at what the class actually does at some point and try and rewrite it. ed g2s • talk04:14, 29 December 2006 (UTC)
The geography class is almost perfect, with grouping of rows and stuff. But I raised a question above. There is a difficulty when dealing with many rows in the same group all being optional. We probably need one more subclass in addition to mergedtoprow, mergedrow, and mergedbottomrow. Currently these 3 class works in Infobox Country because leader_title5 must co-exist with leader_title4, leader_title4 must coexists with leader_title3, etc. So the last leader can be determined. That is not the case of everything is optional and there's no dependency among them. --ChoChoPK (球球PK) (talk | contrib) 05:34, 29 December 2006 (UTC)
The only difference between mergedtop, merged, and mergedbottom is the vertical spacing - within the class a row has 0.4 em top and bottom, so a mergedtop has 0.4em at the top and 0.2em at the bottom, a merged row has 0.2em top and bottom, and a mergedbottom has 0.2em at the top and 0.4em at the bottom. If everything is optional, I'd use merged for all the optional rows, terminating the group with a subsequent plain row or a mergedtop for the next group. -- Rick Block (talk) 05:45, 29 December 2006 (UTC)
What talk page headers was reducing the font size of this disrupting? In general, a template needs to handle various sizes properly anyway, because people are using different systesms with different font sets and using different sizes. —Centrx→talk • 23:41, 30 December 2006 (UTC)
It wasn't disrupting in the sense of breaking, but it looked awkward on templates that were not talk page templates but were using that class (which is actually a surprising number of templates). —Mets501 (talk)02:51, 31 December 2006 (UTC)
Okay, we should move those to a new class then. Why are people using "standard-talk" on things that have nothing to do with talk. Not having to making individual edits everywhere is the whole point of CSS. —Centrx→talk • 03:26, 31 December 2006 (UTC)
Things like {{bot}} looked sort of awkward. It's really the main focus of a bot's userpage, and yet it would be small if the font size were changed. —Mets501 (talk)16:07, 1 January 2007 (UTC)
We recently modified the NavFrame and collapsible tables JavaScript. Previously, you could not mix classes with NavFrame / NavHead / NavContent. You would have to use inline styles.
Now, you can use other classes (ie. class="messagebox standard-talk NavFrame"). However, this causes a problem; because of the styles applied by Common.css to Nav* elements, the other classes' styles are overridden by the styles from NavFrame.
We could easily move most of the styles applied by Nav* to a separate class, but there is one major issue. There are a lot of templates and pages which rely on using the current Nav* styles. All of these would have to updated beforehand.
No, I think the font/color stylings should be separated from the Nav frame classes. Personally, I don't like the center-aligned text or the awkard font sizing. It'd be smarter if the font stuff was all left out entriely. The .Nav* should apply nothing else to the content of the divs except for its show/hide feature and maybe some required positioning and padding/margin elements to the text.
In fact, this batch of presentation classes should probably be renamed from "Nav*" to something like ".Collapse", and adapt the ".Nav*" classes strictly for Navbox text styling (and maybe some "float" box classes, for grouping purposes), into Monobook.css.
The many templates using this may have to be adjusted, but that can be accomplished with some patient editing/categorizing methods. Ultimately, we ought to encourage user application of styles without including additional styles into content presentation classes. —Down10TACO22:35, 8 January 2007 (UTC)
Thanks for pointing that out. There may be some gray areas in regards to that license, since someone could link to a pornographic PDF in theory (which is allowed by WP policy if it is relevant to the subject), but it should be acceptable in most cases. Mike Dillon22:25, 29 December 2006 (UTC)
I said "if it used Adobe's copyrighted icons, which it doesn't". We aren't using Adobe's icon; we are using a public domain icon created by Mark James. There are no issues with copyright. There are no issues with the icon's image description page not being linked to. There are no copyright issues with this icon and there never have been. — Omegatron03:20, 30 December 2006 (UTC)
I know I said "fair use", but I was actually thinking of trademark issues, not copyright issues. Regardless, I don't really care about this enough to start using bold text or arguing about it. Mike Dillon05:31, 30 December 2006 (UTC)
I would note that I kind of agree with Mike Dillon, in that I think the icons we're using are easily confusable with the Adobe icon everyone's familiar with and could constitute trademark infringement. But I don't care enough to argue either. —Simetrical (talk • contribs) 01:00, 10 January 2007 (UTC)
Trademark and copyright are not the same thing. Do you know that the use of logos in icons is trademark infringement, or is this just personal speculation? Wikimedia Commons is a lot less permissive about legal violations, and they host plenty of Adobe-derived icons. Same for pretty much any Linux distribution or other Free software that features a file browser. — Omegatron02:10, 10 January 2007 (UTC)
I'm not sure what it is you're trying to add, but you might want to try editing Monobook.css with a admin account. What version of MediaWiki are you using? You might also want to look at the setting of $wgSpamRegex. Mike Dillon01:07, 16 January 2007 (UTC)
Consistent styling for edit-page messages
{{editprotected}}
There's some inconsistency in edit-screen messages at the moment; it was suggested on MediaWiki talk:Talkpagetext that there should be a CSS class that can be used for consistent styling. I'd like the following to be added to common.css (originally taken from MediaWiki:Longpagewarning:
(It could be argued that this should go in monobook.css, as it's an interface message, but placing it in common.css is the least change to the current situation.) It would be nice if MediaWiki:Talkpagetext, MediaWiki:Longpagewarning, and MediaWiki:Newarticletext were all updated to use the new class (resulting in no visible changes to the first two, and only a slight change to the third), but I'll put up {{editprotected}} messages after the class is added if necessary. --ais523 09:16, 7 December 2006 (UTC)
standard-talk is for divs/tables placed at the top of a talk page. This is for divs/tables added by the software above the edit box when editing a page, and looks quite different. --ais523 14:56, 12 December 2006 (UTC)
highlights the reference that you clicked in the article. Put it in your style sheet and then start clicking on references to see how it works. I want to put it in the site-wide style sheet. — Omegatron22:26, 10 January 2007 (UTC)
Cool, I forgot to suggest this feature here after it to the Vietnamese Wikipedia a few months now (in yellow, but I like the shade of blue you used). I also bolded the [1] link that the user is taken to after clicking the ^ link in the footnotes. This way, the reader can easily find their place after reading the footnote. I'm open to suggestions on making the [1] link stand out more, though; bolding it doesn't do much for discoverability, since the link is so small. – Minh Nguyễn (talk, contribs) 09:50, 25 January 2007 (UTC)
Is there any reason not to change the background of tables to be transparent instead of white? The slight mismatch between the white and the monobook background have been bothering me for some time, and I have added it to my monobook.css file. I don't think it would cause any problem with other skins, since they all pretty much use a white background. Prodegotalk01:29, 15 January 2007 (UTC)
Yes. The reason is that, when the background is transparent, the horizontal line below headings is visible behind some tables, which is uglier than a slight colour mismatch. --cesarb16:11, 3 February 2007 (UTC)
Rules based on the namespace-based CSS classes such as ".ns-0" could be added to sync the table background colors across the various namespaces. I'm not sure if those classes are available in any skin except Monobook, so it would possibly be better to add them to MediaWiki:Monobook.css. On second thought, it is definitely better to add them there since the background colors are skin-specific. FYI, I just checked the CologneBlue skin and it also supports the .ns-# classes. Mike Dillon16:18, 3 February 2007 (UTC)
Well, how about setting the default background to #F8FCFF for monobook only, (and the other classes each with their own). That way the backgrounds will match. This could be added to Mediawiki:Monobook.css. Prodegotalk23:21, 6 February 2007 (UTC)
Yes, I think so. I know only a very little CSS, so you will need to bear with me here. I have one question, what does the "#content" before table do? I understand .ns-0 specifying for the main namespace's white background, but I do not understand the "content" part. But yes, that is what I mean. Prodegotalk04:37, 7 February 2007 (UTC)
It makes it apply to tables that are children of an element with id="content". I put it there because the rule that does the background for the content tab includes #content. Mike Dillon05:46, 7 February 2007 (UTC)
I see, you need that because it is part of the way the mainspace background is changed. It looks good. Now, can we do the same thing to diff backgrounds on non-mainspace pages? Currently they don't match either. Prodegotalk20:42, 7 February 2007 (UTC)
This rule actually has some issues. I have it in my personal monobook and it is changing the background of the tables that use .standard-talk blue on talk pages. I think the issue is that the #content selector increases the weight of this rule above the weight of the rule for the .standard-talk background. It might be possible to fix this by removing #content from the ancestor chain and adding "!important" to the .standard-talk rule. Mike Dillon02:59, 8 February 2007 (UTC)
I removed the #content and "*" selectors from the rules and it fixed the talk page issues. I still think this stuff needs to be thoroughly tested in somebody's personal monobook before going live. The main namespace table rule makes it so that a rule that only has one class selector will not work without "!important". This is because the ".ns-0 table" rule has a specificity of 11 and a single class rule like ".infobox" has a specificity of 10. A rule like "table.infobox" has a specificity of 11 and it then becomes an issue of ordering which one applies. We don't want to have to have ".ns-0" versions of all the CSS rules to make sure they work and scattering !important everywhere kind of sucks. Mike Dillon03:12, 8 February 2007 (UTC)
I know it has been discussed before. But it seems that nothing has changed. It is still 90% now. I personally prefer 85%, which will make references small in both IE and FF. My second choice is 92%+, which also render similarly in both browsers. But with 90%, it's inconsistent across the two major browsers. --ChoChoPK (球球PK) (talk | contrib) 11:45, 21 March 2007 (UTC)
I agree to some extent – though I should point out that small references are not the only thing that renders at a different size in IE and Firefox. So does the sidebar, the user links in the top-right corner, and the tabs ("edit this page" etc.) at the top of the page. All of these are specified at (I think) 90%, or at least some size that shows up differently in the two browsers (and differently again in Opera). So if this is going to be changed for that reason, so should everything else – Qxz00:38, 24 March 2007 (UTC)
Wikitable changes
I don't think the child selector was supported in Internet Explorer until version 7 (cf. Comparison of layout engines (CSS)#Selectors, which lists support for child selectors in the Trident rendering engine as a version 7.0 feature). Thus, I'm afraid that the recent change to use this rule will not work:
Can anyone confirm that this works in IE6? If not, it should probably be removed since a bad selector will cause the rule to be ignored. Also, I'm not sure that tbody is present in the DOM in all browsers. Mike Dillon02:33, 24 March 2007 (UTC)
Re: tbody, this page seems to confirm that it is there in IE. I know that Gecko-based browsers have it as well. I guess that part isn't an issue, but I think the child selector thing is. Mike Dillon02:35, 24 March 2007 (UTC)
IIRC, tbody is implicitly added only when using HTML, not when using XHTML. Since using XHTML is needed for using MathML, it would be a bad idea to depend on something that would not work on XHTML. --cesarb16:25, 24 March 2007 (UTC)
I really thought that all browsers, which supported css2 supported child selectors. it's a rather common type. →AzaToth14:19, 24 March 2007 (UTC)
I'm not sure there are any mainstream browsers that fully support CSS2. Even Firefox and other Gecko-based browsers, which are generally touted for their compliance, have a few areas that aren't supported. An example is @font-face, although it is possible that will be removed from CSS3. There is a table in the "General overview" section of the Comparison of layout engines (CSS) article that only shows full cross-browser support for CSS1. Mike Dillon15:26, 24 March 2007 (UTC)
If I don't hear any good justification, I will remove the checkerboard background style for transparent images (as visible here). I understand the usefulness for editors. The style is already the default on Commons, and most transparent images are user-uploaded ones which belong there. Here on Wikipedia, we should be more concerned about the readers, for whom these checkerboard patterns are nothing but a distraction when viewing images.--Eloquence*02:20, 17 February 2007 (UTC)
Wouldn't adding a history tab to the image namespace moving the file history to the history tab be more beneficial to readers? (As well as moving most metadata to the talk page, leaving only the image and a description which is relevant to readers on the image page?) —Ruud13:58, 17 February 2007 (UTC)
To further improve the description page's appearance for readers, I tried to change the images' background color from white to the pale shade of blue used for non-article pages. I did so by creating a 1px GIF image and attempting to tile it via the same code formerly used for the checkerboard background. This had no apparent effect, so I tried a 16x16 version. That didn't work either, so I tried a 1px PNG (a larger file than the GIF version, which is why I didn't use it in the first place). No luck.
If anyone can identify the problem (or knows of a better way to do this), please jump in. —David Levy07:52, 14 March 2007 (UTC)
That change to Monobook.css appears to pertain the "gallerybox" class (used for image galleries), so I'm confused as to how it affects the description pages. (Please bear with me.) Also, shouldn't that be set to #F9F9F9 (the shade of grey used for the galleries) instead of white? I assume that the similar code (in lieu of an image link) could be used here. —David Levy08:52, 14 March 2007 (UTC)
The comma separates different sets of selectors, so both gallerybox class image and the file page image will have the same CSS applied to them (for the selected element). The spaces represent child selector, so it only applies to <IMG> within an element using thumb and gallerybox classes. So you have to options: separate the first selector and give it the background: #F9F9F9 or remove it which will make it transparent. You probably should test your stuff with Web Developer Extension before implementing it. Lastly this change should not be implemented in commons.css as it affects all skins. —Dispenser06:57, 15 March 2007 (UTC)
Thanks again for your help! I implemented the background coloring in Monobook.css. Some of this may be moot, however, as Ed g2s has restored the checkerboard background. —David Levy 17:05/17:07/17:11, 15 March 2007 (UTC)
Hang on, since when did the chequered background become such a bad thing? There is no other way to convey transparency information (changing the background colour doesn't really help) and it's subtle enough not to distract from the content of the image. I think it is considerably more useful than it is distracting. The difference between white and transparent can convey information in a diagram. ed g2s • talk16:48, 15 March 2007 (UTC)
Could you please cite an example in which this effect helps to "convey information in a diagram"? I can't imagine why an image author would rely on such a feature (unavailable in articles and to users of incompatible browsers), and I'm afraid that I agree with Erik. The checkerboard is useful to editors (who can implement it in their personal CSS), but it distracts readers. —David Levy17:20, 15 March 2007 (UTC)
Any diagram which contains a white filled object - while one may be able to infer it from it's filled from context one can only see that when the background is changed. Can you give an example of where it distracts readers, it's only a very pale grey. ed g2s • talk18:08, 15 March 2007 (UTC)
I would argue that the checkerboard background serves as a distraction whenever a reader simply wishes to view the image's subject (here, for example). —David Levy19:18, 15 March 2007 (UTC)
A quick example (probably not the best) is Image:Warsztat.svg. With the transparency is possible to tell that the two large enclosed rectangles are empty, and the system is not mounted on a white wall. Also the small circle at the intersection of the sticks labelled 16 is made apparent to be a pin, and not a hole because it is filled white, the same with the joints labelled 8. As I mentioned, it is often possible to guess the difference between white and transparent, but it is not always the case, and this certainly makes it clearer. ed g2s • talk18:14, 15 March 2007 (UTC)
I see what you mean, but this advantage is nonexistent when viewing the image in an article (against a white background) or via an incompatible browser (such as IE6). Therefore, diagram creators should be discouraged from relying on this convention to convey information. It would make more sense to simply use a solid background and fill specific elements with different colors. —David Levy19:18, 15 March 2007 (UTC)
Transparency is not just about conveying information - it also makes images more reusable - i.e. compositing diagrams, overlaying onto new backgrounds etc. This benefits everyone, regardless of which browser they use. As long as we agree that transparency used correctly is a Good Thing, then we should be displaying it when we have it, and highlighting the images which use it incorrectly / don't use it at all. ed g2s • talk14:40, 28 March 2007 (UTC)
It also makes it clear when an image is broken (lacking transparency or using transparency when it should be filling white), something that all Wikipedians should be concerned about, not just Commoners. ed g2s • talk18:19, 15 March 2007 (UTC)
Actually, this is something that concerns editors (who can deliberately select compatible browsers and add the necessary code to their personal CSS). Other Wikipedia readers simply want to view the images. —David Levy19:18, 15 March 2007 (UTC)
Wikipedians = editors. Most editors/Wikipedians won't bother/know how to set their stylesheet, and the problems will go unnoticed. ed g2s • talk14:40, 28 March 2007 (UTC)
Consistent padding for "div.NavFrame" and "table.navbox"
Common.css currently has different padding values assigned to the two navigation box classes: div.NavFrame uses 2px and table.navbox uses 5px. This causes navbox templates to effectively have 5px more padding (3px from the CSS settings plus 2px from the use of tables). The difference in appearance can be seen at the bottom of pages such as Guadeloupe, Mayotte, Toronto and too many others to list here. I have included examples below which compare the navbox-based {{Navbox generic}} and NavFrame-based {{Navigation}} templates. Users of Internet Explorer 6 for Windows will see no differences in these examples, as CSS padding for tables seems to be ignored.
The first example shows navbox with the default padding:5px. This creates a large amount of padding between the border and the body of the table.
The second example shows navbox with padding:2px. Although this is also the default for NavFrame, the padding in navbox appears larger due to the table adding an additional 2px of "cellspacing" (HTML) or "border-spacing" (CSS).
Homogenizing the looks of the various navigational boxes is a good move. I'd personally prefer option 3 (or perhaps even a totally different look.) Some other tweaks would be to use the same font size and amount of padding between two boxes. I'll have a stab at rewriting the Javascript behind NavFrame to fix some minor bugs and integrate it better with my collapsible table code (so both the NavFrame and navbox boxes collapse when the total number is over some threshold.) —Ruud00:22, 17 March 2007 (UTC)
Unicode/IPA class doesn't work with IE7
I currently use both IE6 and IE7, and so discovered that all the special characters using Unicode or IPA classes are displayed correctly only on IE6.
Then I found out the comment "The inherit declaration resets the font for all browsers except MSIE6. The empty comment must remain." just before the class in Common.css (some info about the empty comments [11], with a test page for your browsers). I don't really understand why we should "reset" the font for all these browsers. For myself I created a customized stylesheet without the inherit line, and it works fine.
Forcing the use a a certain font is very evil, so we only want to do it on browsers that would otherwise mess up. The font declarations should probably be moves to the Internet Explorer bug-fix stylesheet or see if we can use IE's conditional comments so we can avoid exploiting a bug that only exists in IE6. —Ruud18:07, 29 March 2007 (UTC)
Since I don't have other browsers except IE, I can't tell how they react to Unicode symbols. Does they really show all the characters correctly (try IPA chart for English)? I know that some of the symbols need special fonts such as Doulos SIL, so how would a browser know to use that font without the CSS? —Yoshigev21:35, 29 March 2007 (UTC)
Firefox, Opera and Safari (unlike IE) just try each font on your system if the character isn't available in the default font. —Ruud00:16, 30 March 2007 (UTC)
I thought of another option: Embedded OpenType font. EOT fonts only work for IE, and they are downloaded automatically. I created a file for "Doulos SIL", and it weighted only 394 KB. In the CSS the lines should read something like:
I tried this a few months ago, but unfortunately for a significant portion of the users it causes a messagebox to appear on each page view asking them if they wish to download the font. —Ruud08:35, 30 March 2007 (UTC)
OK, nevermind. So it looks like there's no elegant solution. Do you think we should put an explanation somewhere (so it will be noticable) how to fix the problem with personal monobook.css? —Yoshigev11:17, 30 March 2007 (UTC)
I very much disagree with Ed2gs; the checkered background on transparent images is highly distracting for readers and makes some of our most aesthetic works look ugly and unappealing. Whenever a complex diagram (like in eye) is in an article, people will want to zoom in to see and understand details. Overlaying a checkered background that the original artist of the image never intended to be there is distracting and greatly affects the aesthetic quality of these images.
Ed has been the only person so far who has actually argued for keeping this for readers. I have removed it again; but if you feel this is an issue that needs a resolution, then we can have a poll on it. I strongly feel that this is something that should be on the level of editorial preferences, not a default we serve to all readers.--Eloquence*22:29, 31 March 2007 (UTC)
If an image isn't meant to have an transparent background, then the image shouldn't have a transparent background, I believe the checkered background brings more positive things than negative things, as you then quickly can see if an image by some freak accident has transparency even if they shouldn't. The eye image is fully incorrect where the whole image has a transparent channel. So let's bring the checkered background back! →AzaToth23:13, 31 March 2007 (UTC)
Why should the artist create a background, when their expectation is that the image will be used in the context of a wiki, which may have particular stylistic needs? They only want to create an image, not worry about the particular context in which it is used. Default transparency strikes me as a perfectly reasonable choice, and I see no compelling argument to bother our finest artists with unnecessary requests, or to distract our readers with unaesthetic patterns.--Eloquence*23:31, 31 March 2007 (UTC)
The only way I would consider this to be workable in the default skin is as an optional overlay which users can activate via JavaScript on image description pages, i.e. a "Show transparency" link.--Eloquence*23:33, 31 March 2007 (UTC)
If the original artist has chosen transparency for a reason, I can't believe their reason was to show it against a white background, thus show it as it doesn't have a transparency. →AzaToth23:53, 31 March 2007 (UTC)
Inkscape, which is probably the most commonly used vector graphics application around here, will treat all background as transparent by default. There is no conscious choice. Moreover, any such choice probably does not equate to "an ugly and distracting chessboard pattern".--Eloquence*01:23, 1 April 2007 (UTC)
Using transparency is a good thing: the image can be displayed on various coloured of textured backgrounds. However the fact hat we can does not imply we should. The checkered background is only of use to a small portion of the editors, which are only a small fraction of our users. Those who care about the transparency likely have the technical skills to add this to their personal stylesheet. —Ruud13:19, 1 April 2007 (UTC)
What do you think of at least change the background color of the image? Like this for example:
The majority of users would prefer a white background and it doesn't clearly indicate the presence of transparency to the rest. —Ruud13:43, 1 April 2007 (UTC)
The checkered background is used because it is the standard way of showing transparency, using a solid color will result in any image that uses that color being subjected to low or no contrast to the background. HighInBC(Need help? Ask me)15:37, 1 April 2007 (UTC)
It is the standard way of showing transparency in image editing applications. The display of the checkered background is akin to viewing an image in "edit mode". As you say, it allows the illustrator to preview what effect an image might have when put in front of a background, without using any specific background color that might result in low contrast to the colors used in the image.
This, however, has nothing to do with what is best from a reader's perspective. For the viewer, the benefit of a tool that emphasizes background is completely lost. They are not interested in the background, or how useful the image might be in front of another one. They are interested in the content. Most illustrators on Wikipedia will design with white as the background color in mind. If we use white as the default, and allow editors to make transparency visible when they need it, we serve both groups. If we make the "edit mode" the default view, we risk to lose the audience for whom we created the images in the first place, and force illustrators to add artificial and arbitrary background images where none are needed.
If you disagree, can you show me a single scientific or educational publication, anywhere, that shows images with a checkered background? If there is none, then why should Wikipedia be the first?--Eloquence*01:00, 2 April 2007 (UTC)
"Why should the artist create a background, when their expectation is that the image will be used in the context of a wiki" - our content is not just for use in a wiki - it is supposed to be reusable. The use in the wiki (as in articles) does provide a white background. I have also yet to see an image where the extremely pale background has made it difficult to view. ed g2s • talk01:29, 2 April 2007 (UTC)
Could you guys stop wheel warring and figure this out before making any more changes? It would probably make sense to discuss this somewhere other than this talk page (e.g. WP:VPR). People keep claiming things like "best for readers", "best for editors", or "majority of users", but this is a very limited discussion and I've seen no references to discussions taking place with a broader audience. Mike Dillon01:57, 2 April 2007 (UTC)
That seems like a good idea. I did object to a feature which has been around for (what seems like) a long time, being removed after very little discussion. ed g2s • talk02:04, 2 April 2007 (UTC)
.geo is used for a microformat; .longitude/.latitude are regular classes to replace inline styles, and the names are also special for the Geo microformat. The .geo-* classes are defined such as they are, in coordination with Template:Coor link, so that a user can override via monobook.css/etc whether geographic coordinates are displayed in DMS, decimal, both, or original source version (the default); see the comments in the CSS or Template:Coord for details.
If there are any issues please change or revert as needed. {{Coord}} isn't widely used at the moment so it would be safe to revert the changes, but once it permanently replaces {{Coor dms}} et al it will take more thought before changing it. —Quarl(talk) 2007-04-04 13:45Z
"the names [geo, latitude and longitude] are also special for the Geo microformat" For "special", read "required". It might be worth including a note to that effect, as a CSS comment. Andy Mabbett20:41, 4 April 2007 (UTC)
I think we should use CSS so that some boxes, such as TOCs, "pseudo-category" type boxes like the lists at the foot of Birmingham,and perhaps infoboxes, don't print. Guidance could be given on how to override this, for those who must waste trees. Or at least we should provide tools to make individual boxes not print. Thoughts? Andy Mabbett13:07, 4 April 2007 (UTC)
For writers: Adding noprint class should make any box non-printable, as far as I understand: see commonPrint.css; also similar rule (I'm not sure why) can be found in MediaWiki:Monobook.css.
For readers: custom CSS rules for monobook.css can be developed (and then posted at Wikipedia:WikiProject_CSS).
P.S. You can just hide TOC table before printing and then I think it will not be printed (except for the word «Contents».
Why do we need a poll on this? It won't effect anything substantial at all, and the people lamenting that it looks ugly can (as they so kindly pointed out) easily override it. Why waste the community's valuable time with a poll over such a completely trivial issue? --tjstrftalk15:38, 5 April 2007 (UTC)
Yes, of course. However, that doesn't answer my question. Why are we having a bureaucratic poll over something completely insignificant? --tjstrftalk20:58, 5 April 2007 (UTC)
Because "we" would like to determine what the general opinion on removing or keeping the checkered background is. Those who are in favour of it or against it can voice their opinion, whose who think it is insignificant can ignore the poll. It's an efficient way of consensus building and in no way bureaucratic. —Ruud00:57, 6 April 2007 (UTC)
I'm not sure how that's different, in effect, from what I proposed. Incidentally, further experimentation shows that it's better with the solid border on the right, excluding last-child (as opposed to being on the left and excluding first-child). This looks better when the list wraps over two or more lines. Andy Mabbett13:53, 30 March 2007 (UTC)
Wait, it doesn't work on IE6. I'm testing now. --ais523 13:55, 30 March 2007 (UTC)
I no longer have IE6 here, but, from memory, it doesn't "fail" so much as "fall back", which is what CSS is designed to do. Can you describe (or screen-cap) what you're seeing, please? What page are you testing it on? Andy Mabbett14:07, 30 March 2007 (UTC)
The selector given is wrong; instead of ul.horizontal, .horizontal ul is what's needed, or it makes no visible change to the page at all. (I think the selector given is wrong for all browsers.) With that corrected, the borders are placed asymmetrically between the words, looking ugly (in both the first-child and last-child versions). Also, the :first-child selector is ignored, meaning an extra vertical bar at the start. (The CSS fallback would cause the horizontal list to become vertical in non-CSS browsers, which is also probably a bad idea.) I'm testing on User:ais523/Sandbox. --ais523 14:11, 30 March 2007 (UTC)
I refer the hon. gent. to the code I gave in my original comment (linked above). As to the placing of borders is that a browser issue, or a quantitative-values issue for the CSS? As for first/ last child selector being ignored, if you will use a broken, superseded browser... (but switching to last-child should help remedy that). I fail to see why correct non-CSS fall-back is a bad idea; the alternative would seem to be to misappropriate HTML markup to achieve presentational effects - like using blockquote for indentation or tables for layout. Andy Mabbett14:17, 30 March 2007 (UTC)
My point was that for long horizontal lists (which don't take up much space), the fallback is a long vertical list (which could be several pages long in some cases), rather than an unformatted list of words stretching horizontally. Another way to put it might be: the <li> tag was originally intended for block-level markup (to me it carries a connotation of 'list' as in each list item is on a separate line, and whether they're bulleted or numbered or whatever is less important), and the fictitious 'horizontal list' tag would be inline. I'm not sure to what extent this acts against the 'li means list, and a horizontal list is a list' argument, which seems reasonable. --ais523 16:29, 30 March 2007 (UTC)
Outdent1
Try
.horizontal li
{
padding-left: 0.4em;
padding-right: 0.6em;
The problem with the fallback for really old browsers would be the huge page-heightening that a long horizontal list could achieve. And I don't have much choice in browser; the only browsers installed on this computer are IE6 and an ancient version of Mozilla that can't even cope with the Monobook skin (it falls back to a Myskin variant), and I don't have admin rights on this computer so I can't install any others. If I remember correctly, IE6 is one of the browsers that Wikipedia still attempts to display correctly on (although I'm well aware quite how difficult this can be...) --ais523 14:46, 30 March 2007 (UTC)
(By the way, I appreciate the reasoning behind wanting to use logical markup when possible; but this rule is broken a lot (for instance, we're both using <dd>, which is what the : character produces, for indentation in this thread).) --ais523 14:48, 30 March 2007 (UTC)
I think people who use "really old" browsers will be used to things looking less than beautiful, anyway. I take your point about ie6 (it;'s still widely used) but there have to be some compromises when dealing with something so broken, and the fine- positioning of a separator probably comes under than heading. Your piont about abused HTML is also well made, but no reason not to try to do better. Andy Mabbett14:57, 30 March 2007 (UTC)
Note: I haven't worked with CSS style sheets in some time, mostly inline stuff. I just wanted to get the ball rolling with a request edit :) GracenotesT § 14:33, 30 March 2007 (UTC)
If I remember correctly, display: inline works for list items in IE6, and maybe even IE5. Can anyone confirm/disconfirm that? It should also be pointed out that the semantic information of list-ness is actually used in nonstandard browsers; browsers with limited simultaneous output, such as screen readers and small-screen browsers, may "compress" lists by default and allow the user an option to expand them if he really wants to see all 57 counties of Finland or whatever instead of wanting to scroll to the navigation stuff at the bottom. I know Opera Mobile (or Mini or whatever), at least, does this, and inline lists are conspicuously long. So this isn't some academic "purity" issue. —Simetrical (talk • contribs) 22:45, 30 March 2007 (UTC)
display: inline definitely works in IE6. --ais523 14:41, 31 March 2007 (UTC)
Good question! I have seen absolutely no dissent, here or on any of the other pages where I raised the matter; only discussion of minor tweaking for aesthetic reasons (note that some of the CSS in my example code (line height, font-size) was for such purposes on my site, and might not be needed here). Can we perhaps get something uploaded, even if only on a trial basis? Note also an additional use-case; templates such as Template:West Midlands railway stations. Also, "flat" may be better name than "horizontal", not least for ease of typing by users implemetning such lists. Andy Mabbett15:23, 31 March 2007 (UTC)
This seems reasonable, as long as the code with .horizontal ul li (which works on IE6) also works on standards-compliant browsers. I won't make the change myself, partly because I don't know whether the IE6 selector is the same as the 'correct' one, and partly because I'm too involved in this discussion. --ais523 15:27, 31 March 2007 (UTC)
No shrubbery is necessary. I am willing to make the change, but I want to make sure that there is consensus, and that all the possible issues have been addressed. Since this CSS file affects every user on the site, it is particularly important to be careful in vetting proposed changes.
I use FF2, ie7 and Opera 9.1. It works fine in all three (in Opera, there are no "separator" borders, but its still perfect readable and wraps and enlarges without problems). It's fine on Opera's "narrow" mobile device emulator. It degrades gracefully in all three, with CSS disabled, and in 'OffByOne' a basic browser with no CSS capability. Andy Mabbett05:52, 1 April 2007 (UTC)
Thanks. I changed the other occurance of border-left to border-right as well. That makes the following. Would someone double-check that this works? Also, can I change the bare 0 to 0em in four places? CMummert · talk21:49, 1 April 2007 (UTC)
It would work much better if the border were 1px instead of 0.1ex, probably. 0.1ex is typically less than a pixel, so Opera doesn't display it at all, and IE apparently gets confused too. Compare:
Foo
Bar
Baz
to
Foo
Bar
Baz
There's definitely such a thing as too much purism, and specifying borders in exes will typically fall in that category. Also, you want to remove the right padding, not the left, on the last child. And the "horizontal" rule is clearly wrong and needs to be ".horizontal" (it's valid CSS but will never apply to valid [X]HTML documents). While I'm at it, may as well clean up the rules a bit altogether. Like so:
<!-- Style for horizontal UL lists -->
.horizontal ul {
padding: 0;
margin: 0;
}
.horizontal li {
padding: 0 0.6em 0 0.4em;
display: inline;
border-right: 1px solid;
}
.horizontal li:last-child {
border-right: none;
padding-right: 0;
}
Pigsonthewing suggested I report a problem here about pages using this when viewed with IE6. I noticed it first on the Warwickshire page where a list was changed. The vertical bar is splitting multi word items when the item is wrapped over lines.
Thus '| Joe Simith |' when wrapped onto 2 lines comes out as -
| Joe |
Smith |
that is with the extra unwanted bar at the end of the first line.
Well, we can either get rid of the borders, or allow IE 6 to be broken in this minor way. Either option seems OK to me. CMummert · talk10:58, 5 April 2007 (UTC)
I'd prefer to keep the borders; they're an important visual clue for readers, and I can see editors objecting to replacing lists marked up with pipes or hyphens, or whatever, with this version and no border. ie6 is broken in several major ways ;-), so this minor bug might be acceptable. What do others think? Do we have a feel for how many people are still using ie6? Or a policy on how much we disadvantage people with better browsers (be they alternatives, or ie7), in order to accommodate it? Andy Mabbett11:26, 5 April 2007 (UTC)
The figure on my reasonably active site is around 25%+ using IE6, a plurality. The best way to go for compatibility is undoubtedly to ditch the borders and hardcode the separators in, like
This also avoids people wanting to use other kinds of separators, and it avoids last-child issues that will result in a separator after the last item in even IE7 (which apparently only supports first-child). Eventually we'll be able to use generated content, but for now it's hopeless, you need to have the separators added manually. Still far better than the present situation. Of course, if the borders are removed, so too should the padding be (the padding will consist of spaces). So really it would best be
<!-- Style for horizontal UL lists -->
.horizontal ul {
padding: 0;
margin: 0;
}
.horizontal li {
padding: 0;
margin: 0;
display: inline;
}
I hadn't tried the code. I'd like to think that I was familiar enough with CSS not to need to test a five-line rule. But here you go:
Item 1 |
Item 2 |
Item 3
As for "awful", well, no kidding, but sadly we don't live in an ideal world where every browser supports fully semantic markup, so we have to make do with half-measures. If you want people to use your lovely semantic lists, which as I have said is a worthy goal for entirely pragmatic reasons, you have to ensure that they look the same as the old lists people are using, or else people who dislike the appearance will resist the change and revert you. And they'll probably outnumber you, as well. That's life on Wikipedia, where not everyone is a semantic-HTML idealist. —Simetrical (talk • contribs) 19:18, 6 April 2007 (UTC)
Would the problem be solved by adding "nowrap" (or whatever the correct style is) to '.horizontal li'? It would probably also improve general readability. Andy Mabbett09:39, 8 April 2007 (UTC)
We'll need soeone with IE6 to test it to see whether IE6 respects the CSS. In general, this would improve the appearance of the lists. CMummert · talk11:38, 8 April 2007 (UTC)
This is a list consisting of a few elements each with lots of words, so I can see how this looks in IE6.
This is a list consisting of a few elements each with lots of words, so I can see how this looks in IE6.
This is a list consisting of a few elements each with lots of words, so I can see how this looks in IE6.
According to the CSS as of this timestamp (without the nowrap), it seems that the separators are fine, but the second line is vanishing off the left border of the page; its first character and a half have ended up stuck behind the sidebar. --ais523 14:32, 8 April 2007 (UTC)
Seeing how this works in a TOC (yes, it does work in a TOC!), it seems that IE6 is adding left-borders to the first word wrapped onto a new line, too. --ais523 17:07, 8 April 2007 (UTC)
nowrap would make this unusable for long list items and small screens. It will also potentially create a lot of ugly whitespace. It's a bad idea for that reason, and besides, you haven't gotten around the :last-child issue (IE6 doesn't support that, and nor does IE7, although the latter does support :first-child). This solution is going to be broken in IE, and nobody is going to adopt because they like their separators better, whatever you do. The separators shouldn't be coded into the template. Or if you really want them to be, it occurs to me that background-image might do the trick better. I can't give a demo here, because background-image is blocked, but the code would be
The effect can be seen here. Note that it doesn't work well with wrapping on IE7 (probably IE6 too). A bullet will also be displayed before the first item in IE6, I believe. I continue to strongly feel that separators be written in the list itself for maximum flexibility, acceptance, and compatibility. —Simetrical (talk • contribs) 03:17, 12 April 2007 (UTC)
Poll on transparency issue
Should a checkerboard pattern be used to indicate image transparency on all image description pages?
There has been some back and forth on whether image description pages should show a checkered background image (repeated over the dimensions of the picture) by default to indicate transparency (the alpha channel of the image). A poll will begin here on April 10, 2007 or later, once there is consensus on the arguments and options. The arguments are as follows:
Arguments in favor
It helps to indicate the presence of transparency and therefore makes it easy to see on which backgrounds the image can be used.
All the arguments against are on the basis that the pattern is distracting, however the pattern is so light and subtle it doesn't actually distract from the image.
It highlights errors in an image, such as the incorrect use of transparency, or missing transparency. Typical errors include the use of transparency to make images "lighter", rather than the use of lighter colors.
Most editors won't know how to / be bothered to add it to their own stylesheet, meaning these errors will often go unnoticed.
Transparency can often convey important information in an image, such as the difference between a hole, filled disc.
If the information is important, it should not depend on the presence of a checkerboard pattern in the background.--Eloquence*14:30, 2 April 2007 (UTC)
Wikipedia targets readers before editors. Readers and viewers will be distracted by an unexpected chessboard pattern showing up when they zoom into illustrations. The repeating, alternating pattern is unaesthetic and almost certainly not intended by the illustrator to show up in any published version of the image.
Readers may also want to know if an image has transparency if they are intending to reuse the image. Apart from disagreeing with your opinion that the pattern is unaesthetic, I also question your assertion that no illustrator would create an image for which they expected the transparency to be made apparent by such a technique. I also question the suggestion that the Image: page should be consisdered the "published version" of the image. I doubt any Wikireaders would include the Image: namespace. ed g2s • talk15:58, 2 April 2007 (UTC)
Of course there's not going to be a consensus about what is or isn't unaesthetic. Some people might love to have little ponies in the background of each image. However, the point here is that we as Wikipedia are making a particular choice what to show in the background of images that someone else created, a choice that affects both the aesthetics and the usefulness of the image. We are making that choice, as has become very clear, to aid editors.--Eloquence*00:48, 3 April 2007 (UTC)
Is agree with ed_g2s, the pattern is not shown in articles to the public, is is only shown on image description pages for editors who intend to use the image in articles or want to re-use them. They definitely need to know about transparency, and aesthetic questions are of less importance there. Cacycle16:41, 2 April 2007 (UTC)
Uh, what? Both the "zoom" link and the main link around the image take a reader to the image page. That is the page that includes the full size view of the image, which is intended as much for readers as for editors to see details of the image that are lost in the thumbnail. The thumbnail is only a preview; the image page is the full view. And that is where the transparency pattern is shown. The argument that this is not a "published" use is very divorced from reality; this website is where most readers will be exposed to these images, and it includes the chessboard pattern.--Eloquence*00:10, 3 April 2007 (UTC)
I strongly doubt that a typical reader ever intentionally visits the image description page (other than for inadequately scaled images in articles, which should be fixed in the articles). Cacycle20:26, 12 April 2007 (UTC)
Editors who need this pattern can add it to Special:Mypage/Common.css with relative ease. It may also be possible to implement a JavaScript which activates the overlay with a click, though this does not currently exist.
Surely, a regular editor can be expected to edit a wiki page and copy and paste something in. Surely we would not have the same expectations from a reader.--Eloquence*00:49, 3 April 2007 (UTC)
Further, the option to show a checkerboard pattern on description pages only could be added in Preferences, under Files, and turned off by default - if a user prefers checkered transparency, they will be able to turn it on. —The preceding unsigned comment was added by Vanderdecken (talk • contribs) 14:17, 2 April 2007 (UTC).
No professional print or online publication would publish its highest quality illustrations on a chessboard pattern. If the argument is that artists should make a choice to use a particular background color, it is a very weak one, as common vector drawing applications use transparency in the background by default; there is no compelling reason why we should annoy our artists with unnecessary requests to add background imagery just to avoid the implicit activation of an undocumented "feature" that will distort their work once it is uploaded to Wikipedia.
We also do not publish the images in articles or in full screen view with a chessboard pattern. The pattern is only shown on image description pages as part of the image description. Cacycle16:41, 2 April 2007 (UTC)
Image description pages are the primary view targeting readers. Full screen view is the third step of viewing, and for SVGs, it will not even work in Internet Explorer.--Eloquence*00:10, 3 April 2007 (UTC)
Thumbnails are the primary view. If an image is unclear at default thumbnail size, it should be embedded at a larger size. This is done out of consideration that most users won't want to navigate away from a page while reading, and that other mediums may not publish the full Image: page. ed g2s • talk11:12, 4 April 2007 (UTC)
If they choose transparent when they meant white, it will get fixed, the Wiki way. If we don't have the background the images will often remain broken. ed g2s • talk15:58, 2 April 2007 (UTC)
The place to work on images is Wikimedia Commons; there, a default pattern may be appropriate. Wikipedia is an encyclopedia, not an image repository, and our focus should be knowledge and education.
Nevertheless, images on Wikipedia are subject to improvements, updates, and use in articles. For this you need to know about transparency. Cacycle
If they are freely licensed, they should be on Commons. If they are fair use, it is unlikely that there is going to be significant use of transparency. In other words, in almost all update scenarios, the edit is going to have to click to Commons anyway to upload the newer version. They might as well click to Commons to find out whether the image is transparent.--Eloquence*00:51, 3 April 2007 (UTC)
En has many more frequent users than Commons, and most images views do not result in a commons image view, so we are loosing a large set of eyes checking over images. ed g2s • talk11:12, 4 April 2007 (UTC)
Casual readers will not bother to raise their voice over images with transparency issues. —Ruud17:52, 6 April 2007 (UTC)
Poll options (not open to voting yet)
Remove chessboard pattern from default skin
Keep chessboard pattern in default skin
Other
"It may also be possible to implement a JavaScript which activates the overlay with a click, though this does not currently exist." seems like a very interesting compromise if there is a consensus against using it by default. ed g2s • talk14:19, 2 April 2007 (UTC)
If you're worried about the time it takes the load the script, the script should be cached by your browser. If your worried about execution time, this script won't do anything until you click the "show transparency" button or whatever it is. ed g2s • talk15:43, 2 April 2007 (UTC)
Wikipedia's loading time is mainly due to slow servers. A couple hundred KB of CSS and JavaScript that's heavily cached anyway is not the issue. —Simetrical (talk • contribs) 17:03, 2 April 2007 (UTC)
I think whatever is decided here (keep/remove background), there should definitely be a javascript button to switch to the other mode and possibly a preference setting - although would take longer to get implemented. ed g2s • talk19:50, 2 April 2007 (UTC)
Legend
I am strongly for keeping the checkered background on image description pages. Transparency is an important feature for editors that want to use the image on pages with non-white backgrounds and for editors who want to improve or update an image. The checkered pattern is the standard method to indicate this in a wide range of image processing programs. However, in order to not confuse anybody and to see the actual appearance in an article, I suggest to add a small legend below the images:
Transparency indicated by , click here for a white background
The link would use inline-javascript to change the background style or would reload the page with a white background if JavaScript is turned off. Cacycle17:02, 2 April 2007 (UTC)
It's most likely that you haven't refreshed your browser cache. Here's the notice about that, pasted from .js pages:
Note: After saving, you have to bypass your browser's cache to see the changes. Firefox/Mozilla/Safari: hold down Shift while clicking Reload (or press Ctrl-Shift-R), Internet Explorer: press Ctrl-F5, Opera/Konqueror: press F5.
Hello, smart people. I brought this up at Wikipedia:Village pump (technical) week before last (April 1); it was suggested that I ask here...
After viewing this page: List of musical instruments by Hornbostel-Sachs number, I wondered if there was way to make the automatic table of contents render differently. I'm envisioning a TOC that would still compile automatically, but would render the headings with no outline numbers, ie:
Thing
Sub-thing
instead of
1 Thing
1.1 Sub-thing
This would be useful in the article in question, and possibly others, because the article itself is a demonstration of a numerical typology or classification system, analagous to the Dewey Decimal system or the DSM-IV; thus it makes some sense to include the H-S system's own numerical designations in the headings, but in the default TOC this combines with the automatically generated outline #'s to render as numerical gibberish.
The consensus seemed to be that this is not possible, however User:Splarka made the following suggestion, which I'm cutting and pasting here since I really don't understand the syntax involved:
You could request at MediaWiki_talk:Common.css an un-numbered class for wrapping your TOC in, such as:
///(or a variation thereof). Which could be placed with <div class="nonumtoc">__TOC__</div>. Note that you'd have to be rather convincing to get it ^_^.
It seems to me this would be analagous to the currently available alphanumeric TOC's, and could possibly be useful in more than just the one article. Is it doable in technical and policy terms? Thanks much, —Turangalila (talk) 16:45, 10 April 2007 (UTC)
It would be feasible from both perspectives. Note that that markup would place a square before each list item; list-style: none; would probably be better. —Simetrical (talk • contribs) 03:21, 12 April 2007 (UTC)
Ok, your version sounds better...how do I go about making it happen? Do I just ask again here or somewhere else? (please bear with me–I'm still kinda new here and I hadn't even heard of .css until this month.) —Turangalilatalk07:20, 12 April 2007 (UTC)
I've added the class to Common.css. However, when it is used, the indenting disappears (as if the headings were all the same level). If someone can come up with a fix for that... Harryboyles07:25, 13 April 2007 (UTC)
I've added language pseudo-classes for languages using Nastaliq, for CJK disambiguation, and for grc ({{polytonic}}). In theory, this should yield distinguishably Chinese vs. Japanese vs. Korean rendering for the example table at Han_unification#Check_your_browser if any of the fonts named are installed.
Sometimes, it's desired to remove very-low-level section headings from the TOC. (This could be useful in some project pages with low-level subheadings used for edit-section purposes; there are probably list-like articles that would benefit (e.g. ones which have a long list of sections each corresponding to a different country, and this sort of thing would also allow section headers to be used at RfA without noinclude tricks). The code to do this would be
(I have tested this in my own userspace, and it validates according to W3C); it would allow
<div class="toclimit-3">__TOC__</div>
to remove any headings below level 3 (assuming level 1 headings aren't used, which they shouldn't be on most pages), etc. Does anyone object to me making this change? --ais523 14:02, 18 April 2007 (UTC)
I've made the change. --ais523 16:13, 18 April 2007 (UTC)
I would appreciate the following addition to this page:
div.poem {
margin-left:2em;
}
This would make all <poem>s indented,
like this.
This way,
:Line 1
:Line 2
:Line 3
can be replaced with
<poem>
Line 1
Line 2
Line 3
</poem>
with no differences. Perhaps white-space: pre; should also be added, since poems often manipulate whitespace. (Any other suggestions or corrections would be good.) GracenotesT § 19:19, 15 May 2007 (UTC)
I'm not convinced this is a good idea; it's possible that some poems are indented at the moment through near-necessity, not for stylistic reasons. Wouldn't
<div style="margin-left:2em;">
<poem>
Line 1
Line 2
Line 3
</poem>
</div>
make a better replacement, not involving any changes to common.css? That way, the poem could be styled as required in the actual article (such as preing the whitespace). --ais523 12:41, 16 May 2007 (UTC)
I've disabled the editprotected request while discussion continues. Please re-enable it once there's consensus. Cheers. --MZMcBride20:24, 16 May 2007 (UTC)
Blockquotes may work, but there's still the white space issue. Taking cascading into account, its notable elements of style are "line-height: inherit; margin:0.4em 0pt 0.5em; font-size:93.75%;". If a class (called, for example, blockpoem) had the style "margin-left: 2em; font-size:93.75%; white-space: pre;" the following would work:
I meant that blockquote should be used regardless of formatting since a poem is, semantically, a blockquote. Right? — Omegatron14:09, 17 May 2007 (UTC)
The ideal way to fix that would be to alter the poem extension, an easy task in theory. But then there's the whitespace, and simplicity. GracenotesT § 14:29, 17 May 2007 (UTC)
Scroll bars for pre tags
I originally asked this in 2004, and it was never implemented. I don't remember why.
We should add something like this:
div#bodyContent > pre {
overflow: auto;
width: auto;
}
To the CSS so that code examples and the like don't extend beyond the edge of the layout. Each long section gets its own scroll bar so you can continue to read the article text while looking at the code. This is the standard way of doing it in Linux help forums and the like. Maybe this, too:
would come out as a list instead in CSS-compliant browsers like Firefox. (It has no effect at all in IE 6, so it degrades gracefully.) Would anyone object to this being added to the site-wide CSS (it's a bit of a niche thing; I'm using the transclusion to put lists of past AfDs on renominated AfDs, to make them easier to track, but it can be a bit ugly (see User:ais523/Sandbox), and the same could be done for RfAs)? Putting {{editprotected}} up because this needs a second opinion, even though I'm an admin. --ais523 15:04, 17 May 2007 (UTC)
Personally, I don't have any objections, but I do have a few thoughts. Because it won't be compatible in IE6 (and most likely other browsers), I'm wondering if it would be better just to fix the problem on your end using a Greasemoneky script or something similar (if that's possible). That way, the CSS wouldn't have to be changed for such a small task. Thoughts? --MZMcBride19:47, 17 May 2007 (UTC)
The information would be visible to everyone, so the fix would need to be made for everyone. (I can, and have, fixed it to my own view by using Special:Mypage/monobook.css.) It's not unusable without the fix, or with the fix degrading, but it would improve the view for standard-compliant browsers. (I'm only using the coding on AfD at the moment, but hope to place it on RfA as well eventually. It would probably be an improvement even without the fix, but having two page names side-by-side, each with one word wrapped, looks quite silly.) --ais523 14:03, 18 May 2007 (UTC)
I know it doesn't work in IE (and probably has no hope of working), so I just made sure it degraded gracefully. It doesn't work in IE, but doesn't bork pages either. --ais523 10:53, 23 May 2007 (UTC)
Now that redirects in categories are marked with that class. I would personally prefer a more conspicuous style alteration than mere italics, but that's just me (and I can customize it, anyway!). GracenotesT § 19:15, 17 May 2007 (UTC)
In order to offer a template that would allow user-defined preference regardgin the style of display of IEC/traditional notation
Could the following be included ?
The rational is detailed at Wikipedia talk:Manual of Style (dates and numbers)#Template with CSS proposition
This will allow the use of Template:KiB for instance, that in turn would be a way to avoid editor's argument regarding which style to use.
the default style is compliant with the current WP:MOSNUM, but most importantly, one can easily chose a 'pure' IEC style or a 'pure' traditional style without having to mass edit.
Another benefit is that, if and when IEC notation become in widespread use, we can change the default style in this central location. - Shmget17:12, 25 May 2007 (UTC)
This will cause the articles to have lost information if they are read without our CSS (e.g. on a mirror). I don't think this will work. An alternative would be to use a span with a CSS class around the abbreviation itself and let users use their personal JavaScript to switch out the text for themselves. This wouldn't require any site-wide styling or scripting, but it would also not avoid style arguments. Mike Dillon18:14, 25 May 2007 (UTC)
I see. Yep that is a problem. Can you point me to an example of the solution you suggest (I'm not asking you to code it for me, just a place where similar technique are used so I can study and adapt them). I do beleive that if there is a user-level custom solution that would render void most of the dispute. Shmget18:42, 25 May 2007 (UTC)
I not sure I understand the argument that a change shouldn't be made because it will cause mirrors not to work. Every style used in Common.css (obviously) won't apply to other sites that don't load the CSS, including things like "wikitable". Additionally, I'm not sure it's a good idea to base decisions on whether or not another site may copy this one. These comments aren't intended to attack or be rude, I'm just not sure I understand the logic in stopping a proposed change to appease other sites. Any thoughts? Cheers. --MZMcBride19:16, 25 May 2007 (UTC)
It's not just mirrors. There are plenty of tools (even some browsers, esp. text-based ones) that interpret HTML and do not honor CSS. For the most part, the users of those tools can expect that they will have different formatting, but that the text itself will read correctly. If CSS is used to add text, with the "content:" attribute, those assumptions no longer hold true, and the users of those tools will have problems. The conclusion, therefore, is that solutions that use "content:" are probably not a god idea to deploy. jhawkinson20:21, 25 May 2007 (UTC)
As jhawkinson, not all CSS poses this sort of problem. Only CSS that does things like hide or add content in ways that the display will be actually broken if they don't happen. If something doesn't use "content" or is missing the rule, you end up with an unqualified number instead of a value with units. Mike Dillon21:29, 25 May 2007 (UTC)
Well, the approach I'm suggesting would do the following:
Make a template like {{KiB}}, but have the content be:
{{{1}}} <span class="kib">{{{2|KB (KiB)}}}</span>
Call it like so: {{KiB|1234}} or {{KiB|1234|KB}}, which would display as "1234 KB (KiB)"" or "1234 KB" respectively
In the JavaScript, use getElementsByClassName(document, "span", "kib") to find the spans containing the units
Use JavaScript to replace the inner text of the span with whatever the user wants to see
Let me know if you have any questions. I don't mind writing up the code if people want to use this approach. Mike Dillon21:37, 25 May 2007 (UTC)
You solution achieve what I have in mind : a centralize way so that the notation could reflect the style consensus, including change in that consensus if that occurs, and still the freedom to individual reader, editor, not to be force to abide with that consensus without creating endless warring.
I have changed the Template according to your suggestion. I will try my luck with javascript (I tend to be allergic to java, but I'll try to get over it :-) ), you are most welcome to beat me to if if you are so inclined. I don't know if this method will be accepted and therefore used by 'people', but it would be easier to make a case with a working prototype... - Shmget22:43, 25 May 2007 (UTC)
Actually, User:Mike Dillon, your solution is even better that what I had in mind, since it would also allow to stick to the consensus of the existing page - as per current WP:MOSNUM - by specifying explicitely a parameter 2, while still clarifying that KB are 'binary' in the 'source' (the page would show {{MiB|16|MB}} - which make it clear that the editor know that they are binary) and allow any user to switch to pure IEC if they feel so inclined (and recriprocally allowing any user to switch to full traditional if he is allergic the IEC notation) and finally for editor that don't care, they can delegate the presentation to the WP:MOSNUM whose recommanded notation of the time would be reflected in the template's default. I really don't see any downside to this - Shmget23:04, 25 May 2007 (UTC)
I'd actually say that the template should conform the consensus if the second parameter is not passed. It isn't actually clear to me what the consensus is, but the templates should be set up in such a way that following consensus is the default option. Mike Dillon01:16, 26 May 2007 (UTC)
I agree. I tried to write the template based on what I understand being the 'current consensus', even though that is being debated... I would gladly change the template to reflect what-ever consensus emerge. The point of the template being to allow qualified exception (by over-riding the default an editor make a conscious choice, that should probably not be reverted too lightly) and by allowing user with very strong opinion on the matter to have it their way without engaging in edit-war. Shmget02:00, 28 May 2007 (UTC)
Thanks a lot. I haven't tried it with other skins yet, but I don't wee why it would make any difference (unless they actually already use 'kib/mib/gib/tib' as class of span.
I agree that the template should agree with the consensus if the second parameter is not passed, which I believe they do. But WP:MOSNUM also say right now, that on established page, one should stick with the consensus of THAT page and not change style for the sake of changing style. Using the second parameter will allow page about legacy hardware, for instance - to keep their default consensual style, while making clear - in the source of the page - that the use of KB is no accident and that it is known to have it's usual binary meaning and also allow any given user to see it with it's favorite notation, without having to edit the page, using the script you wrote.
The only difference in behavior between skins would be the part used to find the relevant spans to change. In Monobook, it finds all spans inside the "bodyContent" node; in other skins, it finds all spans inside the whole document. I think the code should work correctly in both cases, unless one of the skins is using "kib", "mib", "gib", or "tib" as a class in the non-article portion of the page. Mike Dillon14:43, 27 May 2007 (UTC)
this is this part right?
var body = document.getElementById("bodyContent") || document;
I was wondering, is there an iterator for the 'components/modes' of a document ? a way to get the root node and then traverse the tree from there ? -- Shmget22:15, 27 May 2007 (UTC)
I'm not sure what you're asking exactly, but document is the root DOM node. The reason that code first tries to find the element with the "bodyContent" id is that that's the top-level element of user-controllable content in the default Monobook skin. In Monobook, it is pretty much guaranteed that "bodyContent" will only have HTML derived from the article text, so we can be assured that even if the interface itself used those classes, they would be ignored. In the case of other skins, we simply traverse all children of the root node, so we could end up seeing an element with "kib", "mib", "gib", or "tib" if the skin used them outside of the article content. I'm pretty sure that no skins actually use those classes, so it's pretty much a moot point. Mike Dillon01:42, 28 May 2007 (UTC)
Thanks for the precisions. I guess my question boil down to: How do you iterate the whole collection of sub-node without going to GetByxxxx(). Let's say, for the sake of the discussion that I want to create a function that count the number of instance of each class used in a document... -- Shmget02:00, 28 May 2007 (UTC)
The getElementsByClassName() function is provided by the Mediawiki software in the wikibits.js file. It relies on the getElementsByTagName() DOM function and filters the return value to be a JavaScript Array with only the nodes that have the right class name. If you wanted to do it yourself, you'd have to do a traversal starting from document using the childNodes property (which implements DOM HTMLCollection interface). All DOM Element nodes have a childNodes collection, but not DOM Text nodes, so you'd have to skip non-elements. If you don't want to recreate the wheel, you'd just use the .length property on the Array returned from getElementsByClassName(). If you have more questions, go ahead and ask on my talk page since this is getting a little off topic for this page. Mike Dillon02:32, 28 May 2007 (UTC)
IE .infobox.geography .mergedrow problem
{{editprotected}}
The .infobox.geography .mergedrow does not display correctly in IE when footnotes are included in the text. This is noticeable in Infobox U.S. state. It squishes the text together and the second "p" in population has the bottom cut off on my machine, others are worse (this may be a problem with mergedtoprow). See InfoboxUS states display problems.jpg for an example screenshot. The space between lines has to be slightly increased. Mr.Z-mantalk¢21:34, 26 May 2007 (UTC)
Anyone want to suggest a way to fix this? I was surprised to find that an infobox has custom CSS here, since it ought to be possible to style the infobox using CSS inside table code. CMummert · talk02:50, 28 May 2007 (UTC)
Well, there are css options such as line-height, that might work, and in a pinch we can just increase the padding, but that's a hack. From the screenshot it looks to me like a vertical alignment problem. But I don't have any access to IE so I couldn't test any changes to see whether they help. CMummert · talk12:19, 28 May 2007 (UTC)
I don't think it's common enough (from what I've seen) to warrant a separate class. The span tag works just fine. Cheers. --MZMcBride22:02, 31 May 2007 (UTC)
Can these be removed, please--at least for the "simple" stylesheet? I try to remove white backgrounds wherever possible, which is why I use the "simple" stylesheet in MediaWiki prefs (so the web browser-specified page background is used instead), but most MediaWiki tables tend to have annoying white backgrounds which are overbearing, glaring, and even painful to look at (considering most of my backgrounds are neutral grey). --Єερ²(τ|c)12:48, 20 May 2007 (UTC)
We'd have to do
table {
background-color: transparent;
}
(inherit would possible work; I'm not sure.)
this would override the first of following from main.css:
I've really wanted this for some time, and think it would be great if it were implemented :) Pretty sure it's been suggested before, if not here. GracenotesT § 18:14, 20 May 2007 (UTC)
Well, yes, but this is a mass inconvenience :) or at least a mass irritation. You would add the former code to this page (from what you've told me) to see transparent tables. GracenotesT § 19:09, 20 May 2007 (UTC)
Doesn't work. :( I may have to put the whole CSS file there and then just remove all the white backgrounds. ∞ΣɛÞ²(τ|c)21:00, 20 May 2007 (UTC)
You put in the wrong one :( try replacing what you have with:
I put in the one you said--the first one (well, you were vague--you just said "the former one", which isn't even the one you just mentioned now). Anyway, it still doesn't work. "Inherit" retains the same background; it doesn't do anything. Just to be sure you understand what I mean, I want the white backgrounds on tables (such as on WP:PARA to not be whitebut be the same default background color as my web browser (which is Firefox set to "use system colors", of which, in WinXP, is set so that the "window" item's "color 1" in Control Panel > Appearance > Advanced is set to RGB 128,130,140 (hex/HTML #80828c, a neutral blue-grey). Dig? ∞ΣɛÞ²(τ|c)22:47, 20 May 2007 (UTC)
I was previously somewhat confused about what you were asking, and now I'm stupefied. I thought you were talking about tables, since that issue has been brought up before, but I guess not... if you want a background color in tables of #80828c, your background-color should be set to #80828c in your user CSS style sheet. I still feel as though I'm out of the loop, so do you want a CSS change for everyone, or only for yourself? Are there any particular elements you want to alter? GracenotesT § 22:55, 20 May 2007 (UTC)
I am talking about tables. Anyway, I figured it out; I had to specify the correct table elements (see User:Eep²/simple.css). I still think it should be that way for everyone with the "simple" skin but this'll work for me at least. Thanks for your help. ∞ΣɛÞ²(τ|c)23:10, 20 May 2007 (UTC)
I think transparent or inherit should apply to everyone, just because default white backgrounds look unprofessional outside mainspace, and so I don't have to type {| style="background-color:transparent" for category or template namespace tables. If transparent is default as it seems to be, then just remove the line. –Pomte16:37, 3 June 2007 (UTC)
I.e., .small instead of .small-talk, and no color override of .messagebox's default near-white. If .small will conflict with something, .small-non-talk will do. — SMcCandlish [talk] [cont] ‹(-¿-)›23:12, 28 May 2007 (UTC)
Following discussion here about scroll boxes and printable versions, Pharos filed a Mediawiki feature request about the issue. The Brion Vibber said this would be better handled by modiying this page (Commons.css) to accomodate Pharos's request. Could someone who knows CSS update this page accordingly? Raul65415:37, 13 June 2007 (UTC)
Could we perhaps work in a way to deal with scrollbox panorama pictures too, a parallel problem I also mentioned in the feature request, while we're at it? Basically the issue would be shrinking these panoramas withe a reasonable-size box on the 'printable version'.--Pharos19:54, 13 June 2007 (UTC)
I'm not sure how to correct this. For the moment, I think we should focus on the references issue. Wide images are another issue altogether. --David Iberri (talk) 20:25, 13 June 2007 (UTC)
Is there also a problem with linked items in the the scrolling section not coming to the fore when using Apple's Safari?? That seems to be a feature that doesn't work for me or Orangemarlin. ... dave souza, talk20:10, 13 June 2007 (UTC)
Possibly my fault for not keeping my system up to date, as discussed at Talk:Evolution#References section as scrollable text, but if there are many users like me we don't really want such features to make reference sections significantly less usable for them. In my view, ... dave souza, talk 21:25, 13 June 2007 (UTC) oops, corrected link to section of evolution talk: that article displays "reference-scrolling" which looks tidy and doesn't quite work with Safari and Konqueror, apparently. ... dave souza, talk22:51, 13 June 2007 (UTC)
Why on earth to you want to have the references in a separate scrollable box, even on the not-for-printing-version? There is next to no content below the references; are as annoying as hell when you are using a scrollwheel; look ugly; and they add yet another inconsistent way of formatting the reference section. —Ruud22:22, 13 June 2007 (UTC)
The Featured Article Evolution does it that way. Actually, it would probably be better if there were a user level preference to govern how the Reference section was displayed, and a single simple markup for the content of that section. - Bevo23:05, 13 June 2007 (UTC)
One of the user preferences could be to not display References at all (and also not display the superscript indexes inline). That would be handy (even temporarily) for using a Wikipedia article in a presentation (enhanced readability of the unadorned text) - Bevo23:10, 13 June 2007 (UTC)
It's a discussion on whether to keep or delete {[tl|Scrollref}}, which serves the same function as the style proposed here. If consensus is to delete, then it follows that this style should not be used. –Pomte00:03, 15 June 2007 (UTC)
A class for sideboxes
{{Firefox TOC}} is an example of a sidebox. What classes should these have? Do we need to create a new class? It's clear neither a navbox nor infobox. —Dispenser22:09, 3 June 2007 (UTC)
That's a navigational template of the side boxes and headers variety. It's not an infobox because it doesn't include information specific to each article. It's a navbox because it's used for navigating between articles related to the topic Firefox. As listed in my second link, some of them use the classes infobox, toccolours and/or arbitrary styles. Some of them have the recognizable look of {{Methodism}}, but it's probably a good idea to have a coherent standard for most if not all of them. –Pomte02:27, 4 June 2007 (UTC)
Could we get some sort of class now for these so we don't have these thing tagged as infoboxes? It's better to do it now rather than later. —Dispenser06:02, 18 June 2007 (UTC)
A few months ago, there was enthusiastic support for highlighting references made using m:Cite.php when they get clicked. Could the same be applied to the ref and note templates? This would be very useful as the symbols (^) aren't always numbered, so it's hard to figure out which note it is at the bottom of the page. I notice that these use definition lists (dl) instead of ordered lists (ol), but setting dd:target works the same way, right? –Pomte16:29, 3 June 2007 (UTC)
As long as the id attribute is on the <dd>, it will work the same way in the browsers that support :target. However, I'm not seeing the definition lists you're talking about. What I see in {{note}} is a <cite> tag with an id that can be suppressed. Mike Dillon16:55, 3 June 2007 (UTC)
My mistake; I got confused because I listed some {{note}} the tags with : instead of * or #. Do it on the <cite> tag then, even if it'll highlight only a short symbol? –Pomte17:20, 3 June 2007 (UTC)
The following code creates a class that removes the styling from a TOC. Using this makes it possible to choose a different styling (width , background-color, border, etc.). I can imagine that it's not something you'd want to happen in normal articles, but in user talkpages, portals, etc. it can be very useful to be able to do this. Would it be possible to have this added to Common.css?
/* this class removes border and background-color from the TOC */
.tocnostyle table#toc, .tocnostyle table.toc {
border: none;
background-color: transparent;
padding: 0;
}
My understanding of the current practice is that we avoid adding things to common.css unless we know they have an important use, to keep bandwidth down. Is there a specific use for this being planned? — Carl (CBM · talk) 19:51, 23 June 2007 (UTC)
How to install
This may be obvious to some, but others seem to find it difficult to know what this article is all about. Perhaps it would be handy to place a comment near the top of these messages spelling out that one should view it's source and past the contents into the MediaWiki:Common.css article/message at your mediawiki site. I can tell you that I felt a little dumb having spent a few days figuring out something this obvious which a simple comment might have told me. --D0li022:11, 21 June 2007 (UTC)
If you want your styling to be identical to Wikipedia's, yes. The main purpose of this page is to provide the styling for Wikipedia; the page's name has special meaning to the software (as do most pages in the MediaWiki namespace). --ais523 10:15, 22 June 2007 (UTC)
"leave a comment" spacing
Now that the "+" sign next to the "edit this page" tab has been changed into "leave a comment", I'd suggest making the space between the tabs consistent. The space between the "edit this page" and "leave a comment" tabs should be the same as the space between "article" and "discussion", and I think it would also be best to make the space between "leave a comment" and "history" the same as the space between "discussion" and "edit this page". I don't know the relevant CSS portions, perhaps someone would be able to easily find them. (Otherwise I'll do some digging myself.) —msikma (user, talk)21:57, 13 July 2007 (UTC)
Ah, yes, I'm sorry. That's right. Anyway, it seems that the + has already returned, in which case I think it no longer matters too much. :) —msikma (user, talk)08:16, 14 July 2007 (UTC)
This added the colors DarkGray and PapayaWhip. The only valid CSS colors as of 2.1 are "aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, orange, purple, red, silver, teal, white, and yellow". Please use #FFEFD5 and #A9A9A9 respectively instead of PapayaWhip and DarkGray: this breaks CSS validation. —Simetrical (talk • contribs) 19:43, 15 July 2007 (UTC)
Just how does one go about 'activating' common.css and common.js on other wikis? I've been wondering this for some time, but have never really been able to find information on it. It would really help if the location of a tutorial or something for doing it was made obvious on here, too. --Dinoguy1000Talk18:26, 13 July 2007 (UTC)
All Wikimedia Foundation wikis have it enabled. Third-party wikis can enable it using
$wgSiteCss=$wgSiteJs=true;
in LocalSettings.php. This is not normally necessary, however, because they're turned on by default. The feature only exists in 1.5 or later. —Simetrical (talk • contribs) 02:51, 15 July 2007 (UTC)
Not sure if this is the right place, but where in here is the modification to get the title heading Main Page removed from the article and have the tab say main page and not article. This inquiry is per Wikipedia:Help_desk#Technical_Questions. --User:Charitwo/Sig 00:31, 25 July 2007 (UTC)
To remove the title heading, you need the CSS rule body.page-Main_Page h1.firstHeading, body.page-Main_Page h1.pagetitle { display: none; }. To change the tab, you need the function mainPageRenameNamespaceTab() from MediaWiki:Common.js, plus
See this diff (warning: very large and slow to load). The gray-on-slightly-different-gray really doesn't look good:
This cell's background looks a bit odd if you look closely.
vs.
This cell's background does not.
I figure it's best to do it in general, not just for th's:
yes
vs.
yes
The background for <code> is really meant for display on a white background. It works on the pale blue we have here, too, but non-presentational tables tend to (rightfully) have different-colored backgrounds, so it's not normally appropriate to set gray backgrounds for small chunks of text that might constitute the entirety of a table cell. It might be considered for <pre> too, but that tends to enclose more content, making a different background a bit more reasonable, so I'll leave that out of the request for now. —Simetrical (talk • contribs) 04:09, 22 July 2007 (UTC)
Sounds good to me. If people want their code blocks explicitly colored in these cases, they can do something like:
I'm not sure this change would be desirable on pages like Help:Wikitext examples#HTML tags (which demonstrates the effect of <code>), but I'm not sure if this would be enough to prevent the change. (The workaround mentioned above might not work in skins that don't grey-background code tags; I wonder if there are any such skins.) --ais523 17:44, 30 July 2007 (UTC)
Note that even prettytables are normally not affected unless the <code> is in a header cell: the code background is identical to the normal data cell background for wikitables/prettytables. Even in header cells, the code background is not easy to distinguish, as I illustrate above.
There absolutely are styles that don't use gray backgrounds for code tags. They may or may not be available by default in MediaWiki, but they're definitely out there. Not long ago I saw someone making a light-on-dark Wikipedia mirror. Inline colors should almost never be used outside of articles like, say, Gray. But honestly, the difference between white and F9F9F9 is tiny, completely invisible on the LCD I'm using now, and I don't see why anyone would want to manually restore it. —Simetrical (talk • contribs) 19:17, 30 July 2007 (UTC)
Your change was incorrect (did not match the request) and was a drastic change to the appearance of tables. Please change it back (and insert the line that was actually requested) --Random83221:51, 1 August 2007 (UTC)
I've reverted myself. Someone else will need to make the code additions, so I'll leave the editprotected tag active. --MZMcBride21:59, 1 August 2007 (UTC)
To clarify for anyone watching - the change that MZMcBride made (and reverted) was to remove the gray background on tables (wikitable/prettytable) - the proposed change (which I don't see any reason not to go ahead with) is to remove the background color from <code> tags inside such tables. --Random83222:02, 1 August 2007 (UTC)
Does anybody oppose setting a default presentation for <cite> elements? These elements are used in several citation templates such as Template:Citation and Template:Cite book, and they are all forced to include an inline style="font-style:normal" attribute to prevent the citations from being italicized in most browsers. COGDEN22:47, 20 July 2007 (UTC)
This is the standard display style of <cite> in all browsers. I agree it kind of sucks, but I don't know if just giving it an arbitrarily different behavior from expected is the best way to go. Perhaps it is, yes. —Simetrical (talk • contribs) 03:51, 22 July 2007 (UTC)
As a practical matter, all uses of <cite> I know of in Wikipedia already change the default representation, but they just do it inline, which isn't the best policy. I can't foresee any possible use of the element in Wikipedia where you would want an italic representation. Alternatively, and more conservatively, I guess we could create a new class for the <cite> element, such as ".citation".COGDEN21:35, 1 August 2007 (UTC)
Ah, thanks! Now I'll just test it a bit more and then I can "market" it to the navbox editors etc.
However, I suggest the addition of a comment above the nowraplinks CSS code so future readers/editors of commons.css don't need to wonder what the code does. Something like this:
/* Prevents line breaks in links. See docs at Template:Nowraplinks . */
How do I make the headers align left, but still keep the rest of the formatting? For example check the code here to see an ugly hack. There must be a better way. —MC19:41, 21 August 2007 (UTC)
You shouldn't. The general style is for headers to be centered, and that shouldn't be changed for a few tables in one random article without very good reason. However, if there's some really compelling reason, you can do it with inline CSS like so:
column-count and -webkit-column-count are unknown property declarations that get dropped on every Wikipedia page. Please fix it. --Gamer Eek03:25, 23 August 2007 (UTC)
column-count is a CSS3 property, -webkit-column-count and -moz-column-count are two custom non-standart properties for WebKit and Gecko engines. Until CSS3 is widely implemented, using all these properties together is a common way to make multi-column layout work in several browsers at the same time. There is nothing to fix, you simply have to ignore these CSS warnings ∴ Alex Smotrov04:50, 23 August 2007 (UTC)
I predict that this will reduce accidental insertion of '''Bold text''' and other such strings into otherwise constructive edits, by well-meaning users aiming for the top of the text box but missing, by about half. Thanks -- 217.42.77.24611:52, 4 September 2007 (UTC)
This is a request for an 8-pixel gap between the toolbar and the edit box, then. Do people think that this is a good idea? Does anyone have an objection? --ais523 16:06, 4 September 2007 (UTC)
Oh, I love it! I immediately added it to my personal monobook.css. Thanks 217.42.77.246. See I use Firefox, and when it finishes loading a page it inserts the toolbar and "jumps" the edit window down a bit. So if I click the top line of text to edit before the page have finished loading then that click ends up on one of the toolbar buttons when the page has finished loading. Very annoying. This margin might alleviate that problem. I'll probably use more margin than 8px for myself, but 8px seems like a good default. --David Göthberg19:42, 4 September 2007 (UTC)
Yes, I tested it beforehand, not with a bookmarklet, though; I have my own user CSS file (client-side, not on-wiki, as anonymous users don't get user CSS pages) and I added it to that. Usually I don't have the problem at all because I have the edit toolbar disabled completely. But I found (through searching) a large number of otherwise good edits where '''Bold text''' or ''Italic text'' or something else obviously from the toolbar had been added, obviously by mistake. I enabled the toolbar and made a few edits and it wasn't long before I went to click in the top-left corner of the edit box and hit the "Bold text" button by mistake. I was only editing a short page, so I noticed it immediately, but then I tried it on a longer page and found how easy it was to do it by mistake and not notice it. Try it for yourself: bring up the edit form for a long page, scroll the edit box down to the bottom, click in it somewhere near the end, then scroll it back up to the top. Now click the "Bold text" button. Notice how there's no sign at all of the inserted text, because it's been inserted at the cursor (which is still at the bottom of the page) when you're looking at the top. One could easily go on to click "Save" not realising that they had inserted it.
Of course, when you see '''Bold text''' ''Italic text'' [[Link title]] [http://www.example.com link title] == Headline text == [[Image:Example.jpg]] [[Media:Example.ogg]] <math>Insert formula here</math> Insert non-formatted text here --~~~~ ---- #REDIRECT [[Insert text]] <s>Strike-through text</s> <br /> <sup>Superscript text</sup> <sub>Subscript text</sub> <small>Small Text</small> <!-- Comment --> <gallery>Image:Example.jpg|Caption1 Image:Example.jpg|Caption2 </gallery> <blockquote> Block quote
</blockquote> {| class="wikitable" |- ! header 1 ! header 2 ! header 3 |- | row 1, cell 1 | row 1, cell 2 | row 1, cell 3 |- | row 2, cell 1 | row 2, cell 2 | row 2, cell 3 |} , it's obvious that someone's pressed all the buttons and then clicked Save just to see what would happen. This change won't stop such vandalism, but it won't make it any harder to detect either -- 217.44.236.16221:15, 4 September 2007 (UTC)
The prettytable class adds about as much code here as the template standarisation project would. And we're talking here about a major improvement, affecting possibly all article templates (just like prettytable can be found everywhere, too). I believe a project of this magnitude deserves some space in this file. :-) Миша1310:28, 2 September 2007 (UTC)
Agreed, CSS is the right thing to use here. I have no objection to putting the appropriate CSS here; out of the alternatives mentioned, I'd prefer drawing the bar using a large border than with an empty cell, both for browser compatibility reasons, and because the bar is a big border. --ais523 14:34, 3 September 2007 (UTC)
Yes, I prefer that too as a simpler solution. I also don't see an issue with the amount of css being added, whichever method is used there won't be too much. We already use css for the current messageboxes and talk page templates. the wub"?!"22:08, 3 September 2007 (UTC)
People here and at the project talk page have managed to convince me that I was wrong. Now I think I agree that those article message box templates need some CSS code. (But we still probably will use a meta template too, but that meta template in turn will use the CSS so it will be fully "skinnable".) Oh, should probably mention we are still working on it so the CSS code is not ready to deploy just yet. --David Göthberg23:45, 6 September 2007 (UTC)
The Wikipedia:Template standardisation project is ready to deploy. So we need to have our CSS code added. At the end would be fine, but it would be natural to have it right after the last ".messagebox" class since they are related.
By the way, currently the ".messagebox.small-talk" class is placed far away from the other ".messagebox" classes, why not move it up to the others at the same time? I think it has to be placed as the last of the ".messagebox" classes.
Anyway, here is the "article message box" code:
/* Article message box template styles */table.ambox{width:80%;margin:00010%;/* More compatible than "auto". */border-collapse:collapse;background:#f8fcff;border:1pxsolid#aaa;border-left:10pxsolid#39f;/* Default "notice" blue */}table.amboxth,table.amboxtd{/* The message body cell(s) */padding:0.25em0.5em;/* 0.5em left/right */}table.amboxtd.ambox-image{/* The left image cell */width:52px;padding:2px0px2px0.5em;/* 0.5em left, 0px right */text-align:center;}table.amboxtd.ambox-imageright{/* The right image cell */width:52px;padding:2px0.5em2px0px;/* 0px left, 0.5em right */text-align:center;}table.ambox-notice{border-left:10pxsolid#39f;/* Blue *//* border-right: 10px solid #39f; *//* If you want two blue bars */}table.ambox-serious{border-left:10pxsolid#c00;/* Red */}table.ambox-content{border-left:10pxsolid#f63;/* Orange */}table.ambox-style{border-left:10pxsolid#fc3;/* Yellow */}table.ambox-merge{border-left:10pxsolid#95b;/* Purple */}
Can we in CSS detect if we are in top of page (section 0) or some other section?
I am currently involved in the article message box standardisation effort. Some one brought up the question if we can simplify the message boxes so the same message box says for instance "This article may need to be wikified ..."
" when on top of the page and "This section may need to be wikified ..." when in some other section. They suggested using a parameter to the template. But I started thinking that maybe we can do it entirely with CSS? I mean, there is "display:none;" which can hide things. Question is, can we in CSS in some way detect if we are in section 0 or not? That is before the first <H2> tag etc. Or are there some magic MediaWiki words or functions we can use?
Yeah, I didn't expect there to be a simple solution. But I asked anyway just in case. Sometimes some seemingly hard problems have a simple elegant solution. --David Göthberg22:22, 5 September 2007 (UTC)
Sections don't have a corresponding entry in the DOM (they're just the distance between one <h2> and the next <h2>), so there can't be a CSS selector for the first section. --ais523 16:20, 6 September 2007 (UTC)
It's not currently possible to do this with CSS only. Because sections aren't wrapped in an element, there's no way for the browser to determine what section you are in, let alone whether it is section 0. Sections probably should be wrapped in a <div>, and they easily could be, but that's a matter for MediaWiki coders to address. COGDEN23:12, 6 September 2007 (UTC)
Yeah, I did look through the rendered code for some pages and could not find anything that wrapped the sections. So as ais523 said: "No corresponding section in the DOM" and as COGDEN said, if they were only wrapped in for instance a div (marked with some class or id telling section number) then it would be easy. I just hoped there were some more tricks in CSS or some MediaWiki magic words that I didn't know about yet. Ah well, thanks for your responses all of you. --David Göthberg23:40, 6 September 2007 (UTC)
Actually, there's a CSS3 selector that might help:
#bodyContent h2 ~ *
selects all sections except the first, and also the show/hide link on the table of contents (which isn't a problem, because there's unlikely to be a messagebox there!). (Firefox 2, at least, seems to have implemented this.) However, CSS3 hasn't even been officially released yet as far as I know, and the chance of IE understanding this is therefore close to zero (although I haven't checked). It means 'an element that's a sibling of a second-level heading and comes somewhere after it on the page'. --ais523 17:38, 12 September 2007 (UTC)
Wow, thanks ais523. So it will work in some browsers and in the future probably in all browsers. So if we put some span tags with some ID or class in we can mark the text "article or" in the text line "This article or section needs wikifying" and then use a hide statement in the CSS and thus only part of the sentence will be seen when the message box is in a section: "This section needs wikifying". But for the message boxes in the page heading (and for bad browsers) the entire sentence will be visible. But still, that is a big improvement. Guess I have some testing to do. Thanks again ais523. --David Göthberg18:06, 12 September 2007 (UTC)
I don't think that selector will work. h2 ~ *, as I understand it, means any html element * preceded by an h2 heading as a sibling. The problem is that the selected element would come after the heading, instead of before. You can't reverse the order such as #bodycontent * ~ h2, because in this case, the h2 would be selected, which is not what you want. I don't think there is a "succeded by" selector in CSS3. COGDEN18:25, 12 September 2007 (UTC)
The selector selects all sections except the first (any * preceded by an h2). Therefore, the first section is the section where the selector does not match. (I agree that reversing the order doesn't work, and there isn't a selector for 'succeeded by'.) However, a 'succeeded by' selector isn't what's wanted anyway, because it would select all sections except the last, rather than all sections except the first. --ais523 18:35, 12 September 2007 (UTC)
Weeee! It works, and it works VERY well. And I managed to tweak it to select also only section 0 !!! I'll do a little more testing since there seems to be several ways to do this, then I'll come back here with an explanation and links to examples. It works in my Firefox and my Opera but of course not my very old Internet Explorer 5.5 (which I keep for compatibility testing of web pages). ais523, your the master! --David Göthberg18:54, 12 September 2007 (UTC)
Here is my test code User:Davidgothberg/Test15. The trick I do to select section 0 is to use the fact that on top of section 0 is a H3 tag with the text "From Wikipedia, the free encyclopedia". So I turn on whatever I want to do at the H3, then turn it of at the next H2 tag. That is what "cascading" means, that the last command is the valid one. Opera only needs one line that can select everything but for Firefox I had to specify many things like DIVs in DIVs and so on. So to make it work in Firefox the code became pretty ugly. --David Göthberg23:41, 12 September 2007 (UTC)
:lang(grc){font-family:Athena,Gentium,"Palatino Linotype","Arial Unicode MS","Lucida Sans Unicode","Lucida Grande",Code2000;
to
:lang(grc){font-family:"Athena Unicode",Gentium,"Palatino Linotype","Arial Unicode MS","Lucida Sans Unicode","Lucida Grande",Code2000;
The original Athena Roman font is no longer available. The current version of Athena Unicode gives "Athena Unicode" for its font family and not "Athena", and so is not detected.
The green template documentation boxes are created by Template:Template doc inline. It has its styles hardcoded, but also has the currently unused class "template-documentation" in its header. So I suggest moving its styles into common.css so the template docs can be skinned.
I took the liberty of adding a proper margin on top so templates and their docs won't come to close. Later on I will change the template so it only uses this class and no hardcoded styles. (Note, never use that template directly, instead see Wikipedia:Template documentation.)
Thanks. Only question now is how long to wait. Since we just learnt the hard way with the .ambox classes that Wikipedia has set CSS caching to a month or so and that some browsers seem to honour that! Perhaps we should request a lowering of the default caching to 1 week?
The 25px margin-top seems excessive. I propose decreasing it to 1em, as I've done to {{Documentation}} in this change, to make the transclusions at for example WP:SONG#Infobox flow better. A 1em margin-top combined with the box should be enough to keep the doc separate from the preceding content. --PEJL19:43, 19 October 2007 (UTC)
Nuke it. Banner ads give me a headache. *Clarification: Fundraising is necessary, and a simple banner like the Wikimania banners would be fine. But this is way too much. I would support a better-designed one. Neranei(talk)01:07, 23 October 2007 (UTC)
(3x EC) What happened a single line of text that could be hidden? Terminate with extreme prejudice. Oh, and you can hide it by adding .fundraiser-box{display:none;} to your monobook.css. east.718at 01:10, 10/23/2007
Or, even better, marquee { -moz-binding: none } or marquee { display: none }, which only disables the scrolling. --cesarb01:21, 23 October 2007 (UTC)
I know fundraising is necessary, and would tolerate a well-designed banner (which lost the eye-straining jerky scroll and actually identified itself as part of the semi-annual Fundraiser), but I agree that what has been presented here is not appropriate for a message displayed to all site visitors. It should be removed/replaced. Dragons flight01:14, 23 October 2007 (UTC)
For the record, I said "removed" in the sense that we shouldn't necessarily wait for a replacement to be created before removing it. If a replacement is made soon, then okay, if not, I would still encourage it to be removed for now. Dragons flight01:22, 23 October 2007 (UTC)
I agree that a banner at all is okay, as long as it's not ghastly like this. Until there's a better one, I support the removal. isaid01:21, 23 October 2007 (UTC)
As hopefully all sysops who read this realize anyway, the banner was placed there by an employee of the Wikimedia Foundation acting, presumably, in his official capacity. Consensus isn't going to overrule the Foundation if it wants it to stay. Whether anyone removing it will get summarily desysopped I don't know, but it would hardly be unprecedented.
I am seeing no "dismiss" option. There should be one - if one cannot be added, the entire thing should be removed until it can be rewritten in such a way that it can be dismissed. I do not see why as someone who has donated I should have to be subjected to this annoying and distracting notice. It's worse than adspam. And I am not going to edit my monobook.css, because whatever is done should be done for all users, not merely those with superior technical skills. Orderinchaos13:24, 23 October 2007 (UTC)
Incorrect - a "Show more/Hide this message" was added recently. Bypassing my cache on three occasions in 12 hours has failed to rectify the problem. Orderinchaos23:13, 23 October 2007 (UTC)
It looks like a true dismiss was added and then removed again. --ais523 11:53, 24 October 2007 (UTC)
(e/c)Delete. No prejudice against creating a replacement banner that does not scroll, with an option to close built in. Going back to the original format is better. Also, on another area of discussion a visually impaired user said that ad messed with their interface, so it's more than just an annoyance. ~Eliz81(C)01:28, 23 October 2007 (UTC)
The scrolling notice in one window eats 54% of the CPU in one of my browsers; makes it difficult to use more than one window in Wikipedia, or do anything else while Wikipedia is up. We already went through this mess on Wikinews. (SEWilco02:02, 23 October 2007 (UTC))
The scrolling is also interfering with the goal of writing the encyclopedia. On my fast machine the scrolling interferes enough with the edit window that positioning or multiple backspacing become jerky and unpredictable. (SEWilco02:02, 23 October 2007 (UTC))
This rule is here for Template:Navbox generic. Look at the two included examples on Template:Navbox_generic#Layout_of_table: in Firefox the rule works and the backgrounds under {group1} and {title} are different. Not so in IE and Opera (see Comparison of layout engines (CSS)). I really doubt CSS3 should be used in Common.css. Either not() should be removed (making the rule work in Opera and IE7, but not in IE6) or, even better, the whole rule should be removed and {{Navbox generic}} should be modified like {{Navbox}} which specifies inline styles for all rows and thus doesn't need any advanced CSS at all ∴ AlexSm18:26, 17 October 2007 (UTC)
I think the background should not be defined inline. Instead, I think defining a sererate #id for the row headers would be more appropriate. — Edokter • Talk • 18:40, 17 October 2007 (UTC)
Actually, since {{Navbox generic}} has been deprecated in favor of {{Navbox}} (and thus shouldn't be (but not necessarily isn't being) used for any navigation boxes), this isn't terribly important. I'll put in an editrequest on Navbox generic anyways, though (unless someone beat me to the punch). --Dinoguy1000Talk04:58, 18 October 2007 (UTC)
What is the point of removing code that only rendered extra information to those using a browser better supporting CSS. Using style inline is a dirty solution and should be avoided whenever possible as it uses more bytes than if it set in the style sheets. Additionally it prevents users from accessing those elements using their monobook.css page. It wanted to support those users you always remove the negate function and swap the two colors around. —Dispenser21:57, 5 November 2007 (UTC)
Agreed; unless the CSS3 code renders improperly in browsers that don't support it, there's no reason to not have the code. EVula// talk // ☯ //22:25, 5 November 2007 (UTC)
In this particular case the code was only used for deprecated template and only good for Firefox but not for IE and Opera. I think that was a good enough reason to remove it. You're welcome to suggest :first-child (without :not) at {{Navbox}} talk page; don't forget to mention that this won't work in IE6. P.S. The statement about user's monobook.css is false: just use !important ∴ AlexSm00:02, 6 November 2007 (UTC)
If the same can be done without CSS3, it should be done that way (using an extra class or id). There's absolutely no reason to use CSS3 if it can be avoided. — Edokter • Talk • 00:17, 6 November 2007 (UTC)
What about all the navboxen that don't use the template but are just plain tables with the navbox class? —Ruud00:49, 6 November 2007 (UTC)
The CSS3 capable browsers loose their first TH color, for other browsers it stays the same (which didn't show the right color anyway). — Edokter • Talk • 01:02, 6 November 2007 (UTC)
Sometimes one might want to float a wikitable. Currently, when you simply add style="float:left" or style="float:right" to the wikitable this yields an ugly effect. A screenshot serves to illustrate this effect. It contains four tables. The first two are floating right and left using only style="float:left"; the ugly effect clearly shows. The next two tables demonstrate how the tables should look; this was faked using extra inline CSS. Screenshot.
The effect is sufficiently ugly that wikitables cannot be floating without using inline CSS, which is a bad solution. It is my opinion that either the wikitable CSS class should be better behaved when style="float:left" or style="float:right" is added (if this is at all possible) or two extra CSS classes should be defined, for tables that float left or right.
As a closing remark, I would like to note that this effect appears in all browsers I have: Safari, Konqueror, IE and Firefox, regardless of fontsize, and window width. The screenshot was taken from Safari, but differences from what is seen in other browsers are only noticable on the pixel-level, i.e. they are very small indeed, at least on my computer. Shinobu11:54, 22 September 2007 (UTC)
(Markup based on the "floatleft" and "floatright" classes in monobook/main.css that are used for thumbnails. We could almost use them as is, but they seem to come with some annoying extra rules that italicize text in paragraphs and such.) —Ilmari Karonen (talk) 18:59, 7 November 2007 (UTC)
Could you please explain the purpose of position: relative; here?
Why limit the new classes to wikitable and prettytable only?
The only effect the "position: relative" appears to have is to establish a containing block for any absolutely positioned elements.[13] I'm not sure it's needed; it's been part of the "floatleft"/"floatright" classes since forever (I've only been able to trace it back to rev:2909), but it might be obsolete or it might have some purpose specific to image thumbnails. As for making the declarations apply only to "wikitable"/"prettytable", the idea would be that we can later add similar declarations for other classes without having to worry about conflicts. I'm assuming that there are currently no CSS rules applying to the classes "left" and "right" by themselves; if we were to make these declarations non-"wikitable"-specific, we'd have to be damn sure that those class names aren't used anywhere else at all. —Ilmari Karonen (talk) 22:42, 7 November 2007 (UTC)
Keep in mind that IE6 doesn't correctly parse multiple-class constructs like .wikitable.right. It will parse it, IIRC, exactly the same as if you just put ".right" to begin with. —Simetrical (talk • contribs) 19:13, 8 November 2007 (UTC)
Oh. Well, that rather shoots down that idea, then. So, if we make the classes stand-alone, what should we call them? Are "left" and "right" good, or should we call them something less likely to cause conflicts? And if so, what? (Keep in mind that "floatleft" and "floatright" and already taken, and, ironically enough, have extra rules that make them unusable for general purposes.) —Ilmari Karonen (talk) 21:51, 8 November 2007 (UTC)
NNot done - I don't think this will have any effect: I tested Special:Newpages in all skins, and the only one that did not use yellow was Nostalgia (preview). I'm ignoring myskin because its purpose is to be user-customized. MediaWiki:Nostalgia.css already includes this code, so an addition here probably won't have any effect. Nihiltres{t.l}16:14, 17 November 2007 (UTC)
The class marks off an item of metadata which most human readers neither wish not need to know, but which is essential for the automagical indexing of chemical compounds. The principal is the same as for Persondata, but the metadata are different, hence the new class. The objective is to allow searching of Wikipedia by chemical structure. Physchim62(talk)18:54, 7 November 2007 (UTC)
Then perhaps the class should have been simple metadata { display: none; speak: none } from the start? Right now it can be at least merged with persondata class above ∴ AlexSm21:00, 7 November 2007 (UTC)
It can hardly be merged without breaking persondata, as far as I can see, which is why I created a separate class with a separate name. Physchim62(talk)21:08, 7 November 2007 (UTC)
Why is that? Search engine don't actually look at the class name, do they? All it does is control the display. For .persondata it's too late to change it's name since it is being used to much, but it's not too late to create .metadata for InChI and possible future metadata templates. I'll implement it now, and I would urge to convert InChI to use .metadata instead. — Edokter • Talk • 21:49, 7 November 2007 (UTC)
Yes, I suggest we accept the current situation, which has a perfectly good rationale behind it. If you wish to deal with metadata in a more "rational" sense, we can always have a longer discussion in a forum which receives more traffic. Physchim62(talk)12:30, 8 November 2007 (UTC)
Leaving it as it is isn't good enough. This is the most appropriate forum, beside the Village Pump maybe, but this is more of an administrative issue then it is a technical one. We can't have Common.css fill up with seperate, yet identical metaclasses that are only used in one template. So we need to come up with a classname that serves any future metaclasses. — Edokter • Talk • 13:16, 8 November 2007 (UTC)
Leaving it as it is is perfectly good enough, you yourself are not the personal guardian on Common.css. I shall place posts on VPP and VPT this afternoon. Physchim62(talk)13:20, 8 November 2007 (UTC)
Actually, I do regard myself as one (of many) guardians if this and other system files, and there is nothing wrong with that; this page is loaded with every pageload, therefor each addition must be discussed beforehand. There is nothing "pretentious" about it. I'm actually more inclided now to just remove the class, as you seem to misunderstand that Common.css is not to be used for adding low-use classes, which are better served in-line. We add them when they become high-use. We just had a major cleanup, and I for one like to prevent another one. — Edokter • Talk • 13:52, 8 November 2007 (UTC)
Sorry? What are the relevant points then? Your rational that "the metadata is different" doesn't hold; you could easily have used persondata and it would have worked fine. Or at least you could have put the name in the same class (as I did) instead of ceating an entirely new, duplicate class. I will repeat though that Common.css must be as small as possible, that is something you cannot dismiss. Now, please come up with a new, generic, metadata class name and use that one instead. Because .InChI isn't going to be around much longer. — Edokter • Talk • 17:43, 8 November 2007 (UTC)
Before this degenerates further into a flame war, I'd like to point out that using a single class for all types of hidden metadata does have at least one concrete benefit besides keeping Common.css short: it ensures that any new types of metadata will actually be hidden from view from the start, rather than only gradually as the latest changes to Common.css work their way into readers' browser caches over the following 31 days. That said, the same caching that creates this delay also mitigates Edokter's point above: This page isn't really served with every pageload — it would be more correct to say that it gets served to each Wikipedia user once a month. —Ilmari Karonen (talk) 18:11, 8 November 2007 (UTC)
Do we want a seperate class for each type of metadata, or is one class sufficient? In second case, is there, besides the perhaps somewhat non-generic name, any good reason not to use the persondata class for the chemical metadata as well? —Ruud20:50, 8 November 2007 (UTC)
The "persondata" class may be used by programs parsing the metadata, so it probably shouldn't be reused. What I'd suggest, for the future, would be to give each type of hidden metadata two classes: one, defined here, which simply marks it as hidden and has no deeper semantic significance, and another designating which kind of metadata it is. The latter would not necessarily need any CSS rules applied to it; it would simply serve as a semantic marker. Of course, the system could and should be modified as needed to accommodate the peculiarities of any existing microformats we might wish to implement. Anyway, as for the name of the generic metadata class, might I suggest simply "hidden"? Assuming it's not in use already, of course. —Ilmari Karonen (talk) 21:45, 8 November 2007 (UTC)
That might cause some creative people to abuse it for things it's not intended for. machine-readable might be a better name in that case. —Ruud22:11, 8 November 2007 (UTC)
Since we'd want to use this class on all talk namespaces, the template namespace, and perhaps the user and Wikipedia namespace (i.e., the majority of namespaces), we could leave the above attribute alone and make the hidden-redlink class !important display: block in disallowed namespaces. GracenotesT§ 02:40, 2 December 2007 (UTC) :Note: This discussion has been included in the list of Cyprus-related deletion discussions. –Cupper52Discuss!13:46, 11 January 2020 (UTC).
Gimmetrow is right; the developers were pretty clear about this last time. As such, editprotected request disabled. --MZMcBride00:25, 3 December 2007 (UTC)
