MediaWiki talk:Common.css/Archive 3

From Wikipedia, the free encyclopedia

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents 1 Remove or demote Titus Cyberbit Basic in template unicode 2 Common.css vs Monobook.css 3 Minor non-compat bug 4 Wiktable caption-side 5 Archive? 6 References small 7 Copied from WP:VP/T 8 Hiding links with new .admin class 9 Class for inline list 10 hiddenStructure again 11 span.texhtml 12 CSS Class for Mini-talk-page templates 12.1 Implementation 13 Navbox width 14 metadata 15 Rollback 16 Improving template code 16.1 Classes instead of id's 16.2 Divs instead of layout tables 16.3 Other templates 17 CSS error 18 Messagebox tables require inline styles 19 CSS errors 20 .references-small -> 92% 21 geography infobox style 22 Removal of styling information for wikitable and infobox classes 23 Removal of geography related classes 24 Useless link in printout fixed 25 Font size of message box standard-talk 26 NavFrame styles 27 PDF icons 28 "Hello link spammer" 29 Consistent styling for edit-page messages 30 Highlight the clicked reference

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?

Benwing 00:29, 3 September 2006 (UTC)

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. Plugwash 00: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 • talk 09: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)

Minor non-compat bug

This is what firefox tells me all the time:

Error: Unknown property 'column-count'.  Declaration dropped.
Source File: http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=2678400
Line: 31

_→AzaToth 13:26, 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. —Michael Z. 2006-09-14 19:30 Z

It shows only up in the console. _→AzaToth 20:24, 14 September 2006 (UTC)

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? —Ruud 22: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?  —Michael Z. 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.  —Michael Z. 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. Ingoolemo ^talk 20: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. —Ruud 22:53, 14 September 2006 (UTC)

{{{name}}}

[[{{{image}}}|250px]]
{{{caption}}}
Type:	{{{type}}}
Manufacturer:	{{{manufacturer}}}
Designed by:	{{{designer}}}
Maiden flight:	{{{first flight}}}
Introduced:	{{{introduced}}}
Retired:	{{{retired}}}
Status:	{{{status}}}
Primary users:	{{{primary user}}} {{{more users}}}
Produced:	{{{produced}}}
Built:	{{{number built}}}
Unit cost:	{{{unit cost}}}
Variants:	{{{variants with their own articles}}}

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

{|
<span id="63283501856" />
=={{{name}}}==
|-
|{{{image}}}
|- style="border-top: 1px solid #aaaaaa;"
|'''Type:'''|{{{type}}}

etc.

|}

 ?

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. Ingoolemo ^talk 02: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:

   {| class="wikitable wt-academiccaption"

 —Michael Z. 2006-09-15 03:04 Z

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? --Dpryan 22: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.  —Michael Z. 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? —Ruud 19: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. —Michael Z. 2006-09-16 14:17 Z

inadequately discussed before being implemented

I've brought it up a few times 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:

1. "Cups of coffee consumed by each senator."
2. "Who spends the most on pollution cleanup?"

A caption may not always be necessary." [3]— Omegatron 05:26, 16 September 2006 (UTC)

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. —Michael Z. 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. —Ruud 22:30, 17 September 2006 (UTC)

Archive?

This page is getting too large. Should I archive the talk page? Any comments about this would be welcomed. --Siva1979^{Talk to me} 20:11, 15 September 2006 (UTC)

Just archive if you feel like it, usually take all from the start to the end of the last month and archive it. _→AzaToth 21:45, 15 September 2006 (UTC)

Yes please. No need to ask, though. Assume consensus ;) --Ligulem 23:10, 15 September 2006 (UTC)

Well, I have just archived the contents up to August 2006 comments. Hope it is up to satisfaction. --Siva1979^{Talk to me} 02:08, 16 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. — Omegatron 00: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. --Ligulem 08: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. --Siva1979^{Talk to me} 19: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. Gimmetrow 21:52, 24 September 2006 (UTC)

Done. —Ruud 21:57, 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.) —Ruud 22: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. Gimmetrow 00: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. — Omegatron 00:55, 25 September 2006 (UTC)

