![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
Per my Village Pump proposal, I'm going to be adding a bit of CSS to enable the creation of metadata (ala Personendaten in the German Wikipedia). This will allow us to try out some metadata schemes and hopefully implement some in the future. See this article for more info. Kaldari 19:27, 22 December 2005 (UTC)
See Template talk:Dynamic navigation box. Monobook contains the code missing in other CSS. -- User:Docu
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 Wikipedia:Village pump (technical)#Bug in Monobook.css there appear to be two errors in Common.css:
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):
Most other images are fine, and IE seems Ok with these. - Wikibob 03:54, 13 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 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 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)
<div class="outer frame">
<div class="inner frame">Image goes here</div> <div class="caption">Caption goes here</div>
</div>
<div class="thumb">
<div style="width:WIDTH SET HERE"> Image goes here <div class="thumbcaption">Caption here</div> </div>
</div>
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 [3]. 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.
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
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." [4] 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)
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 [[clock|clocks]] instead of the perfectly correct code [[clock]]s, 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)
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. → Aza Toth 22:01, 27 January 2006 (UTC)
{| |- | {| |- | |} |- | |}
table | |--tbody | |--tr | | | |--td | | | |--table | | | |--tbody | | | |--tr | | | |--td |--tr | |--td
table > tbody > tr > td
etc...) →
Aza
Toth 19:20, 30 January 2006 (UTC)
{| 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... |} |- | |}
A B
means B descendant of A, A > B
means B child of A. →
Aza
Toth 22:10, 30 January 2006 (UTC)
I'm can agree with a compromize, create a new rule .wikitable2 that are using my specification. → Aza Toth 09:06, 15 February 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)
<span style="text-decoration: none;">[[Article]]</span>
:
Article. →
Aza
Toth 23:31, 28 January 2006 (UTC)
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
filter: alpha(opacity=85); /* for Internet Explorer */ -moz-opacity: 0.85; /* for Firefox etc. */ opacity: 0.85; /* CSS3: for Mozilla and Safari */
The problem: We want a way to briefly link to audio files, like so:
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:
(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:
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 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)
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)
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)
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)
#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; }
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
"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
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:
<span class="PDFlink">[http://www.example.org/differentpdffile.pdf a PDF file]</span>
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:
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)
#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; }
Any opposition to me adding this for the benefit of those of us whose browsers support it? — Omegatron 14:50, 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: {{ 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 [5] or [6], was deleted based on the rationale here. Trademark vs copyright. The {{ 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:
Also, as explained here, we can change the {{ 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:)
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 {{ 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 {{ PDFlink}}, which does effectively the same thing, passed a TfD, so it should go smoothly. — Omegatron 23:40, 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
filter: alpha(opacity=85); /* for Internet Explorer */ -moz-opacity: 0.85; /* for Firefox etc. */ opacity: 0.85; /* CSS3: for Mozilla and Safari */
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
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)
Size | as is | 0 | 0.1em | 0.2em | 0.3em | 0.4em | 0.5em | 1em | 1ex | ← horizontal padding |
---|---|---|---|---|---|---|---|---|---|---|
as is | 1,234,567 | |||||||||
0 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.2em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.3em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.4em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.5em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
1ex | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
↑ vertical padding |
Size | as is | 0 | 0.1em | 0.2em | 0.3em | 0.4em | 0.5em | 1em | 1ex |
---|---|---|---|---|---|---|---|---|---|
as is | 1,234,567 | ||||||||
0 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.2em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.3em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.4em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.5em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
1ex | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 |
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 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)
What are we doing with this? Is this a go or no go? howch e ng { chat} 00:08, 8 March 2006 (UTC)
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 :)
→ Aza Toth 00:46, 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)
Why is scrolling the pre so much better?
Please don't use overflow-y. It's not supported in many browsers, including Internet Explorer 6.0 and Safari 2.0. Use overflow instead, which works almost just as well and is supported by all modern browsers. — Michiel Sikma, 13:05, 13 May 2006 (UTC)
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)
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:
If you turn off CSS, they just look like lists:
Questions:
Feedback:
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 {{ 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; }
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;}
sup small, sub small {font-size: inherit;}
In concert with MediaWiki talk:Monobook.css#Coordinates in article heading, Wikipedia talk:WikiProject Geographical coordinates#Coordinates at the top of the article, and bug 4719, need something like:
/* Do not expand kvaleberg.com-URLs for printing */ #content span.coordinates a.external.text:after, #content span.coordinates a.external.autonumber:after { content: ""; }
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 " 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)
A proposal that came out the Main Page Redesign discussions was:
This would be to aid new users in finding the search box.
#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)
-- James S. 22:57, 11 April 2006 (UTC)
...as explained here: wikipedia talk:footnotes#Resizing footnotes - what is going on?, there was no community consensus to do that.
Please also see and/or contribute to (ongoing) discussions at:
AFAIK, (from what I read in these discussion places), the size of footnotes was reduced to 90% in a solo-action by R. Koot ( diff), so please revert it until consensus shows this would be a good idea (not the case currently). -- Francis Schonken 10:11, 4 May 2006 (UTC)
I totally agree with Hoary. 90% on Hiroh Kikai is insane (I've corrected that temporarily to 100% in that article). Putting everything down to 90% doesn't work. Let's do the small-references class as I proposed below. -- Ligulem 09:35, 6 May 2006 (UTC)
Like in subject. This imposition is definitely not consensus, and causes problems for lots of people. Think disability community, for example; but also just pages that already use sizing of notes (which I don't think is a good idea either, but it's article-by-article). If users want custom CSS, that's fine, but don't impose disruptive CSS on all readers. LotLE× talk 19:08, 4 May 2006 (UTC)
If ol.references { font-size: 90%; }
is removed, could we then at least agree to add .references-small { font-size: 90%;}
and use that class on all those articles that want the smaller font? I think adding references-small doesn't hurt that much, right? This would at least eliminate the absolutely uneeded difference between 85% and 90%. Plus no need to hard code that into articles (or templates). --
Ligulem 22:10, 4 May 2006 (UTC)
.references-small { font-size: 90%;}
. I'm trying to find a compromise that is acceptable for all. If everybody here insists on his position, then we just risk that ol.references { font-size: 90%; }
is removed and we are where we were before. Which is cleary not satisfactorily. But I must concede that I by myself was astonished that ol.references { font-size: 90%; }
was added to Common.css. Of course it was a surprise for me and I would be more than happy with that. But as you see, there are others here which are not happy with that at all. So I agree that this is no consensus for plain ol.references { font-size: 90%; }
. So if there is an admin that removes ol.references { font-size: 90%; }
I urge to add .references-small { font-size: 90%; }
as a replacement. Just for the records: I'm not an admin. --
Ligulem 10:15, 5 May 2006 (UTC)<references />
inside a DIV tag that modified the text size. This is non-uniform, and probably undesirable because some pages end up using 100%, some end up using 85%, and still others use values from 90-95% of the standard font size. By having this in a CSS class, we can affect all usage of references at once (or, as Ligulem suggests, at least provide a CSS class so pages will just use <div class="references-small"><references /></div>
). Of course it'll be more challenging to get people to use .references-small, and it still leads to some articles being 100% and others being whatever .references-small is set to.. but it's still better than using a template to do this (especially since the template is subst'd, making it impossible to update or change without going through and re-subst'ing them again). —
Locke Cole •
t •
c 02:21, 5 May 2006 (UTC)Part of this problem has been caused by me, but resulting from something completely different than the resizing issue: one of the complexities of this problem was caused by the fact that both the {{ Footnotes}} and the {{ FootnotesSmall}} templates were instructed to be used by a "subst:" (placing a lot of "div" tags in article namespace, that can't be undone by changing the template content). The reason for this has nothing to do with RESIZING but with the "help" comment included in these templates that doesn't become visible in edit mode unless with a "subst:" being applied to the template previously.
Here's a solution I'd like to elaborate (doesn't clean up the size-reducing div tags now in article namespace, but might be a better solution for the future).
PLEASE GIVE ME SOME TIME TO TRY THIS OUT
Here's a short description. Might seem complicated at first sight, but in fact it's quite simple, and adresses the issue, independent from the technique (css or "div") used for resizing:
Also needs rewriting the instructions regarding the use of these templates on wikipedia:footnotes, but I'll try to make this work technically first. -- Francis Schonken 14:54, 5 May 2006 (UTC)
<resize=whatever_I_like>
is contrary to the spirit of both the template and of the css, i.e. having a *consistent* formatting in all articles. The class references-small just changes the font size: if I can specify a different size anyway, then what is its purpose? I would prefer sticking with something between 92% and 95% (or maybe simply <small> </small>
) and remove the resize parameter; one can always enlarge the whole page text with the scroll of a wheel, or a menu click, after all. --
Gennaro Prota
(talk) 23:34, 8 May 2006 (UTC)To the admins or sysops: as you can read here and on the Village Pump technical page, there is no and never has been a consensus on changing the footnotes size. Please revert it for now until a consensus has been reached, as the change should not have been made in the first place. — Michiel Sikma, 10:58, 6 May 2006 (UTC)
Anyway, as a temporary solution, I made {{ FootnotesSmall}} work according to the solution explained above. This solution currently uses div tags with style="font-size:...%", but adjusts correctly (with a workaround solution):
Further, I note that some admins refuse to follow established consensus on wikipedia talk:footnotes, and the actual text of the Footnotes guideline that does not recognise that the <references/> tag should in any way resize the text of the references. These admins abuse their power, and that's as simple as that. I mean, I don't need admin powers to help guidelines and policies materialize (and I do quite some of that). Admins refusing to adjust the css according to these guidelines and policies is a completely different cup of tea. It won't make me pursue to become an admin (yet), for such one-off anomaly. I had some previous example of Ruud Koot's anti-wiki behaviour of trying to impose a solution by forced means against community consensus, and would still be able to document the strain he put on the wikipedia community then. With this new case, maybe time to ask Ruud's deposition as a sysop (whatever his other, more positive, contributions to wikipedia).
Please let me know when the css is updated. I'll not continue to follow this page, but might further promote the solution that resizes with div tags for having normal size of footnotes, although currently that is a deplorable workaround. So please let me know when the css is up-to-date, and I'll reverse these solutions, and assist to make a more elegant resizing template. -- Francis Schonken 16:55, 7 May 2006 (UTC)
What should be done with History of entropy, which contains:
<div style="font-size:85%"> #{{note|Mendoza}} {{cite book|author=Mendoza, E. |title=Reflections on the Motive Power of Fire – and other Papers on the Second Law of Thermodynamics by E. Clapeyron and R. Clausius|publisher=New York: Dover Publications, Inc.|year=1988|id=ISBN 0486446417}} #{{note|tribus}} M. Tribus, E.C. McIrvine, “Energy and information”, Scientific American, 224 (September 1971). #{{note|avery}}{{cite book|author= Avery, John|title=Information Theory and Evolution|publisher=World Scientific|year=2003|id=ISBN 9812384006}} </div>
This is not affected by ol.references { font-size: 90%;}. -- Ligulem 22:19, 7 May 2006 (UTC)
Is the intention in reducing the size simply to ape traditional print design, or specifically to visually indicate that the references are supplementary material? If references are smaller, then so should be other supplementary notes sections, including "See also", "External links", and "Further reading", as well as their headings, otherwise this is just inconsistent and certainly isn't an improvement. Let's not make major design changes to Wikipedia ad hoc and pell-mell.
By the way, why not just apply the keyword value "font-size: smaller;", which in modern browsers is the equivalent of 83.33% (=X/1.2). Since the default normal size in visual browsers is 16px, other useful values would be 93.75% (=15px) or 87.5% (=14px, which looks quite good in my browser). Relative sizes (relative keyword, em, or percentage) must be used, not absolute sizes (px, technically relative, but treated as absolute by most browsers).
If this format is to be applied reliably and flexibly throughout the Wikipedia, then someone should fix Bug 4741, so we can globally apply a style to all article sections called "References", and to their headings. — Michael Z. 2006-05-08 15:46 Z
The following CSS code should allow for dark/black wikitables and infoboxes. Significantly, this overrides the standard link colors so they'll work against a dark background.
This code should be placed below the existing wikitable CSS classes.
/* wikitable dark class for skinning tables/infoboxes */ table.wikitable.dark { background: #000000; color: #ffffff; } table.wikitable.dark th { background: #808080; } table.wikitable.dark a { color: #ffd447 !important; } table.wikitable.dark a:visited { color: #a5c969 !important; } table.wikitable.dark a:active { color: #0558ff !important; }
This code should be placed below the existing infobox CSS classes.
/* Infobox dark template style */ .infobox.dark { background-color: #000000; color: white; } .infobox.dark a { color: #ffd447 !important; } .infobox.dark a:visited { color: #a5c969 !important; } .infobox.dark a:active { color: #0558ff !important; }
If you'd like to see an example of this in use, please see User talk:Locke Cole/tvb. Please note that you'll need to copy the above CSS code into your userspace Monobook.css (or whichever skin you use). Note that the link colors are simply inversions of the existing link colors (hence why they're kind of ugly). If someone has a better idea for link colors, I'm all ears. =) But otherwise, I don't think there's anything else wrong with this (though I'd love some input from any CSS gurus out there). — Locke Cole • t • c 02:30, 5 May 2006 (UTC)
[[WikiLink|<span style="color: <new color>">WikiLink</span>]]
. Obviously it'd be nicer if you could specify a different CSS class and have all the links changed automatically. —
Locke Cole •
t •
c 21:11, 6 May 2006 (UTC)One week later and with no objection I'm requesting this be added. Whoever adds this, pleas be sure to place them as noted above. — Locke Cole • t • c 13:53, 12 May 2006 (UTC)
R. Koot, your change [12] specifically effected every browser except MSIE. Furthermore, the font you specified, Arial Unicode MS, has a serious bug affecting its display of some IPA. Please discuss changes to the style sheet before you make them. — Michael Z. 2006-05-06 18:27 Z
What are the style .LatinX and .MUFI? Where were these additions discussed? — Michael Z. 2006-05-06 18:31 Z
It is sometimes useful to use borderless tables for lists. See here for an example. However, with the Monobook skin, http://en.wikipedia.org/skins-1.5/monobook/main.css sets the background of all tables to white:
/* general styles */ table { background: white; font-size: 100%; color: black; }
(None of the other styles currently do this.) As far as I can tell, the best way to get the same background is with the CSS setting background: none
. You can, of course, use the HTML style
attribute:
{| border="0" style="background:none" ...
but I much prefer using a CSS class in situations like this. See
Village_pump_(technical)#CSS_setting_.22background:none.22 for some (ahem) background information (and note that background-color: inherit
does not work in
Internet Explorer v6.x).
I therefore propose adding something like
.same-bg { background: none }
to
MediaWiki:Common.css. (Or should it be added to
MediaWiki:Monobook.css? Or even to /skins-1.5/monobook/main.css
?). This class name is just a suggestion.
Comments, questions, suggestions, improvements, etc all welcome. Cheers, CWC (talk) 09:17, 9 May 2006 (UTC)
class=same-bg
in
m:Help:Table. We should probably also put a brief note about background colors in
Wikipedia:How_to_use_tables#Possible_problems.What is the advantage of removing this to the style sheet, rather than just using the inline style? I'm usually all for IDs and classes, but in this case it seems only to complicate the situation.
A suggestion: let's start naming table styles consistently (see also the stripes proposal below). How about prefixing all table styles with a "t-", and keeping them short and concise, as in class="t-nobg"
? —
Michael
Z. 2006-05-22 15:14 Z
table.same-bg
instead of simply .same-bg
. But regardless, I don't think we should go around creating single-attribute classes without having a reason beforehand; it's possible that a future browser will have trouble with style="background: transparent"
, sure, but it's also possible that a future browser will have trouble with style="color: red"
, or any other CSS attribute, or for that matter a problem with classes! We can't add all these things to the CSS, and every one we do add increases the size of a file that every viewer has to download by just that much.Please don't add this class to anything more until we've worked this out; classes can't be tracked down without great difficulty, and so if the class is removed from the stylesheet cleanup will be a bugger. — Simetrical ( talk • contribs) 22:32, 9 July 2006 (UTC)
Please add
.same-bg { background: none }
to MediaWiki:Common.css. Thanks, CWC (talk) 13:13, 3 June 2006 (UTC)
background: none
sets the background image to none
, not the background color, and so is superfluous (since background-images are generally impossible in MediaWiki). The correct CSS style is background: transparent
See
the W3C specs. Both appear to work in Firefox, but none
might not work as expected in all browsers, since it's not standards-compliant.background
is a sneaky attribute. It resets everything unspecified to its initial values, so what you have does work if you don't care about resetting all the image-related background stuff.In any case, the default for table background should be transparent. Look at Special:Movepage/Cat, for instance, for an example of the current Monobook's ugliness. But that's a Monobook question. — Simetrical ( talk • contribs) 22:32, 9 July 2006 (UTC)
Can we please stop this silly conflict over the font size of references? All of the same arguments in favor of 'variable reference size' could be applied to the size of general text in each article as well... yet we don't have ridiculous edit wars over that. Logically, any instance of someone customizing the footnotes to look 'just right' on their browser to their personal preferences is going to make them look 'just a little off' on someone else's browser to their personal preferences. Which is why we'd smack someone upside the head if they tried to hard code in sizing of the general text. So... everyone trying to manually set the footnote sizes 'just right' for your screens? Consider yourselves smacked upside the head. Everyone is going to have a different take on whether 90% or 100% or 92.374% or whatever is the 'just right' footnote size. It is therefor ridiculous to code these separately for each instance of footnoting. All it accomplishes is silly edit wars and a chaotic mess where everyone sometimes gets footnotes that look too small, sometimes too big, et cetera. Pick a percentage which seems 'ok' (maybe not 'just right', but 'ok') to most and apply that globally. Then people who actually care about three pixels height more or less can make adjustments in their local CSS or browser to set things so they look right. There is no way to manually set the font-size so that it looks right to everyone... so the only logical approach is to set a consistent size which is at least reasonable and allow each user to fine tune if they wish. Kind of like we do with the size of text in general. -- CBDunkerson 08:51, 11 May 2006 (UTC)
It still seems to be ill-thought through to me. A page with a smaller font for references, followed by see also and external links in the normal size looks bad. — Michael Z. 2006-05-22 15:20 Z
I agree. This arbitrary resizing or hiding of reference text in some articles but not others is irritating and counterproductive. We need to add something about this to the Manual of Style and start disciplining people who persist in edit warring over it. — Omegatron 13:54, 22 August 2006 (UTC)
I recently changed template:Infobox U.S. state so that a couple of the "rows" which were multiline elements (with labels and values effectively coincidentally appearing as "virtual rows") are actual rows in the table. Doing this requires making a couple of the rows neither bordered nor borderless, but "semi-bordered" with vertical cell separation but without row borders within a block of cells. Doing this within a single template is a little ugly, and the current version of template:Infobox U.S. state does not display as intended with IE (because IE does not support the border-top style in a TR). Looking at several of the templates in Category:Infobox templates I believe there are perhaps several dozen templates that could benefit from infobox styles for this purpose (perhaps called "toprow" and "mergedrow"), examples include:
In general, I suspect any template that derives from template:Infobox Country could use such styles. I don't pretend to be a CSS expert, but I think the following would have the right effect:
.infobox.bordered .toprow td, .infobox.bordered .toprow th { border: 0; border-top: 1px solid #aaaaaa; border-right: 1px solid #aaaaaa; } .infobox.bordered .mergedrow td, .infobox.bordered .mergedrow th { border: 0; border-right: 1px solid #aaaaaa; }
Comments please. -- Rick Block ( talk) 03:22, 16 May 2006 (UTC)
.wikitable mergedrowtop td, .wikitable mergedrowtop th, .infobox .mergedrowtop td, .infobox .mergedrowtop th { border: 0; border-top: 1px solid #aaaaaa; border-right: 1px solid #aaaaaa; padding-bottom: 0; } .wikitable mergedrow td, .wikitable mergedrow th, .infobox .mergedrow td, .infobox .mergedrow th { border: 0; border-right: 1px solid #aaaaaa; padding-top: 0; padding-bottom: 0; } .wikitable mergedrowbottom td, .wikitable mergedrowbottom th, .infobox .mergedrowbottom td, .infobox .mergedrowbottom th { border: 0; border-right: 1px solid #aaaaaa; padding-top: 0; }
Comments? − Woodstone 10:30, 26 May 2006 (UTC)
.infobox .mergedrow th { border-top-style: none; border-bottom-style: none; padding-top: 0; padding-bottom: 0; }
Excellent idea. This would even make it possible to slim down to:
.notop td, .notop th { border-top: 0; padding-top: 0; .nobottom td, .nobottom th{ border-bottom: 0; padding-bottom: 0; }
In a top row one would set class="nobottom", in a middle row class="notop nobottom", and in a bottom row class="notop". This could be applied for any kind of table. − Woodstone 16:08, 3 June 2006 (UTC)
There is a lot of heat/light on this topic which mixes several different issues: which font size is best for references, whether a certain change should have been made, whether it should be reverted, whether different articles should have different reference sizes. Perhaps a simple straw change on one question would help see where the community stands: which font size is preferable for reference/footnote sections of articles. Leave aside whether enforcing any change immediately would break FAs - let's just establish the desired end result: Stevage 13:07, 18 May 2006 (UTC)
Font sizes should never be other than 90% for footnotes.
No templates or <div>s, just a stylesheet specification (whether 100% or smaller). Or if it's done per-article, at the very least make sure it's a template so that it can be easily changed or removed if we change our minds later.
<references/>
in a div
element, using a template in non-subst mode etc). Now we have a chance to remedy. What I question is the very same idea of choosing styles on a per article basis. If we agree that this should not be done then everything follows as a consequence: MediaWiki decides the class (the same for all articles) and logged-in users possibly override its attributes." --
Gennaro Prota
•Talk 15:06, 18 May 2006 (UTC)-- Ligulem 07:00, 19 May 2006 (UTC)"Formatting issues such as font size, blank space and color are issues for the Wikipedia site-wide style sheet and should not be dealt with in articles except in special cases. If you absolutely must specify a font size, use a relative size, that is, font-size: 80%; not an absolute size, for example, font-size: 4pt."
Can someone add to table.wikitable font-size: 95% and change the padding to 0.4em? The table looks very "thin" and big right now and it is not aesthetically pleasing. Class="wikitable" looks so bad now that people are just not using it anymore and have gone back to using custom styled tables, which is exactly what we are trying to avoid in Wikipedia by using a Common style. For a comparison between the current style and what I'm proposing, see User:CieloEstrellado/tmp ☆ CieloEstrellado 03:14, 19 May 2006 (UTC)
table.wikitable {font-size: 95%;}
to
User:CieloEstrellado/monobook.css —
Omegatron 20:56, 20 May 2006 (UTC)Header cell of a table |
---|
Content cell of a table |
Hey all. I thought that people who watch this page may be interested in a proposal that I've posted on Wikipedia:Village pump (proposals) about striping wikitables. It involves changing CSS and JS. It's posted here: Village_pump_%28proposals%29#Proposal:_striped_table_CSS_class_.2B_JS. — Michiel Sikma, 05:21, 22 May 2006 (UTC)
I've read over the discussion here, but it's a bit unclear to me as to what exactly the references class was originally meant for. I thought it was just for footnotes (in long notes sections), and not reference sections, but that isn't clear. Could someone confirm that for me? -- Spangineer [es] (háblame) 13:11, 22 May 2006 (UTC)
I bring it up because I hadn't seen this before (no FAs to my knowledge until just recently), and the reason for shrinking the text in the notes sections (having really long notes sections) doesn't often apply to references or further reading sections. I'd recommend leaving this to the individual authors of the articles to decide if it warrants shrinking or not, but in general I don't think they should be. -- Spangineer [es] (háblame) 20:23, 22 May 2006 (UTC)
For what it's worth, I've created {{ references-small}} which adds a references block in the small style. Stevage 10:32, 23 May 2006 (UTC)
The class "references-small" is named after its presumed presentation in a visual browser. This is contrary to good authoring practices for semantic/structural HTML. In text-only browsers and audible screen readers, this text will not be smaller, but it may be given a different colour, font weight, tone, pitch, etc. We may decide to use the same format for sections other than "References", including Notes, Further reading, See also, and External links, e.g. supplementary sections.
I propose renaming the class "s-supp", an abbreviation of "section, supplementary". Other future classes intended to apply to sections of an article could also be named with the s- prefix.
References:
— Michael Z. 2006-05-23 14:44 Z
Could some admin please put a link to CSS somewhere in the comment section on the top? This would help the newbies learning what CSS is. Thanks! -- Ligulem 17:03, 25 May 2006 (UTC)
I created a syntax highlighting proposal a while ago, at WP:VPR#Syntax Coloring. It seemed to making some headway, but Rick Block suggested I move it here:
Currently, source code in Wikipedia looks rather dull:
/* * This is fake Java code to demonstrate syntax coloring. * */ public static void main(String[] args) { String s = new String("This is a test"); char ch = 'c' + 123; }
Would it be better if syntax coloring could be applied to the code? Here is an example:
/* * This is fake Java code to demonstrate syntax coloring. * */ public static void main(String[] args) { String s = new String("This is a test"); char ch = 'c' + 123; }
To implement this, I had to use several <span>
tags to achieve this, which makes the code almost incomprehensible. What I am suggesting is a modification to
MediaWiki:Common.css or
MediaWiki:Monobook.css. We would define styles for various types of words in a syntax block:
/* CSS code */ syntax key { color:blue; font-weight:bold;} syntax string {color: maroon;} syntax char {color: orange;} syntax number {color: teal;} syntax comment {color: green;}
In the source code, we could simply write out:
<syntax> <comment>/** this is a comment</comment> <string>"Hey there!"</string> </syntax>
This makes future editing much simpler. If a certain user wished to customize the colors and styles, or turn them off, all he would need to do is modify his own CSS file. This would also pave the way for a possible syntax highlighting tool, much like the <math> tool. The parser would already have the styles in place.
Please, relay your thoughts to me. -- Max Talk (add) 04:04, 23 May 2006 (UTC)
The earliest comments are still on the original page. Unsure of policy on this issue, I felt it was best not to copy their comments over.-- Max Talk (add) 06:26, 26 May 2006 (UTC)
This is fake Java code to demonstrate syntax coloring.
public static void main(String[] args) { String s = new String("This is a test"); char ch = 'c' + 123; }
I already have a syntax highlighter for CSS
in my javascript. Look for /* Syntax highlighting on pre areas */
. —
Omegatron 14:39, 22 August 2006 (UTC)
Does anyone object to adding
* { font-family: "Arial Unicode MS", "Lucida Sans Unicode", sans-serif; font-family /**/:inherit; } textarea { font-family: "Arial Unicode MS", "Lucida Sans Unicode", monospace; font-family /**/:monospace; } pre { font-family: monospace; }
to Common.css? Disadvantage (Internet Explorer only): it overides the font selected by the user in their browser preferences, and can only be re-overridden by changing their own monobook.css. Advantage: it avoids situations such as this, this and probably many more. — Ruud 01:03, 27 May 2006 (UTC)
According to Arial Unicode MS, it does not support smoothing in the 14-18 pt range :/ (Strange, as Linux does smooth this font, how can smoothing be disabled for a certain range anyway? Why can't Microsoft just make something without bugs?) — Ruud 18:26, 27 May 2006 (UTC)
Hi guys,
after an enervating discussion at template talk:languageicon we couldn't find any consensus on the final appearance of link language indications. However there were many requests for a less flashy design; thus I ask to add the following class to common.css, so that anyone wanting a more sober design can obtain it via his personal style sheet:
.language-indication { cursor: default; font-family: sans-serif; font-size: 0.84em; font-weight: bold; color: navy; position: relative; bottom: 0.08em; }
This leaves the default aspect as it is now. Thanks — Gennaro Prota •Talk 18:30, 2 June 2006 (UTC)
I think it is time to remove the hiddenStructure class. This was originally incorporated here as an alternative to {{ qif}} for hiding conditional text in templates. However, there are a number of accessibility problems with this method and it has been obsolete since m:ParserFunctions were introduced as a built-in way of performing the same tasks. Most of the existing uses of 'hiddenStructure' were converted to the '#if:' parser function weeks ago without incident. There are doubtless some pages still using hiddenStructure, but I think it would take minimal time to locate and convert them once the class is removed. Perhaps some sort of public notice could be given that some templates may stop hiding conditional text and info on where to go for help converting them. Thoughts? -- CBDunkerson 10:44, 8 June 2006 (UTC)
I want to use the prettytable settings on my wiki. My brute force approach was to copy http://en.wikipedia.org/wiki/Wikipedia:Common.css to my Common.css page, but this hasn't worked. Does anyone know how I can make something like this work? I am using MediaWiki 1.6.7. dryguy 19:24, 19 June 2006 (UTC)
Thanks! Worked nicely. dryguy 02:21, 21 June 2006 (UTC)
Talk page notices are currently set at a standard width of 80%. Looking at the spectrum of talk page templates in use in en:Wikipedia, this is creating inconsistencies. It also, in my opinion, makes less than optimal use of the page. The border and colored background is sufficient to draw attention to these notices. Limiting the width to 80% is unnecessary. I would like to reset this default to 100%. Rossami (talk) 13:29, 24 June 2006 (UTC)
Comparison (100, 85, 80% respectively, from Template:Vblock; 80% is the current standard): — Simetrical ( talk • contribs) 01:19, 11 August 2006 (UTC)
I motion to change the standard to 85%. This will bring us consistancy with the style guideline and slightly more efficient use of page space. Kaldari 01:28, 11 August 2006 (UTC)
Anyone care if I add some infobox styles in support of the proposed Wikipedia:Geographical infoboxes guideline? I'd like to add an infobox style and some sub-styles (as in User:Rick Block/monobook.css) for use with infoboxes for geographical places. I have a modified version of Template:Infobox U.S. state in user:Rick Block/Infobox U.S. state if anyone would like to see what it might look like. Thanks. -- Rick Block ( talk) 01:58, 2 July 2006 (UTC)
Please see Wikipedia talk:Image copyright tags#Template standardization for discussion on standardizing these templates. — Simetrical ( talk • contribs) 02:08, 10 August 2006 (UTC)
Can anyone tell me what efforts are being made to keep consistancy between these two (and other
sister projects) with respect to this rather important central resource?
Why isn't there a master copy from Meta controlling?
Or at least the same master used on both the English language defaulted commons and this en.wikipedia (The hands down 800# gorrilla of wikipedia's by article count!)<g>
I'm curious, in that some text templates that were debugged and working fine are now evincing a variety of display issues including total disfunctionality.
One of these manifested two weeks back (square 'undef'd character', irrc, seen first on the commons) before my vacation trip. I've been tripping on others since last evening on both sister projects. The sqaure 'undef'd' char box seems to point logically directly to this (
Commons:MediaWiki:Common.css) specific resource.
See:
this if you care to help sort through this vexation and are a code guru.
While I didn't put that up for general consumption, in a nutshell, if it's not shown in bold (indicating a display 'nowiki' block, and hence the desired display effect) one should not be seeing any {s}, {space}, or {i} or {indent} manifestations in the captured HTML.
Something prior to reverts (about 18:00, 17 August 2006) was causing total dysfunction. (Note: This post is heavily indented using the now 2X reverted
1 {{
Indent}} [called via the {{
I}} 'eye' template]). //
Fra
nkB 20:00, 17 August 2006 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
Per my Village Pump proposal, I'm going to be adding a bit of CSS to enable the creation of metadata (ala Personendaten in the German Wikipedia). This will allow us to try out some metadata schemes and hopefully implement some in the future. See this article for more info. Kaldari 19:27, 22 December 2005 (UTC)
See Template talk:Dynamic navigation box. Monobook contains the code missing in other CSS. -- User:Docu
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 Wikipedia:Village pump (technical)#Bug in Monobook.css there appear to be two errors in Common.css:
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):
Most other images are fine, and IE seems Ok with these. - Wikibob 03:54, 13 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 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 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)
<div class="outer frame">
<div class="inner frame">Image goes here</div> <div class="caption">Caption goes here</div>
</div>
<div class="thumb">
<div style="width:WIDTH SET HERE"> Image goes here <div class="thumbcaption">Caption here</div> </div>
</div>
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 [3]. 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.
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
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." [4] 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)
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 [[clock|clocks]] instead of the perfectly correct code [[clock]]s, 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)
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. → Aza Toth 22:01, 27 January 2006 (UTC)
{| |- | {| |- | |} |- | |}
table | |--tbody | |--tr | | | |--td | | | |--table | | | |--tbody | | | |--tr | | | |--td |--tr | |--td
table > tbody > tr > td
etc...) →
Aza
Toth 19:20, 30 January 2006 (UTC)
{| 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... |} |- | |}
A B
means B descendant of A, A > B
means B child of A. →
Aza
Toth 22:10, 30 January 2006 (UTC)
I'm can agree with a compromize, create a new rule .wikitable2 that are using my specification. → Aza Toth 09:06, 15 February 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)
<span style="text-decoration: none;">[[Article]]</span>
:
Article. →
Aza
Toth 23:31, 28 January 2006 (UTC)
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
filter: alpha(opacity=85); /* for Internet Explorer */ -moz-opacity: 0.85; /* for Firefox etc. */ opacity: 0.85; /* CSS3: for Mozilla and Safari */
The problem: We want a way to briefly link to audio files, like so:
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:
(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:
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 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)
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)
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)
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)
#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; }
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
"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
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:
<span class="PDFlink">[http://www.example.org/differentpdffile.pdf a PDF file]</span>
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:
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)
#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; }
Any opposition to me adding this for the benefit of those of us whose browsers support it? — Omegatron 14:50, 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: {{ 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 [5] or [6], was deleted based on the rationale here. Trademark vs copyright. The {{ 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:
Also, as explained here, we can change the {{ 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:)
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 {{ 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 {{ PDFlink}}, which does effectively the same thing, passed a TfD, so it should go smoothly. — Omegatron 23:40, 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
filter: alpha(opacity=85); /* for Internet Explorer */ -moz-opacity: 0.85; /* for Firefox etc. */ opacity: 0.85; /* CSS3: for Mozilla and Safari */
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
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)
Size | as is | 0 | 0.1em | 0.2em | 0.3em | 0.4em | 0.5em | 1em | 1ex | ← horizontal padding |
---|---|---|---|---|---|---|---|---|---|---|
as is | 1,234,567 | |||||||||
0 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.2em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.3em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.4em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
0.5em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
1ex | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | ||
↑ vertical padding |
Size | as is | 0 | 0.1em | 0.2em | 0.3em | 0.4em | 0.5em | 1em | 1ex |
---|---|---|---|---|---|---|---|---|---|
as is | 1,234,567 | ||||||||
0 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.2em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.3em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.4em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
0.5em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
1em | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | |
1ex | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 | 1,234,567 |
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 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)
What are we doing with this? Is this a go or no go? howch e ng { chat} 00:08, 8 March 2006 (UTC)
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 :)
→ Aza Toth 00:46, 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)
Why is scrolling the pre so much better?
Please don't use overflow-y. It's not supported in many browsers, including Internet Explorer 6.0 and Safari 2.0. Use overflow instead, which works almost just as well and is supported by all modern browsers. — Michiel Sikma, 13:05, 13 May 2006 (UTC)
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)
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:
If you turn off CSS, they just look like lists:
Questions:
Feedback:
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 {{ 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; }
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;}
sup small, sub small {font-size: inherit;}
In concert with MediaWiki talk:Monobook.css#Coordinates in article heading, Wikipedia talk:WikiProject Geographical coordinates#Coordinates at the top of the article, and bug 4719, need something like:
/* Do not expand kvaleberg.com-URLs for printing */ #content span.coordinates a.external.text:after, #content span.coordinates a.external.autonumber:after { content: ""; }
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 " 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)
A proposal that came out the Main Page Redesign discussions was:
This would be to aid new users in finding the search box.
#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)
-- James S. 22:57, 11 April 2006 (UTC)
...as explained here: wikipedia talk:footnotes#Resizing footnotes - what is going on?, there was no community consensus to do that.
Please also see and/or contribute to (ongoing) discussions at:
AFAIK, (from what I read in these discussion places), the size of footnotes was reduced to 90% in a solo-action by R. Koot ( diff), so please revert it until consensus shows this would be a good idea (not the case currently). -- Francis Schonken 10:11, 4 May 2006 (UTC)
I totally agree with Hoary. 90% on Hiroh Kikai is insane (I've corrected that temporarily to 100% in that article). Putting everything down to 90% doesn't work. Let's do the small-references class as I proposed below. -- Ligulem 09:35, 6 May 2006 (UTC)
Like in subject. This imposition is definitely not consensus, and causes problems for lots of people. Think disability community, for example; but also just pages that already use sizing of notes (which I don't think is a good idea either, but it's article-by-article). If users want custom CSS, that's fine, but don't impose disruptive CSS on all readers. LotLE× talk 19:08, 4 May 2006 (UTC)
If ol.references { font-size: 90%; }
is removed, could we then at least agree to add .references-small { font-size: 90%;}
and use that class on all those articles that want the smaller font? I think adding references-small doesn't hurt that much, right? This would at least eliminate the absolutely uneeded difference between 85% and 90%. Plus no need to hard code that into articles (or templates). --
Ligulem 22:10, 4 May 2006 (UTC)
.references-small { font-size: 90%;}
. I'm trying to find a compromise that is acceptable for all. If everybody here insists on his position, then we just risk that ol.references { font-size: 90%; }
is removed and we are where we were before. Which is cleary not satisfactorily. But I must concede that I by myself was astonished that ol.references { font-size: 90%; }
was added to Common.css. Of course it was a surprise for me and I would be more than happy with that. But as you see, there are others here which are not happy with that at all. So I agree that this is no consensus for plain ol.references { font-size: 90%; }
. So if there is an admin that removes ol.references { font-size: 90%; }
I urge to add .references-small { font-size: 90%; }
as a replacement. Just for the records: I'm not an admin. --
Ligulem 10:15, 5 May 2006 (UTC)<references />
inside a DIV tag that modified the text size. This is non-uniform, and probably undesirable because some pages end up using 100%, some end up using 85%, and still others use values from 90-95% of the standard font size. By having this in a CSS class, we can affect all usage of references at once (or, as Ligulem suggests, at least provide a CSS class so pages will just use <div class="references-small"><references /></div>
). Of course it'll be more challenging to get people to use .references-small, and it still leads to some articles being 100% and others being whatever .references-small is set to.. but it's still better than using a template to do this (especially since the template is subst'd, making it impossible to update or change without going through and re-subst'ing them again). —
Locke Cole •
t •
c 02:21, 5 May 2006 (UTC)Part of this problem has been caused by me, but resulting from something completely different than the resizing issue: one of the complexities of this problem was caused by the fact that both the {{ Footnotes}} and the {{ FootnotesSmall}} templates were instructed to be used by a "subst:" (placing a lot of "div" tags in article namespace, that can't be undone by changing the template content). The reason for this has nothing to do with RESIZING but with the "help" comment included in these templates that doesn't become visible in edit mode unless with a "subst:" being applied to the template previously.
Here's a solution I'd like to elaborate (doesn't clean up the size-reducing div tags now in article namespace, but might be a better solution for the future).
PLEASE GIVE ME SOME TIME TO TRY THIS OUT
Here's a short description. Might seem complicated at first sight, but in fact it's quite simple, and adresses the issue, independent from the technique (css or "div") used for resizing:
Also needs rewriting the instructions regarding the use of these templates on wikipedia:footnotes, but I'll try to make this work technically first. -- Francis Schonken 14:54, 5 May 2006 (UTC)
<resize=whatever_I_like>
is contrary to the spirit of both the template and of the css, i.e. having a *consistent* formatting in all articles. The class references-small just changes the font size: if I can specify a different size anyway, then what is its purpose? I would prefer sticking with something between 92% and 95% (or maybe simply <small> </small>
) and remove the resize parameter; one can always enlarge the whole page text with the scroll of a wheel, or a menu click, after all. --
Gennaro Prota
(talk) 23:34, 8 May 2006 (UTC)To the admins or sysops: as you can read here and on the Village Pump technical page, there is no and never has been a consensus on changing the footnotes size. Please revert it for now until a consensus has been reached, as the change should not have been made in the first place. — Michiel Sikma, 10:58, 6 May 2006 (UTC)
Anyway, as a temporary solution, I made {{ FootnotesSmall}} work according to the solution explained above. This solution currently uses div tags with style="font-size:...%", but adjusts correctly (with a workaround solution):
Further, I note that some admins refuse to follow established consensus on wikipedia talk:footnotes, and the actual text of the Footnotes guideline that does not recognise that the <references/> tag should in any way resize the text of the references. These admins abuse their power, and that's as simple as that. I mean, I don't need admin powers to help guidelines and policies materialize (and I do quite some of that). Admins refusing to adjust the css according to these guidelines and policies is a completely different cup of tea. It won't make me pursue to become an admin (yet), for such one-off anomaly. I had some previous example of Ruud Koot's anti-wiki behaviour of trying to impose a solution by forced means against community consensus, and would still be able to document the strain he put on the wikipedia community then. With this new case, maybe time to ask Ruud's deposition as a sysop (whatever his other, more positive, contributions to wikipedia).
Please let me know when the css is updated. I'll not continue to follow this page, but might further promote the solution that resizes with div tags for having normal size of footnotes, although currently that is a deplorable workaround. So please let me know when the css is up-to-date, and I'll reverse these solutions, and assist to make a more elegant resizing template. -- Francis Schonken 16:55, 7 May 2006 (UTC)
What should be done with History of entropy, which contains:
<div style="font-size:85%"> #{{note|Mendoza}} {{cite book|author=Mendoza, E. |title=Reflections on the Motive Power of Fire – and other Papers on the Second Law of Thermodynamics by E. Clapeyron and R. Clausius|publisher=New York: Dover Publications, Inc.|year=1988|id=ISBN 0486446417}} #{{note|tribus}} M. Tribus, E.C. McIrvine, “Energy and information”, Scientific American, 224 (September 1971). #{{note|avery}}{{cite book|author= Avery, John|title=Information Theory and Evolution|publisher=World Scientific|year=2003|id=ISBN 9812384006}} </div>
This is not affected by ol.references { font-size: 90%;}. -- Ligulem 22:19, 7 May 2006 (UTC)
Is the intention in reducing the size simply to ape traditional print design, or specifically to visually indicate that the references are supplementary material? If references are smaller, then so should be other supplementary notes sections, including "See also", "External links", and "Further reading", as well as their headings, otherwise this is just inconsistent and certainly isn't an improvement. Let's not make major design changes to Wikipedia ad hoc and pell-mell.
By the way, why not just apply the keyword value "font-size: smaller;", which in modern browsers is the equivalent of 83.33% (=X/1.2). Since the default normal size in visual browsers is 16px, other useful values would be 93.75% (=15px) or 87.5% (=14px, which looks quite good in my browser). Relative sizes (relative keyword, em, or percentage) must be used, not absolute sizes (px, technically relative, but treated as absolute by most browsers).
If this format is to be applied reliably and flexibly throughout the Wikipedia, then someone should fix Bug 4741, so we can globally apply a style to all article sections called "References", and to their headings. — Michael Z. 2006-05-08 15:46 Z
The following CSS code should allow for dark/black wikitables and infoboxes. Significantly, this overrides the standard link colors so they'll work against a dark background.
This code should be placed below the existing wikitable CSS classes.
/* wikitable dark class for skinning tables/infoboxes */ table.wikitable.dark { background: #000000; color: #ffffff; } table.wikitable.dark th { background: #808080; } table.wikitable.dark a { color: #ffd447 !important; } table.wikitable.dark a:visited { color: #a5c969 !important; } table.wikitable.dark a:active { color: #0558ff !important; }
This code should be placed below the existing infobox CSS classes.
/* Infobox dark template style */ .infobox.dark { background-color: #000000; color: white; } .infobox.dark a { color: #ffd447 !important; } .infobox.dark a:visited { color: #a5c969 !important; } .infobox.dark a:active { color: #0558ff !important; }
If you'd like to see an example of this in use, please see User talk:Locke Cole/tvb. Please note that you'll need to copy the above CSS code into your userspace Monobook.css (or whichever skin you use). Note that the link colors are simply inversions of the existing link colors (hence why they're kind of ugly). If someone has a better idea for link colors, I'm all ears. =) But otherwise, I don't think there's anything else wrong with this (though I'd love some input from any CSS gurus out there). — Locke Cole • t • c 02:30, 5 May 2006 (UTC)
[[WikiLink|<span style="color: <new color>">WikiLink</span>]]
. Obviously it'd be nicer if you could specify a different CSS class and have all the links changed automatically. —
Locke Cole •
t •
c 21:11, 6 May 2006 (UTC)One week later and with no objection I'm requesting this be added. Whoever adds this, pleas be sure to place them as noted above. — Locke Cole • t • c 13:53, 12 May 2006 (UTC)
R. Koot, your change [12] specifically effected every browser except MSIE. Furthermore, the font you specified, Arial Unicode MS, has a serious bug affecting its display of some IPA. Please discuss changes to the style sheet before you make them. — Michael Z. 2006-05-06 18:27 Z
What are the style .LatinX and .MUFI? Where were these additions discussed? — Michael Z. 2006-05-06 18:31 Z
It is sometimes useful to use borderless tables for lists. See here for an example. However, with the Monobook skin, http://en.wikipedia.org/skins-1.5/monobook/main.css sets the background of all tables to white:
/* general styles */ table { background: white; font-size: 100%; color: black; }
(None of the other styles currently do this.) As far as I can tell, the best way to get the same background is with the CSS setting background: none
. You can, of course, use the HTML style
attribute:
{| border="0" style="background:none" ...
but I much prefer using a CSS class in situations like this. See
Village_pump_(technical)#CSS_setting_.22background:none.22 for some (ahem) background information (and note that background-color: inherit
does not work in
Internet Explorer v6.x).
I therefore propose adding something like
.same-bg { background: none }
to
MediaWiki:Common.css. (Or should it be added to
MediaWiki:Monobook.css? Or even to /skins-1.5/monobook/main.css
?). This class name is just a suggestion.
Comments, questions, suggestions, improvements, etc all welcome. Cheers, CWC (talk) 09:17, 9 May 2006 (UTC)
class=same-bg
in
m:Help:Table. We should probably also put a brief note about background colors in
Wikipedia:How_to_use_tables#Possible_problems.What is the advantage of removing this to the style sheet, rather than just using the inline style? I'm usually all for IDs and classes, but in this case it seems only to complicate the situation.
A suggestion: let's start naming table styles consistently (see also the stripes proposal below). How about prefixing all table styles with a "t-", and keeping them short and concise, as in class="t-nobg"
? —
Michael
Z. 2006-05-22 15:14 Z
table.same-bg
instead of simply .same-bg
. But regardless, I don't think we should go around creating single-attribute classes without having a reason beforehand; it's possible that a future browser will have trouble with style="background: transparent"
, sure, but it's also possible that a future browser will have trouble with style="color: red"
, or any other CSS attribute, or for that matter a problem with classes! We can't add all these things to the CSS, and every one we do add increases the size of a file that every viewer has to download by just that much.Please don't add this class to anything more until we've worked this out; classes can't be tracked down without great difficulty, and so if the class is removed from the stylesheet cleanup will be a bugger. — Simetrical ( talk • contribs) 22:32, 9 July 2006 (UTC)
Please add
.same-bg { background: none }
to MediaWiki:Common.css. Thanks, CWC (talk) 13:13, 3 June 2006 (UTC)
background: none
sets the background image to none
, not the background color, and so is superfluous (since background-images are generally impossible in MediaWiki). The correct CSS style is background: transparent
See
the W3C specs. Both appear to work in Firefox, but none
might not work as expected in all browsers, since it's not standards-compliant.background
is a sneaky attribute. It resets everything unspecified to its initial values, so what you have does work if you don't care about resetting all the image-related background stuff.In any case, the default for table background should be transparent. Look at Special:Movepage/Cat, for instance, for an example of the current Monobook's ugliness. But that's a Monobook question. — Simetrical ( talk • contribs) 22:32, 9 July 2006 (UTC)
Can we please stop this silly conflict over the font size of references? All of the same arguments in favor of 'variable reference size' could be applied to the size of general text in each article as well... yet we don't have ridiculous edit wars over that. Logically, any instance of someone customizing the footnotes to look 'just right' on their browser to their personal preferences is going to make them look 'just a little off' on someone else's browser to their personal preferences. Which is why we'd smack someone upside the head if they tried to hard code in sizing of the general text. So... everyone trying to manually set the footnote sizes 'just right' for your screens? Consider yourselves smacked upside the head. Everyone is going to have a different take on whether 90% or 100% or 92.374% or whatever is the 'just right' footnote size. It is therefor ridiculous to code these separately for each instance of footnoting. All it accomplishes is silly edit wars and a chaotic mess where everyone sometimes gets footnotes that look too small, sometimes too big, et cetera. Pick a percentage which seems 'ok' (maybe not 'just right', but 'ok') to most and apply that globally. Then people who actually care about three pixels height more or less can make adjustments in their local CSS or browser to set things so they look right. There is no way to manually set the font-size so that it looks right to everyone... so the only logical approach is to set a consistent size which is at least reasonable and allow each user to fine tune if they wish. Kind of like we do with the size of text in general. -- CBDunkerson 08:51, 11 May 2006 (UTC)
It still seems to be ill-thought through to me. A page with a smaller font for references, followed by see also and external links in the normal size looks bad. — Michael Z. 2006-05-22 15:20 Z
I agree. This arbitrary resizing or hiding of reference text in some articles but not others is irritating and counterproductive. We need to add something about this to the Manual of Style and start disciplining people who persist in edit warring over it. — Omegatron 13:54, 22 August 2006 (UTC)
I recently changed template:Infobox U.S. state so that a couple of the "rows" which were multiline elements (with labels and values effectively coincidentally appearing as "virtual rows") are actual rows in the table. Doing this requires making a couple of the rows neither bordered nor borderless, but "semi-bordered" with vertical cell separation but without row borders within a block of cells. Doing this within a single template is a little ugly, and the current version of template:Infobox U.S. state does not display as intended with IE (because IE does not support the border-top style in a TR). Looking at several of the templates in Category:Infobox templates I believe there are perhaps several dozen templates that could benefit from infobox styles for this purpose (perhaps called "toprow" and "mergedrow"), examples include:
In general, I suspect any template that derives from template:Infobox Country could use such styles. I don't pretend to be a CSS expert, but I think the following would have the right effect:
.infobox.bordered .toprow td, .infobox.bordered .toprow th { border: 0; border-top: 1px solid #aaaaaa; border-right: 1px solid #aaaaaa; } .infobox.bordered .mergedrow td, .infobox.bordered .mergedrow th { border: 0; border-right: 1px solid #aaaaaa; }
Comments please. -- Rick Block ( talk) 03:22, 16 May 2006 (UTC)
.wikitable mergedrowtop td, .wikitable mergedrowtop th, .infobox .mergedrowtop td, .infobox .mergedrowtop th { border: 0; border-top: 1px solid #aaaaaa; border-right: 1px solid #aaaaaa; padding-bottom: 0; } .wikitable mergedrow td, .wikitable mergedrow th, .infobox .mergedrow td, .infobox .mergedrow th { border: 0; border-right: 1px solid #aaaaaa; padding-top: 0; padding-bottom: 0; } .wikitable mergedrowbottom td, .wikitable mergedrowbottom th, .infobox .mergedrowbottom td, .infobox .mergedrowbottom th { border: 0; border-right: 1px solid #aaaaaa; padding-top: 0; }
Comments? − Woodstone 10:30, 26 May 2006 (UTC)
.infobox .mergedrow th { border-top-style: none; border-bottom-style: none; padding-top: 0; padding-bottom: 0; }
Excellent idea. This would even make it possible to slim down to:
.notop td, .notop th { border-top: 0; padding-top: 0; .nobottom td, .nobottom th{ border-bottom: 0; padding-bottom: 0; }
In a top row one would set class="nobottom", in a middle row class="notop nobottom", and in a bottom row class="notop". This could be applied for any kind of table. − Woodstone 16:08, 3 June 2006 (UTC)
There is a lot of heat/light on this topic which mixes several different issues: which font size is best for references, whether a certain change should have been made, whether it should be reverted, whether different articles should have different reference sizes. Perhaps a simple straw change on one question would help see where the community stands: which font size is preferable for reference/footnote sections of articles. Leave aside whether enforcing any change immediately would break FAs - let's just establish the desired end result: Stevage 13:07, 18 May 2006 (UTC)
Font sizes should never be other than 90% for footnotes.
No templates or <div>s, just a stylesheet specification (whether 100% or smaller). Or if it's done per-article, at the very least make sure it's a template so that it can be easily changed or removed if we change our minds later.
<references/>
in a div
element, using a template in non-subst mode etc). Now we have a chance to remedy. What I question is the very same idea of choosing styles on a per article basis. If we agree that this should not be done then everything follows as a consequence: MediaWiki decides the class (the same for all articles) and logged-in users possibly override its attributes." --
Gennaro Prota
•Talk 15:06, 18 May 2006 (UTC)-- Ligulem 07:00, 19 May 2006 (UTC)"Formatting issues such as font size, blank space and color are issues for the Wikipedia site-wide style sheet and should not be dealt with in articles except in special cases. If you absolutely must specify a font size, use a relative size, that is, font-size: 80%; not an absolute size, for example, font-size: 4pt."
Can someone add to table.wikitable font-size: 95% and change the padding to 0.4em? The table looks very "thin" and big right now and it is not aesthetically pleasing. Class="wikitable" looks so bad now that people are just not using it anymore and have gone back to using custom styled tables, which is exactly what we are trying to avoid in Wikipedia by using a Common style. For a comparison between the current style and what I'm proposing, see User:CieloEstrellado/tmp ☆ CieloEstrellado 03:14, 19 May 2006 (UTC)
table.wikitable {font-size: 95%;}
to
User:CieloEstrellado/monobook.css —
Omegatron 20:56, 20 May 2006 (UTC)Header cell of a table |
---|
Content cell of a table |
Hey all. I thought that people who watch this page may be interested in a proposal that I've posted on Wikipedia:Village pump (proposals) about striping wikitables. It involves changing CSS and JS. It's posted here: Village_pump_%28proposals%29#Proposal:_striped_table_CSS_class_.2B_JS. — Michiel Sikma, 05:21, 22 May 2006 (UTC)
I've read over the discussion here, but it's a bit unclear to me as to what exactly the references class was originally meant for. I thought it was just for footnotes (in long notes sections), and not reference sections, but that isn't clear. Could someone confirm that for me? -- Spangineer [es] (háblame) 13:11, 22 May 2006 (UTC)
I bring it up because I hadn't seen this before (no FAs to my knowledge until just recently), and the reason for shrinking the text in the notes sections (having really long notes sections) doesn't often apply to references or further reading sections. I'd recommend leaving this to the individual authors of the articles to decide if it warrants shrinking or not, but in general I don't think they should be. -- Spangineer [es] (háblame) 20:23, 22 May 2006 (UTC)
For what it's worth, I've created {{ references-small}} which adds a references block in the small style. Stevage 10:32, 23 May 2006 (UTC)
The class "references-small" is named after its presumed presentation in a visual browser. This is contrary to good authoring practices for semantic/structural HTML. In text-only browsers and audible screen readers, this text will not be smaller, but it may be given a different colour, font weight, tone, pitch, etc. We may decide to use the same format for sections other than "References", including Notes, Further reading, See also, and External links, e.g. supplementary sections.
I propose renaming the class "s-supp", an abbreviation of "section, supplementary". Other future classes intended to apply to sections of an article could also be named with the s- prefix.
References:
— Michael Z. 2006-05-23 14:44 Z
Could some admin please put a link to CSS somewhere in the comment section on the top? This would help the newbies learning what CSS is. Thanks! -- Ligulem 17:03, 25 May 2006 (UTC)
I created a syntax highlighting proposal a while ago, at WP:VPR#Syntax Coloring. It seemed to making some headway, but Rick Block suggested I move it here:
Currently, source code in Wikipedia looks rather dull:
/* * This is fake Java code to demonstrate syntax coloring. * */ public static void main(String[] args) { String s = new String("This is a test"); char ch = 'c' + 123; }
Would it be better if syntax coloring could be applied to the code? Here is an example:
/* * This is fake Java code to demonstrate syntax coloring. * */ public static void main(String[] args) { String s = new String("This is a test"); char ch = 'c' + 123; }
To implement this, I had to use several <span>
tags to achieve this, which makes the code almost incomprehensible. What I am suggesting is a modification to
MediaWiki:Common.css or
MediaWiki:Monobook.css. We would define styles for various types of words in a syntax block:
/* CSS code */ syntax key { color:blue; font-weight:bold;} syntax string {color: maroon;} syntax char {color: orange;} syntax number {color: teal;} syntax comment {color: green;}
In the source code, we could simply write out:
<syntax> <comment>/** this is a comment</comment> <string>"Hey there!"</string> </syntax>
This makes future editing much simpler. If a certain user wished to customize the colors and styles, or turn them off, all he would need to do is modify his own CSS file. This would also pave the way for a possible syntax highlighting tool, much like the <math> tool. The parser would already have the styles in place.
Please, relay your thoughts to me. -- Max Talk (add) 04:04, 23 May 2006 (UTC)
The earliest comments are still on the original page. Unsure of policy on this issue, I felt it was best not to copy their comments over.-- Max Talk (add) 06:26, 26 May 2006 (UTC)
This is fake Java code to demonstrate syntax coloring.
public static void main(String[] args) { String s = new String("This is a test"); char ch = 'c' + 123; }
I already have a syntax highlighter for CSS
in my javascript. Look for /* Syntax highlighting on pre areas */
. —
Omegatron 14:39, 22 August 2006 (UTC)
Does anyone object to adding
* { font-family: "Arial Unicode MS", "Lucida Sans Unicode", sans-serif; font-family /**/:inherit; } textarea { font-family: "Arial Unicode MS", "Lucida Sans Unicode", monospace; font-family /**/:monospace; } pre { font-family: monospace; }
to Common.css? Disadvantage (Internet Explorer only): it overides the font selected by the user in their browser preferences, and can only be re-overridden by changing their own monobook.css. Advantage: it avoids situations such as this, this and probably many more. — Ruud 01:03, 27 May 2006 (UTC)
According to Arial Unicode MS, it does not support smoothing in the 14-18 pt range :/ (Strange, as Linux does smooth this font, how can smoothing be disabled for a certain range anyway? Why can't Microsoft just make something without bugs?) — Ruud 18:26, 27 May 2006 (UTC)
Hi guys,
after an enervating discussion at template talk:languageicon we couldn't find any consensus on the final appearance of link language indications. However there were many requests for a less flashy design; thus I ask to add the following class to common.css, so that anyone wanting a more sober design can obtain it via his personal style sheet:
.language-indication { cursor: default; font-family: sans-serif; font-size: 0.84em; font-weight: bold; color: navy; position: relative; bottom: 0.08em; }
This leaves the default aspect as it is now. Thanks — Gennaro Prota •Talk 18:30, 2 June 2006 (UTC)
I think it is time to remove the hiddenStructure class. This was originally incorporated here as an alternative to {{ qif}} for hiding conditional text in templates. However, there are a number of accessibility problems with this method and it has been obsolete since m:ParserFunctions were introduced as a built-in way of performing the same tasks. Most of the existing uses of 'hiddenStructure' were converted to the '#if:' parser function weeks ago without incident. There are doubtless some pages still using hiddenStructure, but I think it would take minimal time to locate and convert them once the class is removed. Perhaps some sort of public notice could be given that some templates may stop hiding conditional text and info on where to go for help converting them. Thoughts? -- CBDunkerson 10:44, 8 June 2006 (UTC)
I want to use the prettytable settings on my wiki. My brute force approach was to copy http://en.wikipedia.org/wiki/Wikipedia:Common.css to my Common.css page, but this hasn't worked. Does anyone know how I can make something like this work? I am using MediaWiki 1.6.7. dryguy 19:24, 19 June 2006 (UTC)
Thanks! Worked nicely. dryguy 02:21, 21 June 2006 (UTC)
Talk page notices are currently set at a standard width of 80%. Looking at the spectrum of talk page templates in use in en:Wikipedia, this is creating inconsistencies. It also, in my opinion, makes less than optimal use of the page. The border and colored background is sufficient to draw attention to these notices. Limiting the width to 80% is unnecessary. I would like to reset this default to 100%. Rossami (talk) 13:29, 24 June 2006 (UTC)
Comparison (100, 85, 80% respectively, from Template:Vblock; 80% is the current standard): — Simetrical ( talk • contribs) 01:19, 11 August 2006 (UTC)
I motion to change the standard to 85%. This will bring us consistancy with the style guideline and slightly more efficient use of page space. Kaldari 01:28, 11 August 2006 (UTC)
Anyone care if I add some infobox styles in support of the proposed Wikipedia:Geographical infoboxes guideline? I'd like to add an infobox style and some sub-styles (as in User:Rick Block/monobook.css) for use with infoboxes for geographical places. I have a modified version of Template:Infobox U.S. state in user:Rick Block/Infobox U.S. state if anyone would like to see what it might look like. Thanks. -- Rick Block ( talk) 01:58, 2 July 2006 (UTC)
Please see Wikipedia talk:Image copyright tags#Template standardization for discussion on standardizing these templates. — Simetrical ( talk • contribs) 02:08, 10 August 2006 (UTC)
Can anyone tell me what efforts are being made to keep consistancy between these two (and other
sister projects) with respect to this rather important central resource?
Why isn't there a master copy from Meta controlling?
Or at least the same master used on both the English language defaulted commons and this en.wikipedia (The hands down 800# gorrilla of wikipedia's by article count!)<g>
I'm curious, in that some text templates that were debugged and working fine are now evincing a variety of display issues including total disfunctionality.
One of these manifested two weeks back (square 'undef'd character', irrc, seen first on the commons) before my vacation trip. I've been tripping on others since last evening on both sister projects. The sqaure 'undef'd' char box seems to point logically directly to this (
Commons:MediaWiki:Common.css) specific resource.
See:
this if you care to help sort through this vexation and are a code guru.
While I didn't put that up for general consumption, in a nutshell, if it's not shown in bold (indicating a display 'nowiki' block, and hence the desired display effect) one should not be seeing any {s}, {space}, or {i} or {indent} manifestations in the captured HTML.
Something prior to reverts (about 18:00, 17 August 2006) was causing total dysfunction. (Note: This post is heavily indented using the now 2X reverted
1 {{
Indent}} [called via the {{
I}} 'eye' template]). //
Fra
nkB 20:00, 17 August 2006 (UTC)