MediaWiki talk:Common.css/Archive 2#CSS for metadata

Per my Village Pump proposal, I'm going to be adding a bit of CSS to enable the creation of metadata (ala [http://de.wikipedia.org/wiki/Wikipedia:Personendaten Personendaten] in the German Wikipedia). This will allow us to try out some metadata schemes and hopefully implement some in the future. See [http://en.wikibooks.org/wiki/Wikimania05/Paper-JV2 this article] for more info. Kaldari 19:27, 22 December 2005 (UTC)

:BTW, if anyone's interested, I've set up the first metadata project at Wikipedia:Persondata. It's gotten a lot of positive feedback so far. Kaldari 19:56, 2 January 2006 (UTC)

See Template talk:Dynamic navigation box. Monobook contains the code missing in other CSS. -- User:Docu

: I disagree with this change completely. You're using a template to perform a function which really should be added as a software feature. Templates should be used to replicate text among article, not change the fundamental navigation structure outside of the article body. -- Netoholic @ 19:31, 2 January 2006 (UTC)

::That's nice. But a lot of templates are used as navigational aids (navboxes, etc). See for example, {{Street Fighter series}}. That the necessary code to make the show/hide buttons work isn't available in the other skins is something that should be rectified. —Locke Cole • t • c 19:42, 2 January 2006 (UTC)

