MediaWiki talk:Common.css

From Wikipedia, the free encyclopedia

This talk page is automatically archived by Werdnabot. Any sections older than 31 days are automatically archived to MediaWiki talk:Common.css/Archive 3. Sections without timestamps are not archived.

This is the common CSS for all the skins. Use it only for styling things within the content area (stub notices, message boxes, spoiler/disambiguation messages, etc). The following stylesheets call this one: MediaWiki:Amethyst.css (Amethyst) MediaWiki:Chick.css (Chick) MediaWiki:Standard.css (Classic) MediaWiki:Cologneblue.css (Cologne Blue) MediaWiki:Monobook.css (MonoBook) MediaWiki:Myskin.css (MySkin) MediaWiki:Nostalgia.css (Nostalgia) MediaWiki:Simple.css (Simple)

edit

Archives

July 2005 – December 2005 January 2006 – August 2006 September 2006 –

Contents 1 hiddenStructure again 2 metadata 3 Copied from WP:VP/T 4 Hiding links with new .admin class 5 Class for inline list 6 span.texhtml 7 CSS Class for Mini-talk-page templates 7.1 Implementation 8 Improving template code 8.1 Classes instead of id's 8.2 Divs instead of layout tables 8.3 Other templates 9 Navbox width 10 Rollback

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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: [1]. 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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 [2] 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)

[edit] 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

[edit] 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

[edit] 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)

[edit] Other templates

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

[edit] 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)

[edit] 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)