MediaWiki talk:Common.css

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

This talk page exists for a reason

Guys, you really really should test your CSS and discuss it here first.

• Site-wide CSS that affects millions of viewers for up to 30 days is not a sandbox.
• Don't even make small changes without some discussion, you can fuck things up dramatically.
• Don't even change comments without discussion, you'd be surprised what can break.

--Splarka (rant) 22:50, 10 January 2009 (UTC)

Agreed. I admit I have made un-discussed changes in the past, but after a few incidents, I've learned what Splarka says is true: even minor changes can break the site. And cache is a bitch. I've reverted Happy-melon's changes, which from the outside seems kinda dickish, but we really do need to be careful with the site-wide JS / CSS. --MZMcBride (talk) 22:57, 10 January 2009 (UTC)

I accept and fully support the premise that A) changes that have a visible effect or change functionality should be discussed, B) that changes that don't gain immediate unanimous support should be reverted and discussed (and readding reverted code is strictly taboo), and C) that we need to be extra extra careful with CSS and JS. However, I don't think I can agree with MZ's conclusion that any change, no matter how trivial, should be discussed. And I think we can agree that, as edits to Common.css go, this is pretty trivial :D. Of course that was not my only edit, and it was in response to me screwing up my first addition by using the wrong comment syntax (reverted within a few seconds). But that last edit was an attempt to learn from past mistakes in the true wiki fashion.

I think some balance is needed here, between maintaining code integrity and avoiding unnecessary bureaucracy. I think that saying "discuss every possible change before making it" falls on the wrong side of that line. My philosophy remains "discuss changes in functionality, test all changes rigorously, and revert&discuss all changes on the slightest request". So in line with that, now MZ has reverted: does anyone object to the changes I made here and to Common.js to skin and dynamically style the show/hide buttons? Happy‑melon 14:49, 11 January 2009 (UTC)

I disagree with the comment that these lines of code should be removed in two thousand eight, but apart from that, I'm fine with them. However, I think you should've put the real code on the talk page for a few days before adding it—multiple pairs of eyes see more than just one. —Ms2ger (talk) 15:29, 11 January 2009 (UTC)

No objection from me. I agree that trivial edits like bugfixes, comment edits and minor styling changes shouldn't go through red tape. Anything else should be posted fro review first. — Edokter • Talk • 15:32, 11 January 2009 (UTC)

Best practices for editing these pages?

I finally took the time to put words on a page vis how I see our Best Practices in editing system messages, particularly the skin files: WP:EI. I don't think we need anything as pretentious as a policy or guideline to control how we work on these files, but it would be nice to have something to point to to ensure we're all reading from the same song sheet. Comments and criticisms would be very welcome. Happy‑melon 23:06, 11 January 2009 (UTC)

WP1.0 quality assessment colours

I now know why the first attempt to add the WP1.0 assessment scheme colourings (as used by {{FA-Class}}, {{Category-Class}}, etc) didn't work: the CSS specificity of the wikitable declarations overwrote the puny ".assess-fa" declarations. Now I've fixed and tested the declarations with the ".mediawiki" qualifier; they should sit in the correct place in the hierarchy now.