Copied from WP:VP/T

Hoping the below might prompt some code tweaking. Best wishes, David Kernow (talk) 13:30, 17 October 2006 (UTC)

Original heading: Top-level TOC template...?

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:

.toclimit5 li.toclevel-6 {display:none}
.toclimit4 li.toclevel-6, .toc4 li.toclevel-5 {display:none}
.toclimit3 li.toclevel-6, .toc3 li.toclevel-5, .toc3 li.toclevel-4 {display:none}
.toclimit2 li.toclevel-6, .toc2 li.toclevel-5, .toc2 li.toclevel-4, .toc2 li.toclevel-3 {display:none}
.toclimit1 li.toclevel-6, .toc1 li.toclevel-5, .toc1 li.toclevel-4, .toc1 li.toclevel-3, .toc1 li.toclevel-2 {display:none

And then creating a template to handle this:

<div class="toclimit{{{1|5}}}">__TOC__</div>

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)

The best route would be to propose it at MediaWiki talk:Common.css. —Simetrical (talk • contribs) 04:24, 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)

Exactly when would it be useful to hide non-top lelvel headings in the the TOC? —Ruud 15:27, 17 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). --Ligulem 12: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. --Ligulem 15: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 Dillon 14: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 Dillon 16: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 Dillon 17: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;
}

from MediaWiki:Common.css. The 8 transclusions of Template talk:Hiddenref are not worth keeping this obnoxious hiddenStructure definition any longer. --Ligulem 18:09, 1 October 2006 (UTC)

There are litterally thousands of palces this template can be transcluded to, it has also only be "alive" for two weeks. thanks/Fenton, Matthew Lexic Dark 52278 Alpha 771 18:27, 1 October 2006 (UTC)

I've put {{Hiddenref}} on Tfd --Ligulem 18:44, 1 October 2006 (UTC)

Then we must hope that no one are going to transclude the template to more places. _→AzaToth 18:57, 1 October 2006 (UTC)

I've disabled it per method of R. Koot. People kept reinserting it into templates. We need to give it a stop now. The most significant templates on User:Ligulem/work/hiddenStructure removal have been converted now. Will do the rest in the coming days. --Ligulem 08:53, 13 October 2006 (UTC)

There are about two dozen pages which have the hiddenStructure class substituted in them. I'll be working on those. —Ruud 10:32, 13 October 2006 (UTC)

All templates using hiddenStructure have been converted to {{#if:...}}, are on tfd or are unused. See User:Ligulem/work/hiddenStructure removal. Thanks everybody for helping! --Ligulem 22:29, 22 October 2006 (UTC)

So now will you remove the hiddenStructure section from the Common.css? -- Netoholic @ 05:17, 23 October 2006 (UTC)

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. --Ligulem 08: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. --CBD 22: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:

<math>	HTML	PNG
Surrounding a2 + b2 = c2 text	Surrounding a2+b2 = c2 text	Surrounding text

—Mets501 (talk) 20:55, 26 October 2006 (UTC)

This has previously been brought up with the mathematics community, who rejected the idea and explained how to use a personal style sheet. --KSmrq^T 22: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. — Omegatron 15: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)

You want to change the serif HTML equations into sans-serif, so that they look the same as the serif PNGs? — Omegatron 02:19, 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? — Omegatron 13: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. — Omegatron 18:35, 29 October 2006 (UTC)

It seems like a better way to acheive standardization this would be to help identify articles that aren't using <math> for equations and change them. This could be supported by a cleanup template (e.g. {{needsmath}}) and a maintenance category like Category:Pages needing equation conversion. Mike Dillon 16:27, 29 October 2006 (UTC)

That would certainly be better, but would be a lot of manual work. I can't imagine how a bot would do it. —Mets501 (talk) 18:01, 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. — Omegatron 18: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 A ⁺ − A (<math>A^+ - A</math>) with A⁺ − A (''A''⁺ − ''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 ⁺. 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 Dillon 02: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 A² (<math>A^2</math>). I guess it has to do with the fact that we do want space around the plus sign in A + B. -- Jitse Niesen (talk) 06:21, 2 November 2006 (UTC)

We really need Blahtex! ;-) —Mets501 (talk) 12:09, 2 November 2006 (UTC)