Hiding and showing content is something that should be requested as a built-in to the software, where the Javascript code (currently in MediaWiki:monobook.js can be put through proper development practices, like CVS. -- Netoholic @ 20:01, 2 January 2006 (UTC)

I have restored the specifications for the date display templates which got removed for no reason explained in the Edit Summary.

If this was a purposeful removal, then could whoever does it explain it here before doing it again, please?

HTH HAND —Phil | Talk 08:16, 5 January 2006 (UTC)

As reported on [http://en.wikipedia.org/w/index.php?title=Wikipedia:Village%20pump%20%28technical%29&oldid=35818871#Bug_in_Monobook.2Ecss Wikipedia:Village pump (technical)#Bug in Monobook.css] there appear to be two errors in Common.css:

:Unknown property 'filter'.

:Error in parsing value for property 'line-height'.

Also, this may be completely unrelated, but my Firefox fails to display certain images while IE is able to display them (cache cleared, control-shift-R tricks all tried in vain):

• :Image:Reflection_nebula_IC_349_near_Merope.jpg [http://en.wikipedia.org/wiki/Image:Reflection_nebula_IC_349_near_Merope.jpg]
• :Image:Reflection_nebula_IC_349_near_Merope_full.jpg [http://en.wikipedia.org/wiki/Image:Reflection_nebula_IC_349_near_Merope_full.jpg]

Most other images are fine, and IE seems Ok with these. -Wikibob 03:54, 13 January 2006 (UTC)

:Both errors were from the experimental main page stuff. I went ahead and changed the line-height:auto since it wasn't valid CSS. The filter thing is an IE only special deal. Should we keep it or scrap it? Kaldari 04:19, 13 January 2006 (UTC)

:As for the images, check if you aren't using a misconfigured ad blocker. The first one has /ad/ on its URL, which is often indiscriminately blocked. --cesarb 04:51, 15 January 2006 (UTC)

:Yes, the IE filter thing keeps popping up in my js console. Can you hide it from non-IE browsers? Apparently [http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_User_scripts/Scripts/Fix_diff_width&diff=35538146&oldid=35066620 this recalc thing] does it? — Omegatron 01:48, 18 January 2006 (UTC)

(conversation moved to Wikipedia talk:HiddenStructure#CSS hack reduces accessibility) -- Netoholic @ 15:28, 27 January 2006 (UTC)

(conversation moved to Wikipedia talk:HiddenStructure#Why Not Weeble?) -- Netoholic @ 15:29, 27 January 2006 (UTC)

(conversation moved/archived to Wikipedia talk:HiddenStructure#Change request) -- Netoholic @ 15:33, 27 January 2006 (UTC)

There are uses for tables of images inside frames, but [http://bugzilla.wikipedia.org/show_bug.cgi?id=1729 the css doesn't work with them], since it puts a border around every image instead of around the table as a whole. {{Float begin}} handles this in a kludgy way, but better ones would be nice. One possible solution is to add:

div.thumb div table a img {
border: 0;
}
div.thumb div table {
border: 1px solid #ccc;
}

Then I would modify float_begin to use the code in the above example. This will remove the border around images inside tables inside thumbnail frames and put the border around the table instead. There are other solutions, I'm sure, like using a div with a border so that you can [http://en.wikipedia.org/w/index.php?title=Template_talk:Float_begin&diff=11526204&oldid=11525768 put anything inside a frame], instead of just tables, but this would work for now. Can it be added? Are there any conflicts? — Omegatron 18:18, 20 January 2006 (UTC)

: I don't see where this is necessary enough to make a site-wide change to some pretty widely used CSS classes. It could cause conflicts later. You could either combine the smaller images into a larger one, or just kludge it for the few occassions it seems to be used. [http://en.wikipedia.org/w/index.php?title=Capacitor&diff=35719415&oldid=35355259 Take this example], where I put the information into a table using no templates and very little styling. -- Netoholic @ 21:28, 20 January 2006 (UTC)

:: Your kludge is just as bad as the one currently in use. Adding to the css won't break anything and will provide a valid implementation.

:: Another alternative is to create a new div.framed or div.framedtable class instead of reusing in addition to the div.thumb class, if you're really worried about future css conflicts. — Omegatron 22:46, 20 January 2006 (UTC)

::: This is a big problem, and I support fixing it. Articles about chess usually construct chess boards out of individual chess tiles in a table. It's virtually impossible to put such a chess board in a frame, with a caption below, and have it look exactly the same as a wiki image in a frame. I have the sense that the "right" way to solve the problem is to have MediaWiki produce somewhat different code, something like

::::

Image goes here

Caption goes here

:::The problem is that MediaWiki currently produces

::::

Image goes here
Caption here

:::The problem with that code is that the image itself isn't inside its own DIV, so that "thumb" class has to put a frame around every image it contains. Omegatron's proposal looks like a good temporary workaround, but eventually we should get MediaWiki to just make good HTML code. dbenbenn | talk 22:05, 26 January 2006 (UTC)

::::Yeah, it's only used "on a few occasions", like {{Chess diagram}} (36 instances), {{Chess position}} (17 instances), {{Football club infobox}} (454 instances), {{National football team}} (56 instances), {{Football kit box}}, ... Those are all tables of images that want to be inside a frame.

::::Agreed that mediawiki should be fixed. bugzilla:1729 is close. — Omegatron 14:43, 28 January 2006 (UTC)

:::: Biology has another example. — Omegatron 15:37, 5 February 2006 (UTC)

Is anyone opposed to this code? — Omegatron 02:24, 1 March 2006 (UTC)

(conversation moved/archived to Wikipedia talk:HiddenStructure#CSS hack reduces accessibility, confirmed) -- Netoholic @ 15:34, 27 January 2006 (UTC)

Ok, this is what the Freedom Scientific site says about CSS with earlier versions of jaws. Feel free to refactor this if necessary. This applies to jaws 5.1 and earlier. For the whole web page, see [http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=565]. Refreshing with insert+escape shortcut mentioned did not work on wikipedia. I have found out that diff links will also display better in later versions of jaws, so I, personally, will upgrade.

The text is as follows:

Q. Does JAWS support cascading style sheets (CSS)?

A. Yes, JAWS does support cascading style sheets (CSS). CSS is a way of marking up text using styles that are inherited by applying a set of style rules

to a page without having to change the actual page content. For example, you can link an HTML document to a style sheet that displays all level one headings

in red. There are some issues that authors of Web pages should be aware of when using CSS to ensure the page is accessible.

When a page loads and JAWS processes the HTML code, it also processes linked and inline style information to determine which elements should be rendered.

Any elements that use a style with the attributes "visibility:hidden" or "display:none" are not included in the JAWS rendering of the page. However, if

the page has elements shown when it first loads, but then dynamically hides these elements without user intervention after the page loads, JAWS does not

detect that this has occurred and may still show the hidden content. Conversely, if a page hides content when it first loads but then dynamically shows

this content after the page loads, JAWS does not announce the new content.

The safest course of action when developing Web pages is to hide anything in the HTML when the page first loads that should not be shown. Then, only hide

or display content when the user interacts with the page (such as by clicking a link or item with the onClick attribute). When the user clicks text, links,

images, and so on, JAWS asks Internet Explorer for the HTML again, and updates the page.

A JAWS user can press INSERT+ESC to refresh the page content in the virtual document. However, the source that is passed to JAWS by Internet Explorer should

represent the current visible state of the page. This does not occur if the HTML source code does not reflect the true visibility status because of scripting.

If that is the case, JAWS still does not have an accurate view of the document.

JAWS uses style information to try to determine the font name, font size, font attributes, colors, and text alignment. This information is provided to the

user when he or she presses INSERT+F.

Other than visibility and text attributes, style information is not interpreted any further. JAWS does not indicate zIndex levels.

--—The preceding unsigned comment was added by Pianoman87 (talk • contribs) 10:03, 23 January 2006.

: Thank you for the information, and it's good to hear that the CSS hiddenStructure method does work with the most commonly-used screen reader. The method was originally used on Infobox templates only, where hiding a few rows which didn't have data was a convenience. For other uses of conditionally displaying information, as a group, we need to be smarter about developing good, simple solutions rather than "clever" ones. -- Netoholic @ 11:38, 23 January 2006 (UTC)

Please note that screen readers and other web browsers are not required to use CSS at all, and other ones may very well ignore it. Also note that main.css is loaded by a style element containing the attribute media="screen,projection", so it should be ignored by screen readers, and consequently the CSS cascade will be different for screen readers which respect the media attribute.

The gist of this is that we can't possibly know how every single browser, screen reader, and search engine will process pages. Therefore, we should follow HTML and CSS standards, accessibility guidelines, and good authoring practices, and not just ignore or pay lip service to them. —Michael Z. 2006-01-23 15:10 Z

: Quite interesting. Sounds like we need someone knowledgable on the subject to make a request to the developers to provide a way for editors to make changes to non-visual CSS. -- Netoholic @ 15:37, 23 January 2006 (UTC)

:: For what purpose? If we follow basic good practice for accessibility in page content, that is, generate good HTML in the body, then we are probably 90 to 99 percent of the way there (of course, Graham's input would be helpful). Sounds like the HTML for diffs and perhaps red links needs to be tweaked (see below), but that's for the MediaWiki developers, not for Wikipedia editors to fix. The basic style sheets for other media are also a feature of MediaWiki, not part of the encyclopedic content. —Michael Z. 2006-01-23 15:51 Z

I can now confirm that both common.css and monobook.css are ignored in jaws versions below 6.0. This has other implications besides conditional statements. For example it makes interpreting diffs and distinguishing red links more difficult, because even the colour check commands do not work. The only thing the jaws 6.0 new features has to say relating to this is that "JAWS also

features improved performance while you are reading complex Web sites." [http://www.freedomscientific.com/fs_products/software_jaws60fea.asp]

The FAQ for jaws 5.0 did say that css was supported, though.

What could be causing this, and is there any way to fix it? Or maybe this is just another reason to upgrade, along with the fact that Firefox is supported. That's another 350 dollars or so out the window ... Graham/pianoman87 talk 15:28, 23 January 2006 (UTC)

: Thanks for the input, Graham. Your advice would probably be useful at Wikipedia:Accessibility and WikiProject Usability. The diffs and red link problems are probably in the realm of WikiMedia developers' work; I think meta:Usability and meta:Usability group may be where this is discussed. Template development falls somewhere between editors and developers, and is definitely a place where accessibility may be broken across many pages at once.

: Is there any way that editors could improve accessibility in general? —Michael Z. 2006-01-23 15:59 Z

The best thing that editors can do to improve accessibility is to follow the recommendations in the manual of style, like creating good link descriptions (especially for external links, and not "click here!"). Also, heading titles should be descriptive, and in a consistent order: the order for the last few headings should be see also, references and external links, for example. When editing, never break up a line unless absolutely necessary, as the easiest way to edit with a screen reader is to navigate line by line. Also, use as little code as possible, so the text in the edit window is easier to read. My pet peeve is code like clocks instead of the perfectly correct code clocks, which takes up less space. Also, spelling and grammar errors can dramatically affect the sound of the text like "initative" instead of "initiative", which can make the text more difficult to read. The majority of my editing time is spent fixing spelling and grammar errors that affect the sound of the text in an article.

Images should contain a caption, and the caption should concisely describe any information contained in the image. Where possible, any charts or diagrams should have a text equivalent, or should be well-described so that users who can't see the image can gain some understanding of the concept.

The other things I can think of that should be avoided are very bad style, and I have not encountered them in any good articles. For example, having a heading title with the same name as one of the form names on the page, like "search" or "go". I've only seen two articles with this problem, and they both also required major cleanup.

Besides spelling and grammar errors, most well-developed wikipedia articles read well with jaws, at least for me. I think screen reader users need to be profficient in navigating the internet to get the most out of wikipedia, but that is true for every site. Graham/pianoman87 talk 03:55, 24 January 2006 (UTC)

: Thanks. Interesting that nearly all of this falls under simple good writing and tidy editing—helpful for a reader using any web browser. I think most "accessibility" practice just falls under simple usability.

: Should detailed descriptions of charts or diagrams go on their image page, or is it important to keep it all in the article? Regards. —Michael Z. 2006-01-25 05:35 Z

::Detailed image and chart descriptions should go on the image page, with text saying that activating the image link will lead to a more detailed description. I'll put a note on the main accessibility page saying that. Graham/pianoman87 talk 07:20, 25 January 2006 (UTC)

Please change

table.wikitable th, table.wikitable td,

table.prettytable th, table.prettytable td {

border: 1px #aaaaaa solid;

padding: 0.2em;

}

table.wikitable th,

table.prettytable th {

background: #f2f2f2;

text-align: center;

}

to

table.wikitable > tbody > tr > th, table.wikitable> tbody > tr > td,

table.prettytable > tbody > tr > th, table.prettytable > tbody > tr > td {

border: 1px #aaaaaa solid;

padding: 0.2em;

}

table.wikitable > tbody > tr > th,

table.prettytable > tbody > tr > th {

background: #f2f2f2;

text-align: center;

}

So nested tables doesn't inherit the formating. _→AzaToth 22:01, 27 January 2006 (UTC)

::Please try to rally some support, before requesting a change. If others agree your code is harmless and will help, this code should be added. But not before others have weighed in. Thank you. -- Ec5618 18:06, 30 January 2006 (UTC)

:::It's rather simple, if you have the wiki-code:

{|

|-
|
|}

:::The DOM will be:

table
|
|--tbody
|
|--tr
|  |
|  |--td
|    |
|    |--table
|       |
|       |--tbody
|          |
|          |--tr
|             |
|             |--td
|--tr
|
|--td

:::Normally you don't have nested tables, and in the situations you have such, there is not always you want to inherit the formation from wikitable to the nested table, if you want you can always define the nested table as a wikitable, otherwise you have to manually reset all the formating on all td:s. The most logically solution is to limit the formation of wikitable to not transend deeper to nested tables by limit it to defined child (table > tbody > tr > td etc...) _→AzaToth 19:20, 30 January 2006 (UTC)

::::My knowledge of CSS is limited I'm afraid. Can you please get someone to take a look at the code? I understand the problem, but not the cure you're proposing. I imagine this fix might break quite a few tables, as a lot of nested tables are currently defined only through inheritance. Is it not simpler to accept the inheritance and to redefine the variables for each sub-table? -- Ec5618 19:42, 30 January 2006 (UTC)

:::::No, that's impossible because you can't in the sub-table override class inheritance, you should be forced to do simlar to this:

class="wikitable"
{| style="border: 0; background-color: white; border-collapse: separate;"
style="border: 0; background-color: white; border-collapse: separate;"

!style="border: 0; background-color: white; border-collapse: separate;"|Header
style="border: 0; background-color: white; border-collapse: separate;"

|style="border: 0; background-color: white; border-collapse: separate;"|data etc...

|-
|
|}

:::::aslo you don't know what style a standard table looks like in all themes. _→AzaToth 19:59, 30 January 2006 (UTC)

:I agree that this should be done, but I don't understand the > code to know whether it will break anything. — Omegatron 21:42, 30 January 2006 (UTC)

::A B means B descendant of A, A > B means B child of A. _→AzaToth 22:10, 30 January 2006 (UTC)

::: I know it refers to descendants; I'm just saying I'm not qualified enough on the site css or how descendants work to know whether it will break anything. Someone else needs to chime in. — Omegatron 19:06, 31 January 2006 (UTC)

:::: I ran into this problem of inheritance in editing the article Bobsleigh. I tried to nest invisible tables to align decimal points in a wikitable, but inheritance broke the formatting.

:::: The formatting Azatoth suggests appears to be correct. See the W3C standard for .css formatting of child selectors [http://www.w3.org/TR/CSS21/selector.html#child-selectors here]. --Stormraven 14:29, 7 March 2006 (UTC)

::So, what would the effect be on nested tables, such as the ones on Help:Contents (the contents box consists of two nested tables), for example? And is the current code causing problems? -- Ec5618 09:25, 31 January 2006 (UTC)

::note. For clarification, on Help:Contents, the parent table sets the font-size to 160%. The child reduces it to 80% of that. Would your fix cause the child table to show the font at 80% of normal? -- Ec5618 09:29, 31 January 2006 (UTC)

::: That's not class="wikitable", though.

::: (And that visual formatting should be done with css, anyway; not a table.) — Omegatron 19:06, 31 January 2006 (UTC)

I'm can agree with a compromize, create a new rule .wikitable2 that are using my specification. _→AzaToth 09:06, 15 February 2006 (UTC)

: I don't think that's a good idea. I also don't think anyone's disagreeing. :-) — Omegatron 02:23, 1 March 2006 (UTC)

:Please garner some support for the change first. Stifle (talk) 00:42, 11 May 2006 (UTC)

Template:Arabic alphabet has a table with all the characters in the Arabic alphabet. The purpose of the table is to demonstrage what they look like, however since they are all wikilinks the added underlines obscures the letters themselves in some cases and just looks ugly in others. Is there some (hopefully already included) bit in any of the mediawiki css that coudl be used to remove the underlines from these links (but not from the rest of the template). Dalf | Talk 23:09, 28 January 2006 (UTC)

:As I have in my settis all removed underlines I don't see anyone, but if you want to manually force a template to not use underlines try:

Article: Article. _→AzaToth 23:31, 28 January 2006 (UTC)

::Tried that before (And again just now to be sure) but it does not work. From reading online I take it the span element can be sued to add decorations but not to remove them. Either that or the code that wikipedia adds to links ovrrides. Dalf | Talk 01:12, 29 January 2006 (UTC)

:Create a class (for instance {{mono|nounderlines}}) and add a rule to Common.css:

::.nounderlines a { text-decoration: none }

:And then use {{mono|

: #bodySearchMP .bodySearchIput { opacity: .85; filter: alpha(opacity=85); }

The declaration "filter: alpha(opacity=85);" doesn't seem to validate in any version of CSS. I assume this is something specific to MSIE. Unless I'm wrong, I will remove this line. —Michael Z. 2006-01-29 07:20 Z

:Thats correct, it a MSIE-specific declaration, should be removed. _→AzaToth 07:24, 29 January 2006 (UTC)

:: Okay, I'll take it out. —Michael Z. 2006-01-29 07:39 Z

:::Thank you. — Omegatron 15:25, 29 January 2006 (UTC)

::::You might use the following. It's not standard, but it works in the named browsers:

filter: alpha(opacity=85); /* for Internet Explorer */

-moz-opacity: 0.85; /* for Firefox etc. */

opacity: 0.85; /* CSS3: for Mozilla and Safari */

::::I just thought you might want to know. --Fred Bradstadt 19:34, 31 January 2006 (UTC)

:There's another syntax error. Always check with the [http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fen.wikipedia.org%2Fw%2Findex.php%3Ftitle%3DMediaWiki%3ACommon.css%26action%3Draw%26ctype%3Dtext%2Fcss&usermedium=all W3C CSS Validation Service] after any changes. -- Schapel 01:18, 14 July 2006 (UTC)

The problem: We want a way to briefly link to audio files, like so:

:Bordeaux (Sound pronunciation[?]) is a port city in...

But if you click on the loudspeaker icon, you go to the image page for the loudspeaker icon, which obviously confuses a lot of people. So, as of January 2006, it looks like this:

:Bordeaux (pronunciation ▶ (help·info)) is a port city in...

(which shows up as an unknown character box in IE6, and isn't optimal anyway.)

Ideally, we would be able to use css or software changes to make a clickable icon for audio files.

Add this to your user css (User:YOURUSERNAME/monobook.css):

.audiolink a{
background: url("http://upload.wikimedia.org/wikipedia/commons/f/f7/Loudspeaker.png") center left no-repeat !important;
padding-left: 16px !important;
padding-right: 0 !important;
}

and then reload this page:

• External audio link:
• : [http://en.wikipedia.org/wiki/Image:Es-Argentina.ogg pronunciation]
• External audio link with audiolink class:
• : [http://en.wikipedia.org/wiki/Image:Es-Argentina.ogg pronunciation]
• Internal audio link:
• : pronunciation
• Internal audio link with audiolink class:
• : pronunciation

This way people can click on the loudspeaker icon without going to the loudspeaker's image description page. If it works for everyone, can we add it to MediaWiki:Common.css and use the audiolink class where appropriate?

The icon should really be a system icon (in http://en.wikipedia.org/skins-1.5/monobook/), but we can use a (protected?) image from the Image: namespace for now. I made a copy [http://upload.wikimedia.org/wikipedia/en/b/b8/Audiolink_icon.png here] to be protected, but maybe that's not necessary.

Same discussion here. — Omegatron 18:56, 18 January 2006 (UTC)

Ok it doesn't work in common.css or monobook.css. Something to do with the !important not working? — Omegatron 03:29, 29 January 2006 (UTC)

:Did you try looking at it with Firefox's DOM Inspector? It's usually very enlightening. --cesarb 18:33, 30 January 2006 (UTC)

::I didn't try any troubleshooting. I didn't want to leave it in the sitewide css if it was breaking something. Maybe I'll try later. It works fine in my user css. — Omegatron 21:44, 30 January 2006 (UTC)

I did this succesfully with vi:MediaWiki:Common.css and vi:Tiêu bản:Âm thanh at the Vietnamese Wikipedia. – Minh Nguyễn (talk, contribs) 02:36, 30 January 2006 (UTC)

:It's not working correctly there, either. The speaker should be clickable and go to the same place as the link. A non-clickable speaker is better than one that goes to the image page, though. :-) — Omegatron 21:46, 30 January 2006 (UTC)

Oh yeah, I forgot to revisit that issue. Actually, I think it should be doable, using the same code that places little blue arrow icons after all the external links. – Minh Nguyễn (talk, contribs) 10:27, 31 January 2006 (UTC)

:It's basically the same code, and it works fine when I tried it in my user css. The speaker is clickable and goes to the sound file directly. I'll try to mess with the DOM inspector later. — Omegatron 18:57, 31 January 2006 (UTC)

:I had assumed that would be the logical solution. Links to irc channels, to secure external websites, and to external websites, all automatically display an icon. Adding another filetype to the list shouldn't be difficult. -- Ec5618 10:47, 31 January 2006 (UTC)

::That's what bugzilla:3726 is for. But do we really want it to display a speaker for all audio files? I wanted to add it just for a specific class, so we could pick and choose. I have code that will work for all audio files, too. — Omegatron 18:57, 31 January 2006 (UTC)

Ummm.... Nevermind. It works now. :-) — Omegatron 04:44, 1 February 2006 (UTC)

This is excellent?

Is it possible to do something similar for PDF files?

We mostly attempt to tag external links which will bring up PDF files, to warn users in advance: however this is not always easy in context.

It would be nice if it were possible to arrange that all links to *.pdf had some sort of icon (like the little arrow for ordinary external links).

FWIW bugzilla:1578 seems to be relevant.

HTH HAND —Phil | Talk 14:06, 15 February 2006 (UTC)

: It certainly is.

bodyContent a[href $="pdf"] {

background: url(http://upload.wikimedia.org/wikipedia/en/thumb/7/79/Adobepdfreader7_icon.png/15px-Adobepdfreader7_icon.png) center right no-repeat;
padding-right: 15px;
}

: These icons should really be folded into Mediawiki once they have enough support, though. Currently they're from the image namespace.

: Oh, and if you use Firefox, you'll like the [http://www.bolinfest.com/targetalert/ targetalert extension]. — Omegatron 01:51, 1 March 2006 (UTC)

: Either put it in your user css or get the test styles bookmarklet from [http://www.squarefree.com/bookmarklets/webdevel.html squarefree], copy and paste, and the following PDF files should have icons:

1. http://www.example.org/notapdf.html
2. http://www.example.org/pdffile.pdf
3. [http://www.example.org/notapdf.html not a PDF]
4. [http://www.example.org/differentpdffile.pdf a PDF file] — Omegatron 05:25, 2 March 2006 (UTC)

::Not bad, but I have a couple of issues with this:

::# In Safari, the icon replaces the external link icon

::# At that tiny size, the icon looks like a fuzzy blob

::#* It needs to be more iconic

::#* If it was just a couple of pixels bigger, it would align neatly with the text baseline, instead of floating above it

::Adding "(PDF)" still seems better to me. —Michael Z. 2006-03-02 06:05 Z

:::Not working for me: I can see the icon fine by cutting/pasting the URL into IE, but I'm not getting anything other than the usual little arrow on those links. Is there some special incantation for IE, or am I simply SOL on this one? —Phil | Talk 08:11, 2 March 2006 (UTC)

:::: But you see the regular external link icons? They're included in exactly the same way. Hmmm... Yes, it appears these selectors don't work in IE. I don't know how they add the external link icons, then... I'll have to dig through the site CSS some more...

In Safari, the icon replaces the external link icon

• Good. That's what it's supposed to do.

At that tiny size, the icon looks like a fuzzy blob

• Looks fine on my screen. I thought it was a little big, actually; it's 15×15 pixels wide, while the regular external link icon is only 10×10. It's just an example to show it can be done, anyway; it could easily be made bigger, if really necessary. Create a thumb of :Image:Adobepdfreader7_icon.png at the size you want (anywhere), then copy the URL of that image and replace the one in the CSS statement.

It needs to be more iconic

• Which means... what, exactly?

If it was just a couple of pixels bigger, it would align neatly with the text baseline, instead of floating above it

• Depends on your font size, perhaps. How do the regular external link icons look? — Omegatron 15:13, 2 March 2006 (UTC)

"More iconic..." Sorry: I mean that it either needs to be redrawn at the small size so that it's sharper, and not so fuzzy, or maybe it should be replaced with something not antialiased at all and more stylized, perhaps a simple one-colour pixel-line drawing like the external link icon. —Michael Z. 2006-03-02 15:48 Z

: Ah. It looks good to me, though maybe it doesn't at lower screen resolutions? It's just a thumb of :Image:Adobepdfreader7_icon.png. A dedicated icon would be better. (Also, the icon is apparently copyrighted. That would be another problem with sitewide use.) — Omegatron 16:02, 2 March 2006 (UTC)

Oh. Mediawiki uses a CSS class="external" to add the icons, so they work in IE. To get PDF icons in IE, you'd need to change Mediawiki or add a class manually:

[http://www.example.org/differentpdffile.pdf a PDF file]

with CSS like:

bodyContent a[href $="pdf"], #bodyContent span.PDFlink a {

background: url(http://upload.wikimedia.org/wikipedia/en/thumb/7/79/Adobepdfreader7_icon.png/15px-Adobepdfreader7_icon.png) center right no-repeat;
padding-right: 15px;
}

But even that doesn't work. I give up.

I suggest not using IE. :-) — Omegatron 05:08, 3 March 2006 (UTC)

I'd suggest making the selector set more like this:

#bodyContent a[href$=".pdf"], #bodyContent a[href*=".pdf?"], #bodyContent span.PDFlink a

This would account for instances like these:

• http://www.example.org/{{CURRENTYEAR}}/{{CURRENTMONTH}}/{{CURRENTDAY}}/pdf (as in a blog or something)
• http://www.example.org/example.pdf?foo=bar (it could happen)

But we should also account for PDFs in the Image: namespace with a rule afterwards that negates this one.

 – Minh Nguyễn (talk, contribs) 22:03, 4 March 2006 (UTC)

: Good ideas. The thing I've seen is something.pdf#page=14 , so this would be better:

bodyContent a[href$=".pdf"],
bodyContent a[href*=".pdf?"],
bodyContent a[href*=".pdf#"],
bodyContent span.PDFlink a {

background: url(http://upload.wikimedia.org/wikipedia/en/thumb/7/79/Adobepdfreader7_icon.png/15px-Adobepdfreader7_icon.png) center right no-repeat !important;
padding-right: 15px;
}

: Also, although the icon is copyrighted, Adobe allows it to be used for identifying PDF files, as I copied and pasted to :Image:Adobepdfreader7_icon.png, so it is ok to use site-wide. Won't work in IE, but at least Firefoxers can use it. Then if Mediawiki is ever updated to tag PDF links, it will work for everyone. — Omegatron 00:27, 22 March 2006 (UTC)

Any opposition to me adding this for the benefit of those of us whose browsers support it? — Omegatron 14:50, 22 August 2006 (UTC)

:Sketchy in terms of freeness. For instance, they only permit its use if the PDF was created using Adobe Acrobat, not any third-party software, which we can't verify. I'd go with a little "PDF" marker somehow embedded in the external link icon, not the copyrighted and trademarked logo. Or you could ask a dev if they'd add it to the software itself, which would negate any worries on our level provided they agree. (Have you opened a bug?) —Simetrical (talk • contribs) 19:25, 22 August 2006 (UTC)

bugzilla:1578 has been unfixed for a year and a half. When it is fixed, the same icon can be used with the same CSS, but it will work in IE, too.

Other possibilities: {{tl|PDFlink}} uses 15px. There's also 15px, 15px, :Image:Icons-mini-file acrobat.gif, 15px, 15px, 15px, :Image:Page white acrobat.png, 15px... An icon, presumably a copy of [http://www.adobe.com/images/pdficon_small.gif] or [http://www.adobe.com/images/pdficon_large.gif], was deleted based on the rationale here. Trademark vs copyright. The {{tl|PDFlink}} icon, on the other hand, survived deletion here.

I don't really like the Noia icon, though; there are definitely better ones available. I like these pretty equally:

1. PDF file15px
2. PDF file:Image:Icons-mini-file acrobat.gif
3. PDF file:Image:Page white acrobat.png
4. PDF file15px

Also, as explained here, we can change the {{tl|PDFlink}} template to apply the "PDFlink" style class, and this proposed change will work in IE for all such tagged links, as well. — Omegatron 19:09, 23 August 2006 (UTC)

My latest rendition:

bodyContent a[href$=".pdf"].external,
bodyContent a[href*=".pdf?"].external,
bodyContent a[href*=".pdf#"].external,
bodyContent span.PDFlink a {

background: url(http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif) center right no-repeat;
padding-right: 16px;
}

Similar in width to the default external link icon, but still identifiable as a PDF icon. (Like this, but the icon is centered vertically:)

• [http://www.example.org/ Regular external link]
• [http://www.example.org/ External link to a PDF file]

Doesn't show up on internal links (like Image: pages). Icon is license-free (and I tried all the other ones in many different size and configurations and this one looks best). Meshes well with my proposed {{tl|PDFlink}} template (I tried it at User:Omegatron/PDFlink). I am going to go site-wide with this soon, if there are no objections, though I'm sure we'll see a handful of objections after it goes up. But we can tweak it then or remove it, depending on what people say. But I've been proposing this for months with no complaints about the concept, and {{tl|PDFlink}}, which does effectively the same thing, passed a TfD, so it should go smoothly. — Omegatron 23:40, 26 August 2006 (UTC)

: Oh wait. It doesn't work in IE? Crap. — Omegatron 23:52, 26 August 2006 (UTC)

Ah. IE was crapping out on the advanced selectors. We could either do it this way or use some IE hack to hide them from it:

/* Change the external link icon to an Adobe icon for all PDF files */
/* (in browsers that support the selectors, like Mozilla and Opera) */

bodyContent a[href$=".pdf"].external,
bodyContent a[href*=".pdf?"].external,
bodyContent a[href*=".pdf#"].external {

background: url(http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif) center right no-repeat;
padding-right: 16px;
}
/* Change the external link icon to an Adobe icon anywhere the PDFlink class */
/* is used (notably Template:PDFlink). This works in IE, unlike the above. */
span.PDFlink a {
background: url(http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif) center right no-repeat !important;
padding-right: 16px !important;
}

This has all of the above features, works in Firefox and Opera for all PDF links, and in IE everywhere the PDFlink template or class is used. — Omegatron 00:45, 27 August 2006 (UTC)

I added it. Complaints go here: — Omegatron 00:18, 28 August 2006 (UTC)

JesseW removed the following:

#bodySearchMP .bodySearchIput { opacity: .85; }

Opacity is a CSS3 property, and it will validate if you tell the W3C's validator that the style sheet is CSS3. That said, I have no idea what it does or whether any browser supports it, so I don't mind that it was removed. —Michael Z. 2006-01-31 16:22 Z

:You might use the following. It's not standard, but it works in the named browsers:

filter: alpha(opacity=85); /* for Internet Explorer */

-moz-opacity: 0.85; /* for Firefox etc. */

opacity: 0.85; /* CSS3: for Mozilla and Safari */

:I just thought you might want to know. --Fred Bradstadt 19:34, 31 January 2006 (UTC)

::The only one of those that are legal CSS2 is -moz-opacity: 0.85;, offcourse it only works in mozilla-browsers, buts it's totally legal css2 (non-standard css must be defined with a leading dash). _→AzaToth 19:41, 31 January 2006 (UTC)

::: Do you have a reference? The [http://www.websitedev.de/css/validator-faq W3C's CSS FAQ] specifically says that -moz-opacity does not validate. —Michael Z. 2006-02-1 01:07 Z

:::: Yupp: http://www.w3.org/TR/CSS21/syndata.html#q4 _→AzaToth 01:10, 1 February 2006 (UTC)

::::: I did not know that; thanks. —Michael Z. 2006-02-1 01:17 Z

I propose indenting bulleted lists so that they align consistently with numbered lists. Please see the proposal with examples at MediaWiki talk:Monobook.css#Consistent list alignment. —Michael Z. 2006-02-1 21:13 Z

:Please do it in MediaWiki:Monobook.css, where you proposed it, then. It works fine as-is in Classic-derived skins; your "fix" badly misaligns them. —Cryptic (talk) 23:29, 1 February 2006 (UTC)

:: Thanks, I didn't realize that basic text elements rendered differently in different skins. I will investigate more widely. —Michael Z. 2006-02-1 23:38 Z

:: List alignment is broken in Monobook and Chick skins. I'm proposing the fix for both of them. —Michael Z. 2006-02-01 23:56 Z

I have created Wikipedia:Catalogue of CSS classes as a place to list and describe all the CSS classes (and IDs). The idea is to have a central place to put all the descriptions, instead of having them scattered all around the wiki. --cesarb 04:22, 3 February 2006 (UTC)

I am proposing that we adjust the cell padding for class 'wikitable'. It currently appears as "padding: 0.2em;" in the CSS. This produces vertical padding which is too large in proportion to the horizontal padding, and there is too much vertical space at smaller fonts. In the two tables below, I have created different cell spacings for comparison. I prefer a vertical spacing of 0 (especially with the small font) or 0.1em (since some might find 0 to be too tight with a normal font) and a horizontal spacing of 1ex or 0.5em. What do you think? —Mike 00:01, 11 February 2006 (UTC)

:This a to a large extent a matter of taste. Looking at the examples above, I tend to agree that vertical padding could be decreased. To me vertical padding 0.1em and horizontal 0.2em (as is) looks best. Horizontal padding at 0.5em looks very wide to me and may waste critical space on the page. I have one technical question though. In your parameters you seem to use "padding: vert, hor", but the definition I know has "padding: top right bottom left". Are you sure it's well defined (and works in all browsers) the way you do it? −Woodstone 12:05, 11 February 2006 (UTC)

:: That's the shortcut if the values are redundant: you can specify one, two, three or all four values, and the missing ones will be the same as the value for the opposite edge. Same goes for margins and borders. —Michael Z. 2006-02-11 15:43 Z

:Thanks for the confirmation (I knew it only for just one value). Since "em" derives from the font width and "ex" from the font hight, we might go for a horizontal padding of 0.2em and vertical padding of 0.2ex. −Woodstone 16:36, 11 February 2006 (UTC)

:: Em is defined as em-height: the height of the font's character box, i.e. the font size. Most browsers treat ex as exactly 0.5 em (although reportedly MSIE/Mac tries to calculate true em-height by analyzing the rasterized font!). May as well use both measurements in em units, for consistency. —Michael Z. 2006-02-15 18:49 Z

:Em is defined as the width of a capital M (see for example the [http://www.adobe.co.uk/type/topics/glossary.html abdobe glossary], while ex is the height of a small x. Indeed, in most cases em is about 2 times ex.−Woodstone 20:08, 15 February 2006 (UTC)

:: No. We're not talking about traditional typographer's measurements, but the units of measurement as defined in CSS: "The 'em' unit is equal to the computed value of the 'font-size' property of the element on which it is used." [http://www.w3.org/TR/CSS21/syndata.html#length-units]. —Michael Z. 2006-02-15 22:49 Z

Would it be possible to add the following? –

pre { overflow-x: auto; overflow-y: visible; }

This would keep long lines of code from adding horizontal scrollbars on large pages (for example WP:AN/I on occasion) and would instead add horizontal scrollbars directly to the PRE'd text.

To see this in action for yourself, simply add the line above to your userspace CSS override, then go to User:Locke Cole/Sandbox and scroll down to the "PRE test" section. —Locke Cole • t • c 02:06, 23 February 2006 (UTC)

:I'll second the suggestion. In my own CSS I have had "pre { overflow: auto; }" which has worked well. —Mike 03:19, 24 February 2006 (UTC)

:: Not many people read these talk pages. Can I suggest that you bring it up first on the Technical section of the village pump? Ral315 (talk) 06:10, 28 February 2006 (UTC)

::: Certainly, will post here when I've done it with a difflink. —Locke Cole • t • c 06:23, 28 February 2006 (UTC)

::: Posted the request to village pump-proposals, [http://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_%28proposals%29&diff=41575686&oldid=41569803 here]. —Locke Cole • t • c 06:27, 28 February 2006 (UTC)

:I support this idea. I've always wondered why pre'd text does this, and figured there must be a reason for it. Johnleemk | Talk 06:40, 28 February 2006 (UTC)

::^ What he said. I support this too. Phoenix-forgotten 18:25, 28 February 2006 (UTC)

I use this, and suggested it a long time ago, but IE doesn't support it, in a bad way, and pages with lots of pres slow down browsers that do. It's not cut and dry. *Goes to look up the etymology of the term "cut and dry"* — Omegatron 01:40, 1 March 2006 (UTC)

: I think it's "cut and dried". —Michael Z. 2006-03-01 01:47 Z

::The phrase is "cut and dry", at least in common American usage. – Minh Nguyễn (talk, contribs) 22:09, 4 March 2006 (UTC)

::: 'Many people mishear the standard expression meaning "set," "not open to change," as "cut and dry." Although this form is listed in the Oxford English Dictionary, it is definitely less common in sophisticated writing. The dominant modern usage is "cut and dried."' —Paul Brians (2003) Common Errors in English Usage, {{ISBN|1887902899}}.

::: The Canadian Oxford Dictionary (2nd ed.) lists only "cut and dried", with the idioms and phrasal variations of the headword "cut". —Michael Z. 2006-03-05 18:33 Z

:Given how infrequently pre is used, and even more infrequently how often it's allowed to go on forever without wrapping, is this really a big issue? I mean, are you objecting to this change? =) And I wonder if IE7 improves the situation at all. —Locke Cole • t • c 01:53, 1 March 2006 (UTC)

::Re-reading your reply, it looks like I might have read it wrong. What exactly does it do in IE? —Locke Cole • t • c 02:21, 1 March 2006 (UTC)

::: It adds unnecessary scroll bars to all the pres, if I remember correctly. :-)

::: MediaWiki_talk:Monobook.css/archive1#pre_autoflow — Omegatron 02:27, 1 March 2006 (UTC)

:::: Weird. FWIW, in IE7 it doesn't work at all (no scrollbars at all except for the horizontal page scrollbar because of the width of the page). I wish I could get IE6 working again so I could try it out in that (for some reason, whenever I enter a URL in IE's address bar, it opens it in Firefox; no, the humor of this is not lost on me, heh). —Locke Cole • t • c 02:50, 1 March 2006 (UTC)

What are we doing with this? Is this a go or no go? howcheng {chat} 00:08, 8 March 2006 (UTC)

:What's the difference between having scroll bars on the page or scroll bars on the pre? Is this really a problem? Couldn't people just add that to their user CSS if they really prefer having their scrollbars on the pre (which seems a bit weird to me). Personally, I don't see a compelling need for this. Kaldari 00:13, 8 March 2006 (UTC)

::Lets see...

First it depends on how wide your screen is, perhaps you have a screen that is so large that it easly fit large pre-block inside. Seccond is that perhaps you doesn't care if a lot of information is beeing located outside your sceen, and you have to scroll horizontally to access that information (or it's might be that you never access pages that large block of text in pre-tags). And, yes, I know this edit violates WP:POINT, but I had to do that :)

:: Yes, it's much much nicer to have scroll bars on the pre itself. This is done in a lot of forums with stuff inside code tags, for intance. I've had it in my monobook.css for a while and I like it. — Omegatron 01:23, 8 March 2006 (UTC)

That's a nice demonstration, but I still don't get the point. Why would anyone prefer scrolling the pre over scrolling the window? For a lot of people, it's easier to scroll the window, for example if you use a scroll ball or one of those two finger trackpads. Why is scrolling the pre so much better? It seems like a matter of user preference to me rather than something that should be universally implemented. Kaldari 01:34, 8 March 2006 (UTC)

: Have you tried it? What skin do you use, by the way? Maybe it doesn't look as horrible in a non-monobook skin... — Omegatron 01:41, 8 March 2006 (UTC)

::Actually I haven't been able to get this particular hack to work at all. Kaldari 02:30, 8 March 2006 (UTC)

Why is scrolling the pre so much better?

:* Because then you don't have to scroll back to continue reading.

:* You can continue reading the article while referencing a specific point in the pre area (coding articles)

:* It doesn't act like a page widening attack and ruin the entire page's layout. — Omegatron 00:25, 24 March 2006 (UTC)

Please don't use {{mono|overflow-y}}. It's not supported in many browsers, including Internet Explorer 6.0 and Safari 2.0. Use {{mono|overflow}} instead, which works almost just as well and is supported by all modern browsers. —Michiel Sikma, 13:05, 13 May 2006 (UTC)

: Doesn't work in Firefox 1.0 either (1.5 works fine). Won't overflow cause a vertical scrollbar to be added in certain situations (looks like it doesn't)? That would be bad, while overflow-y wouldn;t cause any problems. —Ruud 14:42, 13 May 2006 (UTC)

::This is a {{mono|<div>}} with the {{mono|overflow-y}} attribute:

::And here is one with just overflow, which is much more widely supported:

::I don't have all browsers around to test this with, but I can assure you that these two look the exact same on Firefox 1.5. I don't think there's a reason to use {{mono|overflow-y}} over {{mono|overflow}}. PS: this does not seem to work with actual {{mono|<pre>}} tag... looks like block quotes might have to be auto-converted to {{mono|<div>}} tags if we want this to be possible at all. —Michiel Sikma, 21:27, 13 May 2006 (UTC) PPS: it seems that line breaks don't get automatically converted in that {{mono|<div>}} tag. The {{mono|white-space: pre;}} CSS attribute doesn't seem to emulate {{mono|<pre>}} properly. Maybe we need to get a CSS expert in here?

I have been working to update the media templates to a semantic HTML/CSS version, but I need some opinions from CSS gurus. The current templates use tables for visual layout and an inline image for decoration. I propose changing these templates to a simple unordered list and doing the styling with a CSS class. I've already added the (experimental) CSS to Common.css, and the list versions of the templates look like this:

{{User:Omegatron/Sandbox/Listen|filename=Accordion chords-01.ogg|title=Accordion chords|description=Chords being played on an accordion — 145 KB|format=Ogg}}

{{User:Omegatron/Sandbox/Multi-listen start}}

{{User:Omegatron/Sandbox/Multi-listen item|

filename=WhereDidYouSleepLastNight.ogg|

title="Where Did You Sleep Last Night?"|

description=Performed by Leadbelly, a folk singer and guitarist; this Southern Appalachian song dates to the 1870s|

format=Ogg}}

{{User:Omegatron/Sandbox/Multi-listen item|

title="Cross Road Blues"|

description=Performed in 1937 by Robert Johnson, a Delta blues guitarist|

format=Ogg}}

{{User:Omegatron/Sandbox/Multi-listen item|

filename=Po'Gal.ogg|

title="Po’ Gal"|

description=East Coast blues, performed by Zora Neale Hurston in 1939|

format=Ogg}}

{{User:Omegatron/Sandbox/Multi-listen end}}

{{User:Omegatron/Sandbox/Video|filename=A11v 1094228.ogv|title=Buzz Aldrin steps onto the Moon|description=|format=Ogg}}

{{User:Omegatron/Sandbox/Multi-video start}}

{{User:Omegatron/Sandbox/Multi-video item |

filename = Apollo 15 Lunar Rover training.ogg |

title = Rover training |

description = Scott and Irwin train on Earth to use the Lunar Rover. (2.57 MB, ogg/Theora format). |

format = Theora

}}

{{User:Omegatron/Sandbox/Multi-video item |

filename = Apollo 15 launch.ogg |

title = Launch of Apollo 15 |

description = Launch of Apollo 15 running from T-30s through to T+40s. (1.29 MB, ogg/Theora format). |

format = Theora

}}

{{User:Omegatron/Sandbox/Multi-video item |

filename = Apollo 15 TandD.ogg |

title = Transposition, Docking and Extraction |

description = Endeavour comes into dock with Falcon (3.03 MB, ogg/Theora format). |

format = Theora

}}

{{User:Omegatron/Sandbox/Multi-video end}}

If you turn off CSS, they just look like lists:

• Accordion chords (file info)
• Chords being played on an accordion — 145 KB
• Problems listening to the file? See media help.

Questions:

• I have assumed that a list is better for accessibility, but I could be wrong about this. I'm sure it's better than the table currently in use, but is something else better?
• I've replaced an inline image with a decorative background image. Since it's just a decorative image, I figure this is good. This will prevent people from clicking on it and going to the image description page, for one thing. But maybe it's not?
• Should we genericize the list formatting as class="medialist", and have the individual classes like class="videolist" do nothing besides specify the icon? That way if other templates are wanted it is less CSS to change: I've done this.

Feedback:

• I think they look awesome. Nice templates. I'll be sure to use them when the need arises. —Michiel Sikma, 09:53, 8 May 2006 (UTC)

See also Template_talk:Listen#CSS_version — Omegatron 02:58, 1 March 2006 (UTC)

I have been working to get rid of table-based visual layouts lately, and tried to tackle content in columns, like some people prefer with See also sections that have tons of links, etc. I don't really like putting stuff in columns at all, but whatever; I might as well make them work well. Besides, with the CSS-based layout, people who really don't like the columns can turn them off in their monobook.css. ;-) The original table-based templates are at {{tl|col-begin}}, and my new div- and CSS-based ones are at Template talk:Columns. I need feedback and it needs tweaking. Bypass your cache if you don't see the example. — Omegatron 20:33, 19 March 2006 (UTC)

This is completely unrelated to the section right above this one, which proposes an alternate solution for the same problem. — Omegatron 00:42, 28 August 2006 (UTC)

/* VALIDATOR NOTICE: the following is correct, but the W3C validator doesn't accept it */

/* -moz-* is a vendor-specific extension (CSS 2.1 4.1.2.1) */

/* column-count is from the CSS3 module "CSS Multi-column Layout" */

/* Please ignore any validator errors caused by these two lines */

.references-2column {

font-size: 90%;

-moz-column-count:2;

column-count:2;

}

:This code breaks shit. FF 1.5.0.4. Someone please remove the line " column-count:2;" ASAP, please. --Connel MacKenzie - wikt 03:35, 22 August 2006 (UTC)

::It's also terribly unuseful and unreadable if things are in multiple columns because of the great amount of wrapping that then occurs. I'm tired of this "some people think this is a change for the worse, but you can always turn it off in your own stylesheet!" mentality that a lot of these CSS additions seem to be presented with. —msikma <user_talk:msikma> 06:00, 22 August 2006 (UTC)

:::Would a sysop here PLEASE remove the line " column-count:2;" ASAP. --Connel MacKenzie - wikt 03:56, 26 August 2006 (UTC)

::::OK, it's gone. —Mets501 (talk) 04:09, 26 August 2006 (UTC)

::::: Thank you for trying. --Connel MacKenzie - wikt 00:16, 28 August 2006 (UTC)

:Strange. It's exactly the same thing which was inline in several articles; why would it break when placed on Common.css but not when inlined? And BTW, I'm also on Firefox 1.5.0.6, and see no problems. If it's just the complaint on the JavaScript console, that's not actually breaking anything; it's, as it says, dropping the unknown declaration, and thus making no difference. I'm adding it back; please explain how is it breaking things before removing it again. --cesarb 03:19, 27 August 2006 (UTC)

::For an example of an article which currently uses it inline, see 2006 Israel-Lebanon conflict. My objective in creating the .references-2column class is to have it in a single place, instead of in several articles, so that if a change is decided (for instance, to reduce the font size to 85%), it can be made in a single place. --cesarb 04:09, 27 August 2006 (UTC)

::: First you say it isn't causing errors, then you admit it is, and use that for justification for putting it back in? Pray tell, how can I visit Wikipedia, if everytime I do I'm punished by seconds of lockups from garbage CSS as it blitzes my JS console with each page load? AND NOW YOU ARE ADDING THE SAME BAD CSS DIRECTLY TO ENTRIES? (I see you've edited that entry, but don't feel like finding out if it was you personally, or a cohort that made the edit in question...considering the hundreds of edits recently.)

::: Error-causing CSS does not belong anywhere. Isn't it obvious that great pains were taken to ensure JS/CSS errors don't occur anywhere in a default mediwiki installation? Fix it, or remove it. As someone else noted above, the functionality this (sometimes) provides is unwanted anyway. --Connel MacKenzie - wikt 00:16, 28 August 2006 (UTC)

• Don't Wikipedia formatting guidelines talk about experimenting in 800x600 sized browser windows? The two-column display is horrid on the "target" screen size (true for sister-projects, anyhow.) Yes, it is a pain for me to shrink my browser window down that small, but I do it when I'm testing Wiktionary pages. I only maximize the window temporarily, so I can see (when it is resized back down) what the page looks like to visitors. The example page given above looks pretty silly in that mode. Out of all those references, only five were less than two line; most were many lines of wrapped text, with lots of whitespace lost in the middle. The splits themselves, of course, are illogical. --Connel MacKenzie - wikt 00:26, 28 August 2006 (UTC)
• Thankfully, your "fix" doesn't break:
• # Internet Explorer 7
• # Netscape Navigator 7
• # Konqueror 3.5
• # Mozilla 1.7
• # lynx 2.8
• # Elinks 0.11
• # w3m/0.5
• So, I suppose your recommendation will be that I should stick to one of them? --Connel MacKenzie - wikt 00:39, 28 August 2006 (UTC)

Assume good faith. I'm not the one who introduced the 2-column layout to several articles (in fact, I introduced it to none). I just want to consolidate the CSS declarations to a single place, to make it easier to make enhancements and fixes; to do so, it first needs to be identical to what is currently being done. An example of a possible enhancement that could be done once all the articles are using the CSS class instead of an inline style would be to add column-width (and -moz-column-width), which specifies a minimum width to the columns (and thus directly addresses your complaint about it not working well on smaller windows); another one would be to add column-gap (and -moz-column-gap) to add a bit more spacing between the columns. And finally, I fail to see how a single message at the JavaScript console causes any slowdown; you are the first one to report it (remember that I also use Firefox 1.5, so I'd notice it quickly if there were any slowdown). Unfortunately, there's no way to hide the CSS3 version of the declaration (without the -moz- prefix) from Gecko. Since no browser seems to understand the CSS3 version (I believe it's there for future-proofing; again, it wasn't my idea), it would be possible to remove column-count:2 (keeping only the -moz-column-count:2 understood by Gecko), after the references-2column class is widely adopted (if it were to be removed right now, it's possible that the centralization would not be accepted). --cesarb 19:38, 28 August 2006 (UTC)

What does everyone think of this? I'm largely CSS-illiterate, so I can't venture an opinion (although I'll note that Firefox _{displays subscript and} ^{superscript without screwing up leading, yay!}) —Simetrical (talk • contribs) 04:44, 20 March 2006 (UTC)

sup, sub {line-height: 0.1em; font-size: 1ex;}

: … has worked well so far for me. One should perhaps take some care about font sizes, too:

sup small, sub small {font-size: inherit;}

: Christoph Päper 19:03, 20 March 2006 (UTC)

In concert with MediaWiki talk:Monobook.css#Coordinates in article heading, Wikipedia talk:WikiProject Geographical coordinates#Coordinates at the top of the article, and [http://bugzilla.wikipedia.org/show_bug.cgi?id=4719 bug 4719], need something like:

----

de:MediaWiki:Common.css

/* Do not expand kvaleberg.com-URLs for printing */

#content span.coordinates a.external.text:after, #content span.coordinates a.external.autonumber:after {

content: "";

}

----

:--William Allen Simpson 11:05, 21 March 2006 (UTC)

Why do plainlinks have padding: 0 ! important;? It's overriding my user CSS. I can't change the padding even with !important. — Omegatron 00:23, 24 March 2006 (UTC)

Please see "[http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=46083838#Updates_to_CSS_and_JS_pages_to_reduce_redundancy Updates to CSS and JS pages to reduce redundancy]". --Melancholie 00:45, 24 March 2006 (UTC)

A problem has been signalled with linked IPA strings in the discussion at wikipedia talk:Manual of Style (pronunciation). Such strings often contain diacritics and slight modifications under the base line. If such a string is underlined, readability is damaged. Therefore it would be better to suppress any underlining of IPA links. The IPA strings are supported by the template:IPA and the class IPA defined in this style sheet. Adding specific style elements for IPA links would achieve this, approximately as follows:

.IPA a:link, .IPA a:visited {text-decoration: none}

Could someone check this out and add it? −Woodstone 16:46, 29 March 2006 (UTC)

:Strongly agree. The underlining is very hard to read for some characters, but it's very useful to link various IPA characters to their respective articles. Compare {{IPA|ѵ}} vs. {{IPA|ѵ̟}}. —Simetrical (talk • contribs) 19:16, 22 August 2006 (UTC)

::Done. —Mets501 (talk) 03:49, 26 August 2006 (UTC)

::Please answer at VPT:Highlight search box

A proposal that came out the Main Page Redesign discussions was:

Image:Mainpage_searchbox2.png

• Improve visibility of the left-navigation search box in the default MonoBook skin, with an orange-colored border (as used on the active tabs at the top).

This would be to aid new users in finding the search box.

:::this is easily shown by adding this line to one's user/monobook.css. (and presummably common or monobook css for sitewide)

#searchBody {border-color: #FABD23;}

The only question remaining is can this highlight be easily coded to display on only select pages? (specifically the Main Page, and possibly any others we wanted to choose) (or only for non-signed-in users, or other useful permutations?) Or is it a choice of "site-wide or not at all"?

Once this is answered, I will copy the proposal to the proposal page. Thanks. --Quiddity 04:19, 6 April 2006 (UTC)

:You could probably do it by inserting a stylesheet altering #p-search directly onto the Main Page code. Unfortunately, I can't think of how to do this without having MediaWiki allow the