/* Skinnable CSS for assessment grades */
.mediawiki .assess-fa       { background: #6699FF; }
.mediawiki .assess-fl       { background: #6699FF; }
.mediawiki .assess-a        { background: #66FFFF; }
.mediawiki .assess-ga       { background: #66FF66; }
.mediawiki .assess-b        { background: #B2FF66; }
.mediawiki .assess-c        { background: #FFFF66; }
.mediawiki .assess-start    { background: #FFAA66; }
.mediawiki .assess-stub     { background: #FF6666; }
.mediawiki .assess-list     { background: #AA88FF; }
.mediawiki .assess-na       { background: #F5F5F5; }
.mediawiki .assess-         { background: transparent; }
 
.mediawiki .assess-category { background: #FFA500; }
.mediawiki .assess-disambig { background: #00FA9A; }
.mediawiki .assess-image    { background: #DDCCFF; }
.mediawiki .assess-portal   { background: #808080; }
.mediawiki .assess-project  { background: #C0C090; }
.mediawiki .assess-redirect { background: #C0C0C0; }
.mediawiki .assess-template { background: #FFCCFF; }
 
.mediawiki .import-top  { background: #FF00FF; }
.mediawiki .import-high { background: #FF88FF; }
.mediawiki .import-mid  { background: #FFCCFF; }
.mediawiki .import-low  { background: #FFEEFF; }
.mediawiki .import-na   { background: #F5F5F5; }
.mediawiki .import-     { background: transparent; }

As well as providing increased skinnability, this will allow us to get rid of Bad Things like {{FA-Class col}}, resolve problems like this and allow us to move towards a clean and low-overhead way of implementing these assessments without such a plethora of templates. Happy‑melon 10:28, 14 January 2009 (UTC)

It looks good to me, it would be nice to see all those *-class (tl|col|whatever) templates deprecated and (eventually) removed. AFAIK, they aren't properly documented anywhere, their usage is generally unclear, and it's not even clear how many of them there are. Adding these styles would allow us to eliminate all but one template for each assessment and importance grade, and that one remaining template would be a preformatted, prelinked cell for project banners to use. 「ダイノガイ千？！」^{(Dinoguy1000)} 22:54, 14 January 2009 (UTC)

 Done. Plenty of time for more discussion while the decaching time runs. Happy‑melon 00:52, 18 January 2009 (UTC)

The eternal hunt for deprecated classes continues

Spent a happy evening today going through looking for deprecated classes. Found quite a few that are either unused or close to it; comments appreciated on the possibility of removing each of these. Happy‑melon 23:13, 13 January 2009 (UTC)

.same-bg { background: none; }

Was implemented way back in 2006, but only ever managed to find its way into one article, and was redundant there. Its only other appearances are in people's monobooks (why people feel the need to copy the entirety of common.css into their personal skin files is something that I will never understand :D). Happy‑melon 23:13, 13 January 2009 (UTC)

I don't really see the point of this one. No objection to removal. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

 Done Happy‑melon 21:41, 21 January 2009 (UTC)

.prettytable

There are only 500 uses of class="prettytable" remaining 'in the wild'. Should we make the final jump to replacing it throughout and removing the duplicate declarations? Happy‑melon 23:13, 13 January 2009 (UTC)

I think this is our oldest "deprecated" class. The time might be right to start removing it for good. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

I realised, that in OpenOffice.org 3.0 export filter to mediaWiki syntax is .prettytable still used. I'm not sure what to do with that, but if it is deprectated, maybe someone shall tell them. (please forget my bad english :-)) Multimotyl (talk) 23:26, 20 January 2009 (UTC)

I support removing this. Even today it's not going to work outside Wikipedia, so if OpenOffice is using it in their MediaWiki exporter then that's a bug in OpenOffice. —Remember the dot ^(talk) 21:08, 21 January 2009 (UTC)

This is one where you would have to ensure it's not being used anywhere. I imagine it's still hardcoded into quite a few pages. --MZMcBride (talk) 21:54, 25 January 2009 (UTC)

There are 5,151 instances of prettytable in the October 2008 database dump. —Remember the dot ^(talk) 20:32, 27 January 2009 (UTC)

Is that only in articlespace ? --TheDJ (talk • contribs) 21:06, 27 January 2009 (UTC)

Yeah. Good point, there may be more instances in other namespaces. —Remember the dot ^(talk) 21:53, 27 January 2009 (UTC)

Maybe add this to AWB's autofixes? Can there ever be a valid reason to use the phrase "prettytable" on a page? Happy‑melon 22:25, 27 January 2009 (UTC)

Adding any of these cleanups to AWB seems to be a good idea. --—— Gadget850 (Ed) ^talk - 23:11, 27 January 2009 (UTC)

.infobox.standard-talk

I mean really, WTF? Added April 2008; I can see how it makes a certain amount of academic sense, but it's unused and thoroughly deprecated. Happy‑melon 23:13, 13 January 2009 (UTC)

Not so sure here. But likely won't hurt. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

 Done Happy‑melon 21:41, 21 January 2009 (UTC)

This was not unused (as I would have explained if anyone had asked me), and I just came here upon noticing that Template:Main Page toolbox's namespace-dependent coloring was broken. Can someone kindly point me to the technique that this has been deprecated in favor of (so that I can repair the template)? Thanks. —David Levy 21:51, 25 January 2009 (UTC)

Of course, I don't know whether any other pages depend on this class, as the mechanism used to check evidently doesn't find instances in which the complete text ".infobox.standard-talk" is interrupted by conditional code. (In this case, the class is defined as "infobox {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|standard-talk}} bordered".) —David Levy 21:57/22:00, 25 January 2009 (UTC)

Restored. We are allowed to make honest mistakes, you know, and it's not exactly as if this change was rushed through. The "standard-talk" system is deprecated; there is no replacement because no one thought that infoboxes had any use outside the mainspace. I can't really see the connection myself: how is the main page toolbox semantically an infobox? Happy‑melon 22:08, 25 January 2009 (UTC)

Oh, of course people make honest mistakes (and I've made much worse ones myself). I'm sorry if I came across as rude, which certainly wasn't my intention.

I wasn't being sarcastic when I requested "the technique that this has been deprecated in favor of." I sincerely assumed that there was one (which is why I didn't restore the class myself).

This is not an area of expertise for me, so I have no idea why that template semantically should or shouldn't be an infobox; that's just what it was when I found it. If there's a better way to achieve the desired layout, I'm all for it. —David Levy 22:23, 25 January 2009 (UTC)

Me too :D. As I say, I never really thought that the classes would have any use; the search merely confirmed my belief. I can't really see why the toolbox template can't be a simple wikitable; you could add the coffeeroll colours manually if you wanted it to match the talk namespace styles. Certainly there isn't any real nead to use the infobox classes. Happy‑melon 22:52, 25 January 2009 (UTC)

div.videolist, div.multivideolist

Template:Video is gone, and it wasn't using these nasty unclickable background images anyway by the end. .listenlist will eventually go the same way now that {{listen}} has been updated, but there are still a lot of transclusions of {{multi-listen start}} to clean out first. Happy‑melon 23:13, 13 January 2009 (UTC)

.hiddenStructure

Iff Template:Bug is resolved favourably, we can polish this off in the same way as prettytable. Happy‑melon 23:13, 13 January 2009 (UTC)

Not 100% sure on this. Probably from a Talk page point of view, this class might still be useful for reading trough history and stuff. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

.Boxmerge

Added in December 2006, never made it further from de.wiki than here. Found a description of what it was supposed to do here; regardless of intent, it's completely unused here except in people's monobooks again. Happy‑melon 23:13, 13 January 2009 (UTC)

Let it be gone. :D --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

 Done Happy‑melon 21:41, 21 January 2009 (UTC)

.references-2column

Deprecated since November 2006, doesn't appear to be used any more. —Remember the dot ^(talk) 21:14, 21 January 2009 (UTC)

It is still in use on some pages. You can't find them through the mediawiki search engine. You would probably need to search the database dumps. --- RockMFR 17:19, 26 January 2009 (UTC)

How do you know it's still in use then? How many pages are left that use it? —Remember the dot ^(talk) 17:54, 26 January 2009 (UTC)

RockMFR is right: you have to search through a dump. If it is still used, then it is probably time to update them to {{reflist}}. While we are looking at this, is ol.references still in use? This was added to make the references 90%, then changed to 100%. Then .references-small was added to use with reflist. The problem is that ol.references appears to override .references-small when using IE. --—— Gadget850 (Ed) ^talk - 19:23, 26 January 2009 (UTC)

Okay, how do I search through a dump? And yes, all instances of this class need to be converted to {{reflist|2}} - removing the class would definitely provide an incentive to clean up any remaining stragglers. I think we may be overestimating the impact of removing the class - at worst, non-IE users would occasionally see a reference list in a single column instead of two. IE users would continue seeing only a single column as before. —Remember the dot ^(talk) 19:30, 26 January 2009 (UTC)

See Wikipedia:Database download --—— Gadget850 (Ed) ^talk - 19:48, 26 January 2009 (UTC)

I was hoping there was some way to search it without downloading the whole thing...4.1 GB is just barely within the realm of feasibility. —Remember the dot ^(talk) 19:56, 26 January 2009 (UTC)

I believe that there are some users who will perform requested searches on their own downloaded copies of the db dumps; however, I don't know who any of them are. 「ダイノガイ千？！」^{(Dinoguy1000)} 20:56, 26 January 2009 (UTC)

I'm downloading the current dump and will search it tomorrow. --—— Gadget850 (Ed) ^talk - 22:09, 26 January 2009 (UTC)

Thank you. I actually realized that I have a way to download the dump in less than 10 minutes, so I should be able to search it as well. —Remember the dot ^(talk) 02:55, 27 January 2009 (UTC)

I finished the search. As of October 2008, of our 2.7 million articles there were only 510 that still used references-2column. I'd say that's few enough that it's safe to remove the class. —Remember the dot ^(talk) 03:40, 27 January 2009 (UTC)

Great, although we should probably take the opportunity to clean them out. Does this mean we can now poke and prod you to check for any and all other database dump checks we want done? :D If so, put prettytable and the <cite> tag at the top of the list, please :D Happy‑melon 13:56, 27 January 2009 (UTC)

If you have a list of articles, I can run though them with AWB. Add them to User:Gadget850/Sandbox5. --—— Gadget850 (Ed) ^talk - 14:34, 27 January 2009 (UTC)

Request - thumb in Infobox

{{editprotected}} I sugest adding this:

/* Remove left and right border from thumbs inside .infobox */
.infobox div.thumb {
    border-left-style: none;
    border-right-style: none;
}

Thumbnails have coded border to have some margin from the text they float in:

div.tright {border-width:0.5em 0 0.8em 1.4em;}

But it does not look good in infoboxes (see Nikon D300).

Please forget my bad English. Multimotyl (talk) 01:17, 21 January 2009 (UTC)

Removing the border does not fix any alignment within an infobox. The standard practice is not to use thumbnailing in an infobox at all. This code fixes nothing in my opinion. — Edokter • Talk • 03:56, 21 January 2009 (UTC)

I tried it in my own early mediawiki project [1] and tested in major web browsers (MSIE, Firefox, Opera, Safari). Believe me, it works. The change i suggested is quite easy, safe and works well. Multimotyl (talk) 09:28, 21 January 2009 (UTC)

Your example still shows the border, but not the margin. Having tested your code here, the margin is not adjusted, and effectively shows no change. The margin is necessary to stay clear of text. Removing it here will cause surrounding text to stick to the thumbnail. While that may look better in an infobox, thumbnailing is intended to use in article text. Within a box, you should not use a thumbnail, but a seperate caption. So, I'm sorry, but this code will not be added. — Edokter • Talk • 15:31, 21 January 2009 (UTC)

Upon further review, removing the margin itself when embedded in an infobox may be a viable option, but that needs more discussion. I still feel thumbnails in an infobox is redundant. — Edokter • Talk • 15:36, 21 January 2009 (UTC)

It is border which is white so it looks like margin :-). Actualy I wasnt talking about margin property of CSS, but about border property which looks like margin. So maybe it seemed to you like I don't know, what I'm writing about. Thumbnail inside infobox may be redundant, but on the D300 example it seems useful to have a caption to describe the image. It shows not only the D300 itself, but also a lens. —Preceding unsigned comment added by Multimotyl (talk • contribs) 18:14, 21 January 2009 (UTC)

The border does not determine the space next to the thumbnail; you code does not do anything to remove that (it actually adds whitespace above and below the thumbnail). Really, the best thing to quickly fix it is to add a caption to the infobox. I'l add the code for you, so you can see the result. — Edokter • Talk • 19:39, 21 January 2009 (UTC)

Here's the result. — Edokter • Talk • 19:46, 21 January 2009 (UTC)

Hey, I was mistaken with something. I forgot, that there is also a MediaWiki:monobook.css Which removes the border (under /* Remove white border from thumbnails */ ) and puts a margin instead of them. It starts to get confusing :-). Thank you for your patience. I thought, that if there is border on my site so there is one on wipipedia too. And unfortunately I have Firebuged only my site. :-). —Preceding unsigned comment added by Multimotyl (talk • contribs) 20:32, 21 January 2009 (UTC)

Semi-protection edit notice

I'm not sure the notice showing the latest logged entry in the protection log when editing semi-protected pages is that useful. It's not that necessary to remind editors that a page is semi-protected whenever they edit it, or if it is, a simple note that the page is semi-protected and a link to the protection log may be better. Indeed, the latest logged entry is often an adjustment of the protection without specifics on why it is protected, or an addition of move-protection, or worst the logged entry due to a move. So when a semi-protected page is move-vandalized, whenever editing it, editors see a often highly offensive red link. Cenarium (Talk) 17:31, 24 January 2009 (UTC)

Proposal: shifting italics text slightly to the left

Mixing upright and roman text, as done in mathematical formulas, italicized titles at the end of parentheses, etc. looks ugly due to the shifting of italics text to the right, for example:

(g ∘ f)(0) = g(f(0))

... (meaning beef) ...

Some editors fix this by adding thin spaces or ad-hoc span-based formatting, but his could be fixed once for all and site-wide by adding a declaration such as i { margin-left: -0.1em; margin-right: 0.1em; }. The resulting output would look like:

(g ∘ f)(0) = g(f(0))

... (meaning beef) ...

What do you think? -- Army1987 – Deeds, not words. 20:46, 25 January 2009 (UTC)

What browser are you using? To me your psoposed change actually looks worse on FF3. Happy‑melon 21:23, 25 January 2009 (UTC)

Changing the behavior of <i> seems incredibly dangerous. --MZMcBride (talk) 21:53, 25 January 2009 (UTC)

The change is not noticable on small font sizes, and yes, messing with a browser's font handling is dangerous, possibly interfering with user's browser settings or Wikipedia's CSS. — Edokter • Talk • 23:34, 25 January 2009 (UTC)

I only see a difference in Opera if I enlarge everything by at least 200%. --Carnildo (talk) 03:09, 26 January 2009 (UTC)

On Ubuntu 8.04, it looks slightly better in Epiphany (2.22.2) and slightly worse in Firefox (3.2a1pre/20090124). Adding it (back) to your own monobook.css seems the best solution. —Ms2ger (talk) 16:12, 26 January 2009 (UTC)

I had to zoom +4 on FF3 to see the difference. If the real issue is with how formulas display, then a simple template would resolve the problem. Also see Help:Displaying a formula. --—— Gadget850 (Ed) ^talk - 19:18, 26 January 2009 (UTC)

Aligning columns

{{editprotected}}

Following a discussion in the village pump, I'd like to submit the following for inclusion in common.css. Using thies css declarations a user can left align the first column and centre the rest by adding class="col1-left col2-center" to the table class definition. It's primarily intended to be used with wikitables, but I can't see a reason to limit to to them.

(to be added just below the wikitable declarations)

/* a simple way of aligning table columsn */
.col1-left tbody td,
.col2-left tbody td+td,
.col3-left tbody td+td+td,
.col4-left tbody td+td+td+td,
.col5-left tbody td+td+td+td+td,
.col6-left tbody td+td+td+td+td+td,
.col7-left tbody td+td+td+td+td+td+td,
.col8-left tbody td+td+td+td+td+td+td+td,
.col9-left tbody td+td+td+td+td+td+td+td+td { text-align: left; }

.col1-center tbody td,
.col2-center tbody td+td,
.col3-center tbody td+td+td,
.col4-center tbody td+td+td+td,
.col5-center tbody td+td+td+td+td,
.col6-center tbody td+td+td+td+td+td,
.col7-center tbody td+td+td+td+td+td+td,
.col8-center tbody td+td+td+td+td+td+td+td,
.col9-center tbody td+td+td+td+td+td+td+td+td { text-align: center; }

.col1-right tbody td,
.col2-right tbody td+td,
.col3-right tbody td+td+td,
.col4-right tbody td+td+td+td,
.col5-right tbody td+td+td+td+td,
.col6-right tbody td+td+td+td+td+td,
.col7-right tbody td+td+td+td+td+td+td,
.col8-right tbody td+td+td+td+td+td+td+td,
.col9-right tbody td+td+td+td+td+td+td+td+td { text-align: right; }

It's not very elegant but don't knock it should work! — Blue-Haired Lawyer 12:21, 28 January 2009 (UTC)

I propose to use shorter names, like "left1", "center2", "right3", and to code like:

table.left1 tr td,
...
table.left9 tr td+td+td+td+td+td+td+td+td {text-align: left}

−Woodstone (talk) 14:12, 28 January 2009 (UTC)

Striked the editrequest. Enough admins follow this page, once we agree, it will be done.

Personally, I do see the appeal to this (my names would be col1-l col2-c col3-r btw. It's short and the meaning is quite clear). It looks like it could be useful and even though it is a lot of CSS, it does not seem too bad due to the high level of functionality it should bring. --TheDJ (talk • contribs) 15:05, 28 January 2009 (UTC)

My immediate reaction is "there's no way that's going to work on IE6" :D Can we have some browser-compatibility tests, please? Happy‑melon 19:34, 28 January 2009 (UTC)

You are right. Comparison of layout engines (Cascading Style Sheets) --TheDJ (talk • contribs) 20:47, 28 January 2009 (UTC)

I tested with success on Firefox, Safari and Google Chrome and failure on IE7. But I cannot see from the referred CSS comparison above why it should not work. −Woodstone (talk) 22:21, 28 January 2009 (UTC)

Because where they show the comparison for CSS selectors, it says "Trident 7.0 and up" (IE7) for the "Direct adjacent" selector (the +). --TheDJ (talk • contribs) 11:28, 29 January 2009 (UTC)

Yes, but I tested IE7 and that one did not work (same code is fine for the other 3 browsers). −Woodstone (talk) 18:23, 29 January 2009 (UTC)

It depends how you tested it. In certain situations, IE7 does not support CSS selectors. It's a very nice, completely undocumented bug. --- RockMFR 18:02, 30 January 2009 (UTC)

Clearly the use of "colspan" would create miscounts. −Woodstone (talk) 23:05, 28 January 2009 (UTC)

I'd still prefer .col1-left as I think it's more self explanatory and there's hardly a reason we need to economise on characters! I should have thought about ie7. I'll have a look at it and come back. — Blue-Haired Lawyer 23:27, 28 January 2009 (UTC)

Please test in all major versions of Opera. IIRC td+td can do Bad Things (tm) to some versions. Also this is very hacky and does't scale. Hate. --Splarka (rant) 08:17, 29 January 2009 (UTC)

found the relevant thingamabob. No idea what was going on there actually. Coulda been the white-space. --Splarka (rant) 08:36, 29 January 2009 (UTC)

Ah crap. I remember that one. Yes this would require a bit more extensive testing in this case. (BTW, i would not be surprised if ANY browser implementation that handles this would parse it rather slowly. It seems a prime candidate for inefficient implementation.) --TheDJ (talk • contribs) 11:26, 29 January 2009 (UTC)

Pre-emptive strike

thumb|right|300px|Yuck Looks like RevisionDelete is coming soon to a wiki near you, and not a moment too soon. This means that all us admins will soon be graced by a new line of links on history and log pages, as modeled by test.wiki to the right. By default they're in a monospace font, and so by default they look hideous :D. Fortunately, no one's noticed yet. I propose we add the code below to MediaWiki:Sysop.css to keep it that way.

span.mw-revdelundel-link,
stront.mw-revdelundel-link {
    font-family:inherit;
    font-size:inherit;
}

I recognise that this is very much an ILIKEIT/DONTLIKEIT change, and if it is rejected here I'll just stick it in my own monobook and have the results anyway. But this is also a fairly unique situation in that we have the opportunity to choose the nicest appearance for a feature that doesn't yet exist, so we have no assumption in favour of the status quo, because there is no status quo! Happy‑melon 23:24, 30 January 2009 (UTC)

From the silence here I assume no one really cares that much :D.  Done Happy‑melon 00:10, 3 February 2009 (UTC)

Not really... But I urge to hold of on any pre-emptive action until we actually experience this new feature. It's not very Wikipedia-like. — Edokter • Talk • 00:36, 3 February 2009 (UTC)

Ugly fonts for transliteration templates

Hello, please see Template talk:IAST#Font size and Template talk:Transl#Font for translated words: there is something going on that looks ugly, e.g. using {{IAST|Pañcatantra}} gives Pañcatantra which is not the same font as simply typing Pañcatantra. Is this a browser bug? Can it be fixed with common.css? Can someone explain? Thanks, Shreevatsa (talk) 22:18, 31 January 2009 (UTC)

Using FF3's web developer kit, I can unload every CSS rule set by MediaWiki, and the text is still in a different font. So this is definitely a browser issue. Happy‑melon 22:25, 31 January 2009 (UTC)

More specifically, using <span lang="sa-Latn">Pañcatantra</span> gives the different font as before: Pañcatantra. I don't get this when I try the same HTML on non-Wikipedia (non-Mediawiki) pages. So it seems specific to the Mediawiki CSS, actually... and even if it's not, would it be possible to change the Mediawiki CSS to force the text to appear in the same font? Shreevatsa (talk) 22:31, 31 January 2009 (UTC)

I'm not sure I agree; WebDeveloper can also trace the source of any CSS styles applied to individual elements, and while it correctly identifies the MediaWiki stylesheets used to style the rest of the page, it politely informs me that no styles are being applied to that span by this site. On the other hand, even disabling all styling, including the browser defaults, still leaves the difference in place, so I really don't know what's going on. Happy‑melon 23:30, 31 January 2009 (UTC)

(I apologize for changing my comment repeatedly.)

I agree now that it seems to be a browser bug (this one).

Here are spans in a few languages: normal en-Latn sa-Latn ar-Latn el-Latn ru-Latn

Each of the last four appears in a different font from normal. However, if I disable http://en.wikipedia.org/skins-1.5/monobook/main.css?203xx (or disable all styles) it fixes the problem for me for sa-Latn and somewhat for ar-Latn (but not for the other two). (So although it ought to be fixed in the browser, there might still be scope to change the above-mentioned CSS file to improve the situation with sa-Latn, at least.) Shreevatsa (talk) 03:02, 1 February 2009 (UTC)