Definitely. When is this finally going to be implemented? — Omegatron 13:18, 2 November 2006 (UTC)

''A''⁺ − ''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 agree, that's why I suggested changing them to sans-serif. —Mets501 (talk) 20:37, 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)

I don't know about you, but I can't stand cleartype. Everything looks so blurry with it. —Mets501 (talk) 22:56, 29 October 2006 (UTC)

Depends on your screen. On my 130 DPI LCD, it looks much nicer than without. — Omegatron 01:16, 1 November 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)

some discussion — Omegatron 21:18, 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. —Ruud 11: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)

Here is an example that was used in User:Ganeshk/sandbox/peerreview:

{{{!}} cellspacing="0" style="width:238px; background:#F8EABA; border:1px solid #C0C090;" 
{{!}} style="width:45px; height:45px; background:#F8EABA; text-align:center; font-size:12pt; color:#fff;" {{!}} [[Image:Nuvola_apps_kedit.png|30px|Peer review]] 
{{!}} style="font-size:8pt; padding:4pt; line-height:1.25em; color:#000;" {{!}} A '''[[Wikipedia:Peer review/{{PAGENAME}}|request has been made]]''' for this article to be [[Wikipedia:Peer review|peer reviewed]].
{{!}}}

-- Ganeshk (talk) 18:49, 4 November 2006 (UTC)

I'll support that. Looks like a good easy way to implement optional smaller talk page templates. —Mets501 (talk) 20:05, 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". —Michael Z. 2006-11-05 03:38 Z

Yeah, I think this would be the best addition:

.messagebox.small-talk {
  width:238px;
  font-size: 85%;
  float: right;
  clear: both;
}

—Mets501 (talk) 03:43, 5 November 2006 (UTC)

Mets, Thanks! I went ahead and posted this at Village Pump. -- Ganeshk (talk) 23:56, 5 November 2006 (UTC)

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:

.messagebox.small-talk {
   width:238px;
   font-size: 85%;
   float: right;
   clear: both;
   margin: 0 0 1em 1em;
}

since the "auto" margins on messagebox will center the template otherwise. Kirill Lokshin 14:15, 6 November 2006 (UTC)

Kirill, I tried in my monobook and sandbox. Still doesn't work. -- Ganeshk (talk) 00:23, 7 November 2006 (UTC)

Ganeshk, you must put the code in User:Ganeshk/monobook.css, not User:Ganeshk/monobook.js.

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

.messagebox.small-talk {
  width: 238px;
  font-size: 85%;
  float: right;
  clear: both;
  margin: 0 0 1em 1em;
  line-height: 1.25em; 
  background: #F8EABA;
}

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)

Thanks! -- Ganeshk (talk) 19:38, 7 November 2006 (UTC)

Navbox width

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 Dickman ^talk 21: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. —Ruud 22: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 Dickman ^talk 00: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:

/* Metadata */
table.metadata {
    border: 1px solid #aaaaaa;
    display: none;
    speak: none;
}

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. _→AzaToth 15:34, 14 October 2006 (UTC)

The class is intended for the Wikipedia:Persondata effort. It is used by the {{Persondata}} template. Also, I think the notices generally use .messagebox, not .metadata. As far as I know, only Persondata uses that class. Mike Dillon 22:32, 21 October 2006 (UTC)

