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 |
In the Talk page of ((prettytable)) it was suggested to take the discussion about moving that template into sitewide CSS here, but somehow nobody did. Therefore I'm repeating my comment from there:
The current code is
border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse;"
It is correct that IE does not support 'border-spacing', but it does support 'border-collapse: collapse', which always implies "border-spacing: 0", which is the same as "cellspacing=0". It also supports 'padding' for 'td' and 'th' correctly, which is what "cellpadding=4" does. Even that contradicting "border=2" and "border: 1px #aaa solid" is handled the same as in Firefox. Therefore I really cannot see any reason not to move this into the stylesheets (there are more skins than Monobook). Even if in IE some spacing was one or two pixels off or the border color a little darker—it did not matter! Server resources are much more valuable than such a minor glitch. So my proposal is:
table.pretty { margin: 1em 1em 1em 0; border-collapse: collapse; background: #f9f9f9; color: #000; /* font-size: 95%;*/ } table.pretty th, table.pretty td { border: 1px #aaa solid; padding: 4px; }
And while we are at it, add something like this, that IE really does not support:
table.pretty th[scope="col"], /* column header */ table.pretty>tbody>tr:first-child>th, table.pretty th[scope="row"], /* row header */ table.pretty>tbody>tr>th:first-child { background-color: #F00; } table.pretty th[scope="row"], /* row header */ table.pretty>tbody>tr>th:first-child { text-align: left; } table.pretty>tbody>tr:hover>td, table.pretty>tbody>tr>td:hover {/* or '*' instead of 'td' */ background-color: #8A5; }
Note that I do not like all the style choices made in this template, especially not the reduced font size. The actual color codes should be skin dependent. Furthermore I doubt that a class is at all required, because we could just make all tables look nice instead (I already did in my stylesheet, but I'm using Standard not Monobook). Christoph Päper 12:16, 23 Jun 2005 (UTC)
.pretty
-code, but I like the initiative. If it works in the major browsers, I cannot see why we shouldn't include it in the stylesheet(s). The Template:Prettytable is temporary and usable, but hard on the servers. -Fred Bradstadt 09:59, July 21, 2005 (UTC)<th>
having a background color, for example #efefef. What do you think?table.pretty { ... }
with #content table { ... }
). I can't see any other problems with implementing it. ed g2s • talk 12:59, 24 July 2005 (UTC)Please see my suggestions on MediaWiki talk:Common.css#Proposal for CSS for tables. -Fred Bradstadt 16:15, August 20, 2005 (UTC)
It seems to me that someone is adding and removing "text-align: justify;" in the current stylesheet. It causes the Unicoded texts, especially Tamil to flip in Firefox. See, this bug report. So, please don't "justify" text-align. Thanks. --Rrjanbiah 07:53, 5 Dec 2004 (UTC)
I make changes to my monobook.css, but they won't show up (I suppose they will someday). I even load the css in my browser window and shift- alt- command-refresh a dozen times—no luck. Sure is a pain to trouble-shoot CSS changes this way. Is there a trick, or just patience required? —Michael Z. 00:01, 2005 Jan 16 (UTC)
Both /skins/monobook/main.css and monobook.css are currently invalid. I've been experiencing some very annoying styling goofiness in Safari/Mac lately. Can someone please remove the invalid declarations and fix the syntax errors? —Michael Z. 2005-01-21 18:03Z
Please revert this change ASAP. It is messing up the display of table of contents. -- Netoholic @ 06:19, 2005 Feb 10 (UTC)
I don't like this at all. Fredrik | talk 02:55, 13 Feb 2005 (UTC)
The bullet used by lists is bullet.gif. This should be bullet.png, IMHO. It should link to [1], so that it is in the control of the Editor. Gerritholl 11:47, 14 Feb 2005 (UTC)
Would someone please add this to the file:
#bodyContent .plainlinks a {padding: 0 !important}
Thanks. – ABCD 03:20, 24 Feb 2005 (UTC)
!important
code to the http://en.wikipedia.org/style/monobook/main.css file. – ABCD 03:59, 24 Feb 2005 (UTC)
Village pump (technical)#section edit links showing up badly - this may be a problem with the CSS, or it may be a Mozilla/Firefox/etc problem that can still be fixed by changing the CSS. Please have a look. --SPUI (talk) 17:55, 1 Mar 2005 (UTC)
should we change
div.thumb div a img { border:1px solid #cccccc; }
into
div.thumb div a img { border:1px solid #cccccc; background-color:#ffffff; }
(I added this to my user css and it works the way I expected.)
to fix this:
Or maybe we just shouldn't be uploading images with transparent backgrounds? But they look better on pages with colored backgrounds like this:
- Omegatron 16:39, Mar 21, 2005 (UTC)
I'm going to be bold and add it. - Omegatron 17:49, Mar 28, 2005 (UTC)
Per discussion at Wikipedia talk:WikiProject Stub sorting#A simple idea to make stub templates look less ugly/obtrusive, could someone with The Power append the following line?
#stub { font-size: smaller; }
—Korath (Talk) 11:55, Apr 14, 2005 (UTC)
I imagine this is just a css problem. See Twisted pair. The bullets along the image are not indented as they would be elsewhere. - Omegatron 17:10, Apr 15, 2005 (UTC)
Actually. Don't see it. I'll show you here:
Twisting wires decreases interference because:
Twisting wires decreases interference because:
Unfortunately there is no practical way to fix it. The problem is that the margins and padding for the text items are all less than the width of the image. If the text was wrapped in a <div> with a style of margin-left:125px
(125 px because the image is 100px wide + padding), you would see normal (desired) formatting. But because there is normally no way to determine how much text will be affected (it depends on an individual's browser settings), it is just not practical to do that. Instead you will just need to avoid left-floating an image with a list. Float it to the right instead. (I did add it to the article Twisted pair as an example of what it would look like.) —Mike 02:10, July 21, 2005 (UTC)
Many infoboxes now use class="toccolours". For good semantics there should really be a class="infobox", initially with the same properties as toccolours. Also seeing as most infoboxes (in fact, everyone I've ever seen) floats right, it would be good to include an .infobox.right class (or similar) which defines properties such as float:right; clear:right; left and bottom margins. If we could come to a site-wide agreement this would save a lot of arguments based around "but it's not a table of contents", and we could easily bring some consistency to Wikipedia's ubiquitous infoboxes. ed g2s • talk 15:41, 16 Apr 2005 (UTC)
.infobox { border:1px solid #aaaaaa; background-color:#f9f9f9; padding:5px; font-size: 95%; border-collapse: collapse; } .infobox.right /* this may have to be .infobox.info_right if the class .right already exists */ { float:right; clear:right; margin:0 0 1em 1em; /* 1em to the left and below */ } /* Other possible classes that would be useful, in my experience */ .infobox tr { vertical-align: top; } .infobox_image { border:1px solid #aaaaaa; padding: 0; }
.infobox { border:1px solid #999; font-size: 95%; border-collapse: collapse; float:right; clear:right; margin:0 0 .5em 1em; } .infobox tr th, .infobox tr td { vertical-align: top; } .infobox image { margin: 0 auto; }
I have 3 comments/requests - see below:
(1) I think we should consider changing from the gray color to white or something else. For exampe #F9F9F9 becomes white on 256 color machines. Additionally, other customizations such as the debate which sparked this at Template:Infobox pope are attractive, not overly fancy and give Wikipedia a nice fit and polished look.
Not all infoboxes are created equally - I think navigation type infoboxes such as the ones that are used for a series of related articles as a kind of quick link table of contents for related articles such as Template:Christianity, Template:Worldmusicbox, Template:USmusic, etc are much more effective that Categories for quick navigation amongst closely related articles. (2) These should probably resemble as close as possible the Table of Contents look and feel since they serve a similar purpose.
However some infoboxes are mearly informational with few wikilinks (see Template:Infobox Game for an example) others like the Infobox pope provide mostly information with rarely used links to location of birth, links to significant dates, etc.(3) I see no reason why these should all conform to a standard box style other than a few guidelines, lines no thicker than x, no more than 2 horizontal lines in the middle of the box, etc. The use of templates allows these formatting characteristics to be standard across related articles without the extra burden of making them standard across the entire project. The community itself will force attractive (no Bold RED on light Orange titles) through concensus rather than programming decree Trödel|talk 16:33, 27 Apr 2005 (UTC)
Ed's not interested in dialogue, only in convincing everyone that everything must be homogenous and conforming, and that there is no wiggle room for varying the style of the presentation to any degree, regardless on how the style clashes with the coloring of the presented information. There is nothing that mandates the use of toccolours, and by forcing it into the infoboxes he's stifling community involvement. Carry on in creating the infobox you feel you need to make and don't be inhibited by a non-existent style mandate that not everyone finds appealing. - UtherSRG 18:59, Apr 28, 2005 (UTC)
Monobook makes frequent use of line-height specifications using the unit "em". While these lengths _are_ font-size-relative, which is good, the computed value, and not the relative value is inherited by child elements, which is bad.
The problem becomes apparent when a child node uses a different font-size. E.g. many boxes on Wikipedia use font-size:80%. However, because the computed value of line-height is inherited, the line-height stays unchanged (i.e. too large) and the style of the box has to manually fix the line-height.
The solution is to use plain number line-heights, i.e. "1.5" instead of "1.5em". That way, the line-height will properly scale when the font-size is changed.
Here's the relevant section from the CSS2 spec: http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height
Values for this property have the following meanings: [...] <length> The box height is set to this length. Negative values are illegal. <number> The computed value of the property is this number multiplied by the element's font size. Negative values are illegal. However, the number, not the computed value, is inherited.
Crossposted at http://bugzilla.wikimedia.org/show_bug.cgi?id=2013
K. Sperling 00:53, 2005 Apr 29 (UTC)
I have a query at Wikipedia_talk:A_proposal_re_BCE-CE_Debate#Let's implement a preference-based solution today about what is technically possible with CSS. If answered positively, it may help break the deadlock in the interminable BC/BCE debate, so please have a brainstorm about the best solution and comment there! Many thanks. Pcb21| Pete 10:11, 16 May 2005 (UTC)
I have added a new class "plainlinksneverexpand" that behaves like the existing class "plainlinks", but not only suppresses the external link arrow but also URL expansion. Resulted from this discussion at the Village pump. See also Template talk:Ref and Template:Ref, where this is used. Does this need to be ported over to other skins (Cologne, Classic)? Lupo 20:36, 24 May 2005 (UTC)
Does anyone know why we override people's browser settings to underline links? I can't find the original discussion on this - although there is some stuff in the archives from people saying they would prefer us not to have this in the style sheet. We have had an email to the foundation pointing out that this can be an accessibility issue for some types of vision problems. Of course, forcing people to view without underline would also cause accessibility problems for some, so surely we should leave this to browser settings. I know we have preferences settings for this, but that's not a good solution for our large number of non-logged in readers. -- sannse (talk) 20:06, 11 Jun 2005 (UTC)
The line "forcing" underlining was apparently removed today by ABCD. Unfortunately, that broke underlining entirely for me, on Firefox 1.0.6. (I have "Underline Links" set in my browser preferences, but they no longer appear at all, when using the Monobook skin.) I left ABCD a note on his/her talk page, but unless this was discussed somewhere else, it seems unwise if it breaks things. I would revert it but I do not know how, since it comes from Mediawiki and is not a local page. I don't know enough about CSS to know why removing the line forces no underlining instead of letting it be determined by browser prefs. MCB 23:34, 14 October 2005 (UTC)
Wikipedia:WikiProject Spoken Wikipedia would like to put a link to spoken articles to the right of the page heading. For this we will require the following piece of css added:
h1#spoken { display: block !important; border-bottom-style: none; float: right; font-size: 150%; position: absolute; right: 2%; top: .25em; }
A demonstration of what this will look like is Wikipedia_talk:WikiProject_Spoken_Wikipedia#Link_at_top_of_article.3F here. Ta, Joe D (t) 13:54, 26 Jun 2005 (UTC)
This code urgently needs to be corrected to:
#spoken { display: block !important; border-bottom-style: none; float: right; font-size: 150%; position: absolute; right: 2%; top: 0.6em; }
...in order to deal with a problem in MediaWiki 1.5. — Chameleon 28 June 2005 12:05 (UTC)
OK, that code got screwed up by the site notice. I think that the following code is definitive and should always work:
#bodyContent .plainlinksneverexpand a { background: none !important; padding: 0 !important } #bodyContent { position: relative; } #spoken { position: absolute; float: right; text-align: right; font-size: 90%; right: 0; z-index: 1; background: none; border-bottom-style: none; top: -2.2em; }
— Chameleon 30 June 2005 12:05 (UTC)
#bodyContent { position: relative; }
Can anyone tell me why the screenshot above is doing this? It's happened on Wikipedia:No personal attacks, and I am running Windows XP, Mozilla Firefox 1.0.4, using default monobook skin. - Ta bu shi da yu 4 July 2005 02:25 (UTC)
Could it be because the voting notice is shifting the article title and text, but not the spoken article link, down a line? — Dan | Talk 4 July 2005 02:56 (UTC)
Man, somebody must have fucked with something. Because this was perfect a few days ago. BLANKFAZE | (что??) 4 July 2005 13:54 (UTC)
Can somebody just revert this back to the version [3] from the 26th? We can use a temporary fix to get around the sitenotice bug, the current css doesn't work at all. Joe D (t) 5 July 2005 15:39 (UTC)
Monobook.css won't validate as CSS2 because of the following declarations. Are these MS-specific extensions, or CSS3 properties? If the former, is there any reason not to move them to the MS-specific style sheet? If the latter, why are we using them? —Michael Z. 2005-07-4 21:40 Z
/* Experiment: slightly fade inactive tabs */ #p-cactions a { filter: alpha(opacity=90); } #p-cactions a:hover, #p-cactions .selected a { filter: none; }
It appears this is a deliberate attempt at bypassing the default style sheet. It is sometimes useful (see List of volcanoes), but these instances are rare. - Ta bu shi da yu 5 July 2005 03:57 (UTC)
The class for notices like template:mergeto (.notice) looks like this:
/* Style for "notices" */ .notice { text-align: justify; margin: 1em 0.5em; padding: 0.5em; }
Would anyone object to my making the horizontal margin 1em, so it doesn't look different from notices that use a colon for formatting? (E.g., template:merge, which is currently protected). —Michael Z. 2005-07-5 19:47 Z
I noticed it's common for the different skins to get out of sync (things that should be added to all of them are only added to Monobook.css, until someone else takes notice and updates the others). What would you think about creating a MediaWiki:Common.css and adding the following line to the top of all the skin stylesheets:
@import "/w/index.php?title=MediaWiki:Common.css&action=raw&ctype=text/css&smaxage=2678400";
This way, content styles (like for instance .notice) could be updated in a single location, and the skin-specific stylesheets would need to worry only about the user interface. Since it would be added to the top, the CSS cascade could be used to override the common style, if needed.
--cesarb 9 July 2005 19:16 (UTC)
The "new" look is stupid. Please change it back. - Ta bu shi da yu 09:29, 13 July 2005 (UTC)
The following came up on Template talk:Ref:
Can anyone tell me what's happening here? When I print the URL is expanding.... I thought we didn't want to do this. - Ta bu shi da yu 07:42, 15 July 2005 (UTC)
On another note: why does the import of Common.css have a maxage? Lupo 09:04, July 15, 2005 (UTC)
On main.css, there are the following rules:
div.thumb { margin-bottom: 0.5em; border-style: solid; border-color: White; width: auto; } ... div.tright { clear: right; float: right; border-width: 0.5em 0 0.8em 1.4em; } div.tleft { float: left; margin-right:0.5em; border-width: 0.5em 1.4em 0.8em 0; }
Looks to me that borders are being misused, the effect intended is that one of margins. Here, on Monobook.css, you have
#content div.thumb { border-color: #F8FCFF; } ... .ns-0 * #content div.thumb { border-color: white; }
just to change the color of these borders, to match the page background (and this is more annoying because IE doesn't support transparent borders, and so, we can't use border-color: transparent
. Was there a good reason borders where used instead of margins? --Miles 15:33, July 16, 2005 (UTC)
The thumbnail- on-a-background doesn't look good because of the hacky borders around the thumbnail frame, ostensibly done to make separators look better.
Also, the top and bottom borders are not useful for this hack.
hr { margin: 0 auto 0 auto; } div.tright { clear: right; float: right; margin-left:0.5em; border-width: 0 0 0 0; } div.tleft { float: left; margin-right:0.5em; border-width: 0 0 0 0; }
hr
won't do much. —Simetrical (talk • contribs) 19:21, 8 August 2006 (UTC)
<h2>Borders around Thumbs header test</h2> (See http://bugzilla.wikimedia.org/show_bug.cgi?id=6575 for the above weirdness)
Can you not add "border-color: white; border-color: transparent;": won't MSIE stick with white because it doesn't understand transparent, but all other browsers override white with the second border-color declaration? This way it's only slightly broken in the broken browser—so sad, too bad. —Michael Z. 2006-08-08 15:20 Z
The thumbnail- on-a-background looks fine after overriding the "thumb right" style. Perhaps this should be added the /box-header used by most portals? Also, is there a test page for people to compare with before making changes to monobook.css?
I've added a class to all redirects on Special:Allpages called allpagesredirect, please style it somehow (maybe make it grayer). —Ævar Arnfjörð Bjarmason 13:39, 19 July 2005 (UTC)
Can somebody revert the spoken code to:
#spoken { display: block !important; border-bottom-style: none; float: right; position: absolute; right: 2%; top: 0.6em; }
The current code doesn't work. Joe D (t) 13:50, 20 July 2005 (UTC)
The div.tleft
class used for images that float to the left is missing a clear: left;
. This sometimes causes an image to be placed next to another float instead of below it. The div.tright
class properly does clear: right;
It should probably go into /skins-1.5/monobook/main.css, but if I'm not mistaken that file is distributed with the mediawiki software and won't change until mediawiki is upgraded to a new version. So putting it into this one would be a good workaround until then. --K. Sperling 20:40, July 28, 2005 (UTC)
See the edit links on [4]. - Omegatron 19:54, July 29, 2005 (UTC)
Errors URI : http://en.wikipedia.org/wiki/Main_Page Line: -1 unrecognized media screen,projection URI : http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400 Line: 151 Context : #p-cactions a Parse Error - opacity=90) Warnings URI : http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400 Line : 155 property filter does not exist for this profile, but is validated conforming to another profile
Anoniwiki 10:21, 21 August 2005 (UTC)
filter
, which is an MS extension with an invalid or at least unspecified value syntax (CSS functions take comma separated parameters, but no assignments with the equals sign). That experiment, which is inappropriate in a production environment anyhow, should of course use opacity: 0.9
as soon as CSS 3: Color advanced to the next status, or one of the color notations with alpha value (e.g. rgba()
). Note that that Draft has serious yet unresolved issues. Christoph Päper 19:11, 21 August 2005 (UTC)#p-cactions a { opacity: 0.9; filter: alpha(opacity=90); } #p-cactions a:hover, #p-cactions .selected a { opacity: 1; filter: none; }
— Sverdrup 16:36, 22 August 2005 (UTC)
Should the background color of the new Portal namespace be the same light blue it currently is, or should it be changed to white (same as the articles and the Main Page)? Now that it's a separate namespace, it would be very easy to change the color, and it would better match the look of the Main Page. --cesarb 18:02, 28 August 2005 (UTC)
This is a proposal to address the difficulties many users experience when they try to thematically navigate Wikipedia after they leave the Main Page: add one (or add one and expand one) topical navigation menu to Mediawiki:Monobook.css. The elements would be those contained in Template:Categorybrowsebar located on the Main Page. In this template, the first line focuses on the main categories while the second line focuses on browse options. Adding the elements to this style sheet would allow Wikipedia to have a topical, top-level navigation scheme, based on the primary categorization scheme, that would help users move about logically and quickly from any page. Another benefit of this implementation would be that Template:Categorybrowsebar could be removed from a prominent position on the Main Page and several other high-level pages. — RDF talk 17:48, 12 September 2005 (UTC)
p.s. If this is the wrong place to make this proposal, please let me know where I should go. ;-) — RDF talk 19:14, 12 September 2005 (UTC)
Here's a one-menu version (Template:Categorybrowsebaroneline) that could span across the top of a page.
Culture | Geography | History | Life | Mathematics | Science | Society | Technology | Categories | Portals | Articles | Alpha | More
Here's a script version of that template (complements of pile0nadestalk | contribs) developed for such a purpose. It includes my edits to make a one-line version.
/* Add Template:Categorybrowsebaroneline to top of page */
setTimeout("categorybrowsebaroneline()", 0);
function categorybrowsebaroneline() { var div = document.createElement("div");
div.innerHTML = '
<a href="/wiki/Category:Culture" title="Category:Culture">Culture</a> | <a href="/wiki/Category:Geography" title="Category:Geography">Geography</a> | <a href="/wiki/Category:History" title="Category:History">History</a> | <a href="/wiki/Category:Personal_life" title="Category:Personal life">Life</a> | <a href="/wiki/Category:Mathematics" title="Category:Mathematics">Mathematics</a> | <a href="/wiki/Category:Science" title="Category:Science">Science</a> | <a href="/wiki/Category:Human_societies" title="Category:Human societies">Society</a> | <a href="/wiki/Category:Technology" title="Category:Technology">Technology</a> | <a href="/wiki/Wikipedia:Browse" title="Wikipedia:Browse">Categories</a> | <a href="/wiki/Portal:Browse" title="Portal:Browse">Portals</a> | <a href="/wiki/Wikipedia:Browse_by_overview" title="Wikipedia:Browse by overview">Articles</a> | <a href="/wiki/Wikipedia:Quick_index" title="Wikipedia:Quick index">Alpha</a> | <a href="/wiki/Wikipedia:Category_schemes" title="Wikipedia:Category schemes">More</a>
'
document.getElementById("content").insertBefore(div, document.getElementsByTagName("h1")[0]);
}
Use this (template:eight portals links) across the top of a page.
Art | Culture | Geography | History | Mathematics | People | Philosophy | Science | Society | Technology
Add the browse options to the sidebar navigation box something like this.
navigation
The recent changes of the monobook seem to hide some navigational boxes completely - e.g. Template:Provinces of Thailand. The main difference between that one and those which still show is that the invisible include a id="toc". Yesterday they still showed, however due to the caching of the css I'm not sure which change actually was the "bad" one. Where is the problem - within the css or the template? andy 11:09, 27 September 2005 (UTC)
Looking at m:Link style vote the decided policy seems to be underlining links even when the mouse is not over a link, however I see that this behaviour has been reverted by ABCD. The justification he invokes is "allow browser settings to propagate". But, as you can see in monobook/main.css on line 66:
a { text-decoration: none; ... }
This means that browser settings won't propagate, and that links will never be underlined, regardless of what the browser settings are. Note that this only occurs when not logged in (otherwise it depends only on the user's preferences), and that Firefox's Web Developer Toolbar confirms that this is indeed the reason why links are not underlined. Unless monobook/main.css can be modified to fix this, I believe this change should be reverted... Or maybe there was another discussion of this issue? (in which case m:Link style vote should be updated) --Ma Baker 02:08, 8 November 2005 (UTC)
Since a large portion of people are color blind in some sense, we should address this quickly:
(copied from User talk:Jimbo Wales)
Apropos of this, would it be possible to fix it so that the background-color also changes, to allow alterations in white-space to be seen? HTH HAND —Phil | Talk 08:23, 2 February 2006 (UTC)
I was told that here is the place to say this, so sorry if it isn't. May I suggest the hearder be moved back to the top of the page where it used to be, rather than at the right of the page title. The first time I saw it like that I thought it was a bug; I really do think it looks terrible. If I'm understanding the code in the history correctly it's been changed and reverted, and it's only a test, but my view is don't keep it like this! Why was it moved to the right in the first place anyway? Raven4x4x 08:52, 23 December 2005 (UTC)
In, Firefox, left-floated image boxes nearly overlap the text above. I suggest that a margin-top is added:
div.thumb {
margin-bottom: 0.5em;
margin-top: 0.5ex;
border-style: solid; border-color: White;
width: auto;
}
--84.194.112.7 17:57, 11 January 2006 (UTC)
Can somebody revert the spoken code to:
#spoken { display: block !important; border-bottom-style: none; float: right; position: absolute; right: 2%; top: 0.6em; }
The current code doesn't work. Joe D (t) 13:50, 20 July 2005 (UTC)