Templates like {{Cleanup}} are using the class metadata _→AzaToth 14:55, 22 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:Beland reverted {{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.

The class used by {{Persondata}} should be changed, since it is just in one template, and this rule should be changed to match the new class. Mike Dillon 15:35, 22 October 2006 (UTC)

Also, as with the hiddenStructure problem, it has been pointed out that Wikipedia:Persondata should not be done with CSS hiding because of accessibility concerns. Mike Dillon 15:45, 22 October 2006 (UTC)

The change I would recommend is changing the CSS selector in the rule above to use the #persondata id instead of the .metadata class:

/* Persondata */
#persondata {
    border: 1px solid #aaaaaa;
    display: none;
    speak: none;
}

That way it can target what it is intended for. The .metadata class on {{Cleanup}} and others predates {{Persondata}}, so the earlier, more widespread use should not have to change. Mike Dillon 00:00, 23 October 2006 (UTC)

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. Kaldari 06: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:

1. Add new .persondata class
2. Edit Persondata template to use .persondata class
3. Wait until all 3,000 or so article caches have been refreshed (no idea how long this would take)
4. 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? Kaldari 00: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 Dillon 01:45, 25 October 2006 (UTC)

Wouldn't the use of #persondata break the formatting if the Persondata template were used more than once in a article, for example in Wright Brothers or Brothers Grimm (hypothetical examples)? Kaldari 02:12, 25 October 2006 (UTC)

Yes. Mike Dillon 02:49, 25 October 2006 (UTC)

Uh, then I guess I'll proceed with the original plan, if that seems best. Kaldari 03:11, 25 October 2006 (UTC)

Cool. I think the multiple id thing was discussed at Wikipedia talk:Persondata once upon a time and my feeling is that it should be dealt with if and when it actually becomes a problem. Thanks for your help. Mike Dillon 03:25, 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. Rocksong 09: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 Dillon 16: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. —TheMuuj ^Talk 21: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? Kaldari 22: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. —TheMuuj ^Talk 03: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:

1. {{Persondata}} now has both .metadata and .persondata
2. That means it is hidden for anyone with an old copy of Common.css (without .persondata), since the template still has .metadata
3. 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
4. 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
5. 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 Dillon 04:05, 2 November 2006 (UTC)

Here's the search. Mike Dillon 04:12, 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. Kaldari 05: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 Dillon 15:19, 2 November 2006 (UTC)

If you both think that's the best way to go, I'll trust your judgement. Kaldari 16:13, 2 November 2006 (UTC)

Now that over a month has passed, does everyone think it is reasonably safe to remove the .metadata class? Kaldari 19: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 Dillon 20: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 Dillon 20: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 Dillon 17: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 */
 }

What I don't understand is why the above media-specific definitions aren't in common.css. -- PatrickFisher 00:24, 8 December 2006 (UTC)

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 Dillon 05:48, 8 December 2006 (UTC)

Rollback

Why have all rollback links suddenly made boldface? (Radiant) 21:37, 18 November 2006 (UTC)

Yup. Looks ugly in bold. --Ligulem 00:05, 19 November 2006 (UTC)

Undone for now (because I don't see any discussion on the subject and I do see dissent here). (Radiant) 14:36, 20 November 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) – Gurch 12: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. —Michael Z. 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">. —Michael Z. 2006-11-06 22:02 Z

Divs instead of layout tables

Using a table to lay out template:Disambig and other disambiguation notices is contrary to WCAG's guideline no. 3: Use markup and style sheets and do so properly (checkpoint 3.3, a priority 2 checkpoint, says "Use style sheets to control layout and presentation").

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.

Common.css currently has:

#disambig {
    border-top: 1px solid #cccccc; 
    border-bottom: 1px solid #cccccc;
}

This could be changed to:

.dabnote {
    border-top: 1px solid #ccc; 
    border-bottom: 1px solid #ccc;
    padding-left: 50px;
    min-height: 50px;
    background: url(http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Disambig_gray.svg/30px-Disambig_gray.svg.png) no-repeat 10px center;
    font-style:italic;
}

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="/wiki/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="/wiki/Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="/wiki/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="/wiki/Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="/wiki/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. —Michael Z. 2006-11-06 22:02 Z

Side note: template:Disambig is currently transcluded into 70,928 pages. --Ligulem 22:46, 6 November 2006 (UTC)

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? —Michael Z. 2006-11-06 23:01 Z

(A1) I've used m:MWB to build the list. (A2) No. So there are even more... --Ligulem 23:39, 6 November 2006 (UTC)

Yay for replacing table layouts! — Omegatron 23:51, 6 November 2006 (UTC)

Update: I changed the class name to dabnote, avoiding confusion with the id name, as well as harmonizing with .dablink and saving another byte. —Michael Z. 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. EVula 05:26, 7 November 2006 (UTC)

A couple of issues:

1. 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.
2. 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.
3. 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.
4. 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.
5. You could pare down the table markup as follows:

   <table class="notice metadata dabnote">
    <tr>
    <td><a href="/wiki/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="/wiki/Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="/wiki/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)

On second thought, this might be an okay choice for moving to div, but still don't move the image to CSS. —Simetrical (talk • contribs) 05:51, 7 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 Dillon 22: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. — Omegatron 00:30, 4 December 2006 (UTC)

Except that IE6 doesn't support display: table;. —Simetrical (talk • contribs) 05:51, 7 December 2006 (UTC)

And really, how many people really use IE? Only perhaps 80% of the population... EVula // talk // ☯ // 05:58, 7 December 2006 (UTC)

Other templates

What other templates need this treatment? (apart from {{disambig}} and its variations) —Michael Z. 2006-11-06 23:54 Z

CSS error

FireFox's error console reports the following CSS error on every page:

Warning: Unknown property 'column-count'.  Declaration dropped.
Source file: http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=2678400
Line: 33

An error, cross-browser compatibility issue, or typo? haz (talk) e 20:23, 6 December 2006 (UTC)

This has been discussed at MediaWiki talk:Common.css/Archive 2#references-2column class breaks Firefox and MediaWiki talk:Common.css/Archive 3#Minor non-compat bug. I believe it was left as is as a "harmless" compatibility issue. Mike Dillon 21:35, 6 December 2006 (UTC)

Messagebox tables require inline styles

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?

.messagebox table {
  width:100%;
  background:none;
}

Which would eliminate that inline styling. -- PatrickFisher 00:38, 8 December 2006 (UTC)

I've just removed such a 100% from Template:Unreferenced which solved this problem posted at Template talk:Unreferenced#Layout problem with Infoboxes. So I wonder if this is a good idea. --Ligulem 13:12, 17 December 2006 (UTC)

CSS errors

Did the admins forget to check for validation errors after the last couple of changes? It seems that this style sheet no longer validates. function msikma(user:UserPage, talk:TalkPage):Void 09:56, 17 December 2006 (UTC)

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). —Ruud 13:24, 17 December 2006 (UTC)

The advanced interface can be used to validate it with a CSS3 profile. —Michael Z. 2006-12-17 19:26 Z

Nice. It still chokes on -moz-column-count:2, though? —Ruud 20:54, 17 December 2006 (UTC)

Seems to be a bug in the validator, which has already been fixed in the CVS version. —Ruud 21:01, 17 December 2006 (UTC)

.references-small -> 92%

Does anyone object to increasing the font-size of .references-small to 92%? The references are significantly smaller on Firefox than on IE (also see Image:Footnotes90from"Alexander Litvinenko poisoning".png) and some users find them too small. —Ruud 19:08, 18 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.... :] --Ligulem 23:09, 18 December 2006 (UTC)

85%	Lorem ipsum dolor sit amet, consectetur adipisicing 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 adipisicing 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 adipisicing 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 adipisicing 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 adipisicing 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 adipisicing 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.

--ChoChoPK (球球PK) (talk | contrib) 19:47, 18 December 2006 (UTC)

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 adipisicing 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 adipisicing 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 adipisicing 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 adipisicing 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.

--ChoChoPK (球球PK) (talk | contrib) 20:02, 18 December 2006 (UTC)

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)

So 91% and 90% are the same in both browsers. My opinion above is holds. --ChoChoPK (球球PK) (talk | contrib) 21:37, 18 December 2006 (UTC)

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. function msikma(user:UserPage, talk:TalkPage):Void 11: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%. Gimmetrow 21: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. function msikma(user:UserPage, talk:TalkPage):Void 22: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. Gimmetrow 23: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)

geography infobox style

There are 3 types of rows

.infobox.geography .mergedtoprow td,
.infobox.geography .mergedtoprow th {
   border-top: solid 1px #ccd2d9;
   padding: 0.4em 0.2em 0.2em 0.8em;
/* top 0.4, bottom 0.2 */
}

.infobox.geography .mergedrow td,
.infobox.geography .mergedrow th {
      border: 0;
      padding: 0 0.2em 0.2em 0.8em;
/* top 0, bottom 0.2 */
}

.infobox.geography .mergedbottomrow td,
.infobox.geography .mergedbottomrow th {
   border-top: 0;
   border-bottom: solid 1px #ccd2d9;
   padding: 0 0.2em 0.4em 0.8em;
/* top 0, bottom 0.4 */
}

{{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

{{#if:{{{leader_title3<includeonly>|</includeonly>}}}|
<!--then:-->class="mergedrow"|
<!--else:-->class="mergedbottomrow"}}
print leader 2

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:

1. write style="padding: 0 0.2em 0.4em 0.8em;" for many many rows in my infobox
2. 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.

What do you think? --ChoChoPK (球球PK) (talk | contrib) 03:04, 21 December 2006 (UTC)

We should not be writing specific infobox classes, and definitely not overriding the colour. Can't you just use the mergedrows class? ed g2s • talk 17: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 Dickman ^talk 22: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 • talk 04: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. --Ligulem 23:43, 24 December 2006 (UTC)

I concur. Thank you, Ligulem. --ChoChoPK (球球PK) (talk | contrib) 03:01, 25 December 2006 (UTC)

Was there much discussion before adding them? We shouldn't be creating new classes for each type of infobox. ed g2s • talk 03:04, 25 December 2006 (UTC)

Discussion, such as it was, is archived at MediaWiki talk:Common.css/Archive 2#New infobox styles. -- Rick Block (talk) 16:25, 26 December 2006 (UTC)

As my correspondence above, it's also used by {{Infobox Currency}} and will be deployed to {{Infobox central bank}}. And User:Ligulem pointed out that geography class is used by {{Infobox city}}. Isn't this enough to justify a class? --ChoChoPK (球球PK) (talk | contrib) 03:14, 25 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). --Ligulem 09: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)

1. The class itself has nothing to do with geography, if we need another type of general purpose infobox, give it a proper name.
2. The colours do not need to be changed. If they do then propose a change to the infobox class at monobook.css.
3. Same goes for the cellpadding.

   ed g2s • talk 15:25, 25 December 2006 (UTC)

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? --Ligulem 16: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 • talk 20: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? --Ligulem 23: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)

Forgot to say: under any circumstance, changing a common class that has a huge impact without discussing is ill-advised. --ChoChoPK (球球PK) (talk | contrib) 00:55, 26 December 2006 (UTC)

A possibly incomplete list of templates using this style can be found with this search. -- Rick Block (talk) 16:06, 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. —MJCdetroit 21: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:

1. How it differs from the normal infobox.
2. Which of those differences we actually need.
3. What the class should be called, and when it should be used.

ed g2s • talk 01:49, 27 December 2006 (UTC)

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. --Ligulem 12: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)

...And that's why I used it in my post as well :-). --Ligulem 17:00, 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... it is a problem in IE6. If it weren't, the style can be CSS-fied, right? --ChoChoPK (球球PK) (talk | contrib) 22:21, 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 • talk 18: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? --Ligulem 00: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. --Ligulem 00: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. --Ligulem 00:14, 29 December 2006 (UTC)

“Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.” —Antoine de Saint-Exupéry —The preceding unsigned comment was added by R. Koot (talk • contribs) 00:47, 29 December 2006 (UTC).

"La vérité de demain se nourrit de l'erreur d'hier." —Antoine de Saint-Exupéry

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 • talk 04: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)

Useless link in printout fixed

Right Id names #privacy, #about, #disclaimer was fixed in revision 18763, so this can be removed from common.css . --Li-sung 09:13, 2 January 2007 (UTC)

Font size of message box standard-talk

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)

Where are the ones that are a problem? —Centrx→talk • 03:39, 1 January 2007 (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)

Okay, I changed that to use the regular messagebox class. Any other templates? —Centrx→talk • 00:47, 4 January 2007 (UTC)

NavFrame styles

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.

See the new information on Wikipedia:NavFrame for examples.

So, any thoughts? ♠ SG →Talk 20:34, 28 December 2006 (UTC)

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. —Down10 ^TACO 22:35, 8 January 2007 (UTC)

PDF icons

Can we revert this? The new generic blue document icons don't convey PDFness; they just convey non-HTMLness. — Omegatron 21:45, 29 December 2006 (UTC)

Definitely. I "undo"ed it. —Mets501 (talk) 21:51, 29 December 2006 (UTC)

I believe there are fair use issues here. You can't just randomly use Adobe's trademarked logo in this context. Mike Dillon 21:55, 29 December 2006 (UTC)

Is it trademarked by Adobe, though? —Mets501 (talk) 22:09, 29 December 2006 (UTC)

Yes. I don't see how that means it can be used every time someone links to a PDF. Mike Dillon 22:14, 29 December 2006 (UTC)

No. The icon is public domain.

Even if it used Adobe's copyrighted icons, which it doesn't, those are still licensed for this use.[9] — Omegatron 22:19, 29 December 2006 (UTC)

Good point. I just removed it, but should I put it back again? —Mets501 (talk) 22:21, 29 December 2006 (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 Dillon 22: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. — Omegatron 03: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 Dillon 05:31, 30 December 2006 (UTC)

Those guidelines only apply to the icon provided by Adobe and not our free replacement. —Ruud 22:28, 29 December 2006 (UTC)

Here are some other trademark guidelines. —Ruud 22:30, 29 December 2006 (UTC)

The coloured icons are much too visible, can someone please create an icon that is both blue and PDF-ish? —Ruud 22:13, 29 December 2006 (UTC)

I think they are just right. — Omegatron 03:20, 30 December 2006 (UTC)

{{US Patent}} which used a hack to provide a PDF icon for a PDF conversion service is broken. Could somebody please fix this? --Dispenser 23:10, 30 December 2006 (UTC)

Also, {{PDFlink}} is broken. As the icon only shows up when the extension is .pdf.

Fixed. — Omegatron 19:13, 9 January 2007 (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 (Image:Crystal Clear app acroread.png). Same for pretty much any Linux distribution or other Free software that features a file browser. — Omegatron 02:10, 10 January 2007 (UTC)

"Hello link spammer"

I can't seem to add this to my own wiki without receiving a message that says that I'm a "link spammer" or something. What's going on and can anyone help? Sana Jisushi 00:53, 16 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 Dillon 01: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:

.editscreenmsg {margin: 0 0 1em; padding: .5em 1em; vertical-align: middle; border: solid #aaaaaa 1px}

(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)

Isn't this what .standard-talk is for? —Simetrical (talk • contribs) 02:31, 8 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)

This proposal, per the policy at this page, is currently at the village pump. See Wikipedia:Village pump (technical)#Protected edit request. If you have any questions, please contact me at my talk page. Ian Manka 04:05, 3 January 2007 (UTC)

The discussion has now been archived: [10]. Could we have a done/not done for my and/or Simetrical's suggestion? --ais523 13:26, 17 January 2007 (UTC)

Not done. Please decide which you wish made. Proto::► 18:21, 5 February 2007 (UTC)

Highlight the clicked reference

From meta:Talk:Cite/Cite.php#Stylesheet_improvements_for_modern_browsers

Adding

ol.references > li:target {
 background-color: #DEF;
}

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. — Omegatron 22:26, 10 January 2007 (UTC)

I love it! I'll wait for a bit more input before adding it. —Mets501 (talk) 15:18, 13 January 2007 (UTC)

I'm just going to add it. There probably won't even be any comments then. — Omegatron 15:08, 16 January 2007 (UTC)

Cool! Lupo 08:49, 17 January 2007 (UTC)

... and if there are, they'll be good ones. :-) — Omegatron 16:38, 17 January 2007 (UTC)

Neat, thanks. HighInBC ^{(Need help? Ask me)} 16:26, 23 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)

You can't just make it blue background also? — Omegatron 19:53, 11 February 2007 (UTC)

Done. —Quarl ^(talk) 2007-03-16 09:18Z