![]() | 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 10 | ← | Archive 12 | Archive 13 | Archive 14 | Archive 15 | Archive 16 | → | Archive 19 |
Since hlist has taken off, there are (sometimes slightly overenthousiastic) calls to turn everything into a hlist. When it was suggested that {{
navbar}} be turned into a hlist, I had to intervene. Though I understand the reasoning, I do think navbar is not a list. If the goal is to mask the various visual aspects from any elements from content in order to make it sematically correct, there are better ways. For instance, stuff like bullets, pipe symbols and other seperators that are not content, could be wrapped in a nocontent
class, which has the following properties:
.nocontent {
speak: none;
}
I don't know much about screenreaders and such (so it may need extra rules), but this would enable editors and template coders to hide the various visual elements from semantic content, such as the bullets in navbar. — Edokter ( talk) — 15:16, 24 November 2011 (UTC)
OK, have a look at the navbar sandbox version and its test page (and even the navbox test page). There remains a small spacing issue when used inline with brackets, but that scenario is never used AFAIK (I might as well remove the brackets option). Expect a lot of tweaking. Eventually, most navbar CSS will be moved to Common.css. — Edokter ( talk) — 15:19, 25 November 2011 (UTC)
As section title.
Nice to have the tools follow one down the page. Would be nice for WP:ACCESSIBILITY too. fredgandt 23:36, 24 November 2011 (UTC)
position:absolute;
set in the common.css but actually there is no mention of it. I guess it must be inherited? the only two absolute
's I can find are for navToggle and breadcrumbs. Confused as ever.
fredgandt
00:24, 25 November 2011 (UTC)
fixed
as you would not be able to scroll down all items if the entire list spans more then one screen, as is often the case with interwiki links. You can always put it in your personal CSS though. —
Edokter (
talk) —
01:02, 25 November 2011 (UTC)
← My eyes have grown sticky with the night so I've not yet looked at styling the scroll-bar (except that it can be done in webkit and apparently in IE (I am shocked!!)). Here's a quick demo of the basic stuff though.
<!DOCTYPE html> <html> <head> <style type="text/css"> #side-dish { position:fixed; background-color:#ddd; border:1px solid #888; top:8px; float:left; width:150px; height:700px; font-size:70%; overflow:auto; } #main-dish { margin-left:160px; border:1px solid #888; } p { margin:5px; } p:hover { color:#0f0; font-weight:bold; } </style> <script type="text/javascript"> var str; var count=0; document.write("<div id=\"main-dish\"></div>"); var md=document.getElementById("main-dish"); if(md) { while((++count)<201) { str="<p>"+count+"</p>"; md.innerHTML+=str; } } document.write("<div id=\"side-dish\"></div>"); var sd=document.getElementById("side-dish"); if(sd) { count=0; while((++count)<201) { str="<p>"+count+"</p>"; sd.innerHTML+=str; } } </script> </head> <body> </body> </html>
I don't think it's that bad even with the scroll-bar but I'll still look see if it can be styled (later). Thanks for the good luck wishes. I detest IE passionately. fredgandt 03:39, 25 November 2011 (UTC)
I still use a custom version of the Modern skin precisely because it was tweaked to keep the tabs and sidebar always visible; I find that to be a extremely convenient. I've been meaning to apply the same to the Vector skin, but haven't found the time to do it. I'd be happy to try on a custom style I could import to my vector.css and give feedback/offer further enhancements in return :)
(ps - I tried to
import your common.css but I saw no change even after clearing the cache. Does it work only with accompanying js? If so, would it be possible to make it work with css only?) --
Waldir
talk
11:50, 27 November 2011 (UTC)
@import url("
http://en.wikipedia.org/?title=User:Fred_Gandt/common.css&action=raw&ctype=text/css");
. Alternatively, you can use importStylesheet("User:Fred Gandt/common.css");
in your personal javascript file. —
Edokter (
talk) —
14:22, 27 November 2011 (UTC)#mw-panel { position:fixed !important; max-height:500px; overflow:auto; }
Currently there is a nice styling for the user signup form, why not applying it also for the user login form?
/* Makes it possible for the boxes in the Account Creation Process to overlap */ #userlogin, #userloginForm { margin:0; width:90% !important; max-width:100% !important; padding:1.5em; padding-top:0.75em !important; border:0; -moz-box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); -webkit-box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); -moz-border-radius: 7px; -webkit-border-radius: 7px; border-radius: 7px; background:white; background: #fff; background: -moz-linear-gradient(bottom, #fff 90%, #F5F5F5 100%); background: -webkit-gradient(linear, left bottom, left top, color-stop(90%,#fff), color-stop(100%,#F5F5F5)); background: -webkit-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: -o-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: -ms-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: linear-gradient(bottom, #fff 90%,#fff 100%); }
— Fitoschido [shout track] \\ 3 December, 2011 [20:32]
The font stacks in MediaWiki:Common.css/WinFixes.css are a true mess. Over the years, the list of exotic fonts has grown with every editor adding his/her own preferred font. Apart from the three or four MS fonts in the list, the rest of those fonts are mostly found on non-Windows machines, which is rather pointless since the file is only loaded on Windows(!). Why have fonts listed which have an installed base of less then 0.01%?
I think it is time for a cleanup, and prune this list to it's bare minimum. Therefor, I would like to do an inventory for the requirements and compile a list from scratch. Since most classes are intended to mostly fix IE issue, perhaps it is best to limit loading to IE only. Any used fonts should be readily available, preferably without requiring any downloads (as most Windows readers won't even bother with fonts). Then the list should be split into serif/sans-serif to match the several skins.
I can't do this alone, so I need input on the requirements and suggested fonts. What I can do is list the (unicode) fonts most likely available to Windows users (sorted by glyph count). — Edokter ( talk) — 21:46, 27 November 2011 (UTC)
I suspect this code should never have moved to Winfixex.css in the first place. Case in point: Template talk:Unicode#Patently useless. — Edokter ( talk) — 14:25, 1 December 2011 (UTC)
Another frustrating issue... Where IE8 and Firefox display unicode correctly, Chrome fails miserably with combining diacritics, but only under XP! This seems to be a long standing issue, judging from the miriad of bugs filed with Chromium, with no fix in sight. I'm am going to narrow the target for loading Winfixes.css to IE6/7 and Chrome under XP. — Edokter ( talk) — 19:24, 4 December 2011 (UTC)
After trimming the list, I eventually ended up with the two main unicode fonts for Windows for both {{ unicode}} and {{ IPA}}. Since it was now a single line of CSS, I opted to have it load directly in Common.js and remove WinFixes.css. Less clutter, one less HTTP request, so faster loading. — Edokter ( talk) — 22:57, 7 December 2011 (UTC)
I posted about this not too long ago but removed the thread since I chalked it up to PEBKAC... but on further inspection, this issue seems to be legitimate. I'm having trouble finding where in the CSS this is, but the navbox and templates that transclude the class (e.g., {{hat}}) no longer seem to center the title in Firefox and Opera, though it seems to work fine in IE. I'm not sure if there's something non-compliant in the CSS that's breaking that particular aspect of the class. The problem seems to have started not too long ago, and I suspected it might be this edit that's causing the issue, but I've tried reverting to the previous version already and the problem corrected itself temporarily, but is back now, which is quite odd. I'd rather not continue reverting and testing, but if someone else also has the same issue and can figure out what's going on, whether it's the CSS itself or something with MediaWiki, that would be helpful. Thanks. -- Kinu t/ c 22:18, 6 December 2011 (UTC)
text-align:center;
, but a better solution is to have a seperate class for these archive templates. —
Edokter (
talk) —
22:59, 6 December 2011 (UTC)I've got a couple style defs I'd like to add:
/* On wide screens, show these as two columns */
.portal-column-left {
float: left;
width: 50%;
}
.portal-column-right {
float: right;
width: 49%;
}
.portal-column-left-wide {
float: left;
width: 60%;
}
.portal-column-right-narrow {
float: right;
width: 39%;
}
@media only screen and (max-width: 800px) {
/* Decouple the columns on narrow screens */
.portal-column-left,
.portal-column-right,
.portal-column-left-wide,
.portal-column-right-narrow {
float: inherit;
width: inherit;
}
}
Many portal pages like Portal:Literature and Portal:Science create two-column layouts by wrapping a float-left and a float-right div with specified percentage widths in a bigger div with open & close. This looks great on a wide screen, but on narrow windows (especially on mobile screens!) you end up with a really ugly result such as Portal:Literature on mobile. Something like these styles should disable the floats & the fixed widths on narrower screens, so it automatically devolves into placing the two "columns" vertically, with no shrinkage: much nicer on a small mobile screen.
Any objection to adding these styles globally and trying swapping more of them in? Experimentally using them on Portal:Literature/Mobile redesign attempt. (only works if you add the styles to your .css or the globals, otherwise you'll see the one-column layout) -- brion ( talk) 22:09, 7 December 2011 (UTC)
.portal-column-full {
float: left;
width: 100%;
}
width: 100% important; float: inherit !important;
on mobile, rather than setting up different classes for each width and float location? --
Yair rand (
talk)
01:37, 8 December 2011 (UTC)The following, which was added as a sort of bridge while hlist is deployed to navboxes containing explicit padding styles, is not always being applied. There is a difference between the use of listclass=hlist
and bodyclass=hlist
.
.navbox .hlist td dl,
.navbox .hlist td ol,
.navbox .hlist td ul {
padding: 0.125em 0; /* Adjust hlist padding in navboxes */
}
In the case of 'body' the padding is applied, but not for 'list'. This is because for 'list' the class is being assigned to the TD, while for 'body' it is applied to the table itself (inner one, the TD's), and this result in the above selectors not matching; the class is on the TD, not above it.
See here where I changed to body and noticed a rendering change to all the rows (no comments on the single item list; it's a stub for anyone adding to the below item).
I'm thinking the above selectors need to be relaxed: drop the TDs. Maybe drop the navbox class, too. I think this was working but then changed. FWIW, this may be the time to drop it to 0.1em as widening the application of this after so many hlists have been deployed as 'list' will result in a lot of navboxes getting taller. Up to Edokter... Alarbus ( talk) 07:29, 8 December 2011 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
The desired line is:
table.infobox.geography.othername { font-size: 80% }
More details at Template_talk:Infobox_settlement#Resize_request SSzatmari ( talk) 15:51, 13 December 2011 (UTC)
Just wondering if we need the space before the colon in the rule
/* Generate interpuncts */
.hlist dt:after {
content: " :";
}
The place where I saw it used was {{ The Holocaust}}, where the spaces appeared to be extraneous. - CapitalR ( talk) 18:54, 16 December 2011 (UTC)
Note: I have added a link to this page from Village Pumps, e.g Wikipedia:Village pump (technical) (line four: "See also:..."). - DePiep ( talk) 19:37, 16 December 2011 (UTC)
In the example below, the colors are a little off, and both event and function names should be bold.
default { state_entry() { llSay(0,"Foobar!!"); } }
I'd be happy to provide a full example script containing all the components, if the styles can be improved.
In the example below, both the function names should be bold and dark blue.
var foo=encodeURI("blahdiblah");
var bar=encodeURIComponent("blahdiblah");
I'm sure if one function is not correctly styled, there must be others (functions, methods etc.). fredgandt 04:57, 18 December 2011 (UTC)
encodeURIComponent
. It would perhaps be an idea to create a test script for all languages supported, that we can use to keep tabs on the styling. Big job, but worth doing. I'll sort the LSL report out later.
fredgandt
06:03, 18 December 2011 (UTC)I replaced a hardcoded TOC in an article here and here. Is there a template for an hlist TOC? It would be even better if the presentation were similar to what was replaced, but I'm not sure if that is possible. Perhaps a TOC-hlist variation would be possible? Thank you! 174.56.57.138 ( talk) 15:07, 26 December 2011 (UTC)
Is there a way to pass css from the TOC definition down to the list? My particular case is
Template:MTGkeywordsTOC, where my "align=center" tags appear in the td
block, but the list css overrides that in the ul
block right inside it, as shown by Chrome:
<tr>
<td align="center">
<ul>
<li>
and
.mw-content-ltr .toc ul, .mw-content-ltr #toc ul, .mw-content-rtl .mw-content-ltr .toc ul, .mw-content-rtl .mw-content-ltr #toc ul {
text-align: left;
}
-- Temporarily Insane ( talk) 09:04, 3 January 2012 (UTC)
Text marked up with <code> is very small, as the second sentence in this example shows:
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.Can we make it a bit bigger, and thus more easily readable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:08, 21 January 2012 (UTC)
Does anyone know why we don't use "white-space:pre-wrap" or something similar to prevent text overflowing on the right? I have it in common.css on my MW installation, and I add it manually to any <pre> tags I use here without any ill effects I've noticed. I'm probably missing something obvious, though... Begoon talk 08:22, 25 January 2012 (UTC)
<pre>
is to format the text exactly as entered. If text breaks out, then it isn't formatted properly. (But I also have the pre-wrap in my CSS...) —
Edokter (
talk) —
11:22, 25 January 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Per
MediaWiki talk:Common.css/Archive 13#Styling for dfn tags, the following needs to be added, to prevent various browsers (not all – Chrome for one doesn't do it, but the change won't affect Chrome users at all) from auto-italicizing <dfn>...</dfn>
instances, which aside from being inconsistent doesn't agree with any use of italics sanctioned by
WP:MOS, and directly conflicts with a lot of things. The code:
/* Styling for defining instances of terms. */ dfn { font-style: inherit; }
The dfn
element is pure semantic markup, it is not typographic and should not be automatically visually distinct in any way, or problems immediately result, of many kinds. At this time, per that previous detailed discussion at which consensus was arrived at to make this change, only, and the fact that nothing's changed since then, no other styling needs to be applied for dfn, and none is envisioned an time soon, but this change definitely does need to happen. I've been having to manually work around the italics nonsense in {{
dfn}}, etc. —
SMcCandlish
Talk⇒〈°⌊°〉
Contribs.
23:49, 11 February 2012 (UTC)
<dfn>
now. Are there any examples where dfn is used raw? —
Edokter (
talk) —
00:36, 12 February 2012 (UTC)
<dfn>
with a CSS one-liner is so that every time someone is trying to use it, in a template or otherwise, they don't have to figure out WTF is going on and how to work around it when stuff italicizes for no apparent reason (and only some of the time, as various templates usable inside a <dfn>
could override the style, even aside from very likely browser problems; no one tested the issue on any of the profusion of *n*x browsers, for example, only Windows and Mac ones). Assuming they're even competent to work around it manually - not everyone knows CSS and how to add it to HTML elements. I don't know why we're arguing about this. There was already a consensus to do this, it just got archived and I forgot to editprotect-request it. Nothing has changed other than one browser's behavior (on the platform you tested it on), which isn't relevant anyway, because we want to avoid the italics universally (actually, the fact that Chrome is doing it now, too, strengthens not weakens the rationale – now no known browsers are doing what we want). —
SMcCandlish
Talk⇒〈°⌊°〉
Contribs. 01:44, 12 February 2012 (UTC) *Note: It's bogus because the W3C specs do not recommend it,
[3]
[4] and they don't even use it in the default all-browsers style sheet that the entire Web's display is essentially based on.
[5] What happened is either Netscape or IE, I forget which (probably IE, because their track record for standards compliance and weird experimentation was far worse) had it italicized this way back in the early to mid 1990s, and eventually the other one switched to emulate the competitor, then later browsers started doing what the big two of the era did, just to keep cranky designers happy, instead of doing what made sense. —
SMcCandlish
Talk⇒〈°⌊°〉
Contribs.
04:50, 12 February 2012 (UTC)
<cite>
in core (who's default is also italics), so that is where this should be done as well. In the mean time, I'll add it here. —
Edokter (
talk) —
11:25, 12 February 2012 (UTC)
Is the code for account creation still needed? — Edokter ( talk) — 00:40, 12 February 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Per suggestion on Village pump, could someone add the needed selectors to the formatting of NavFrames? The specific change is highlighted on that discussion. Helder 20:34, 31 August 2011 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I was wondering if is it too late to regret my choise of applying the styles directly to the mw-collapsible* classes. I was testing
an script which collapses old talk page threads on Portuguese Wikipedia and when I tried it on enwiki I realised that Anomie's suggestion would have been better than mine, because this change is indeed causing unwanted styling to appear on elements which we make collapsible by using mw-collapsible
(which force us to
override it every time).
So, could you revert that change? Helder 16:44, 14 February 2012 (UTC)
See MediaWiki talk:Common.js#Do not create NavFrame buttons if the new class "mw-collapsible" is used. Helder 14:05, 5 March 2012 (UTC)
An unresolved issue is discussed at Template talk:Birth date and age#Age doesn't show up on mobile wikipedia. Your assistance would be appreciated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:38, 20 February 2012 (UTC)
Hi, I do not have a clue how this stuff works, but FYI the following discussion:
Template talk:Navbox#Small bug
The spaces are clearly incorrect. If their inclusion really was an intentional design decision, then that decision was wrong (unless it was a compromise consequence of avoiding worse difficulties elsewhere, or something of that nature, of course). 86.177.105.189 ( talk) 03:52, 14 February 2012 (UTC)
Can this be fixed such that the trailing spaces before and after parentheses rising from the ** form of hlist are removed? Or encode it so the spaces only surround the interpunct instead of being placed before and after the list items?— Ryulong ( 竜龙) 09:30, 2 March 2012 (UTC)
Edokter (I got it), would anyone of your standing even contemplate this ugly try:
1. For the opening bracket, use ")" (our regular closing bracket). 2. Envelop it in RLO-PDF "bidi directional enforcing brackets": they write this single character R-to-L, not L-to-R (which is idle for an isolated single character) and since it is a bracket, bidi rule mirrors the bracket, using its mirror bracket: "(" 'closing bracket in R-to-L'. In code, it is RLO)PDF:
‮)‬
→ )<li>
tag as a hidden text node, and all browsers seperate text nodes and block element with a space. There is simply no way around that. Any attempt to circumvent this behaviour with tricks like direction-reversal or negative margins is bound to fail... believe me, I tried. —
Edokter (
talk) —
20:59, 4 March 2012 (UTC)
<ul>
and <li>
to be inline elements, not block elements. Consider the HTML output by MediaWiki for a fairly generic list:<div class="hlist">
<ul>
<li>foo
<ul>
<li>bar</li>
</ul>
</li>
<li>baz</li>
</ul>
</div>
display:inline
is given to the <ul>
and <li>
elements, it doesn't get ignored. And since the parens come "between" the linebreaks before/after the <ul>...</ul>
and the linebreaks before/after the first/last <li>
(the effective HTML with the generated parens is something like <li>foo (<ul> <li>bar</li> </ul>) </li>
), you get a space in the display. Unfortunately, there seems to be no way to get MediaWiki to output a list without these breaks, thanks to Tidy..hlist ul ul li:first-child:before
and .hlist ul ul li:last-child:after
instead (stupid IE<9), then the open/close parens would be after/before the newlines before/after the first/last <li>
and everything would render correctly (the effective HTML with the generated parens would be something like <li>foo <ul> (<li>bar</li>) </ul> </li>
). Or you could wait for browsers to support the CSS3 word-spacing
property and then try to get the word-spacing on the <ul>
s (but not the {{
li}}s) set to -100%
, causing the spaces to have zero width. Or you could wait for browsers to support CSS4 and the text-space-collapse:discard
property to use in the same manner..hlist ul ul li:first-child:before
and .hlist ul ul li:last-child:after
warrants some testing. However, I have IE8 to contend with, and IE6/7 may put up an even bigger fight. I'll report back. —
Edokter (
talk) —
09:47, 18 March 2012 (UTC)<ol>
. I didn't touch IE6/7 yet, I'll see about that later. Currently MediaWiki:Monobook.css still has the blue background tint on certain namespaces. I just noticed that MediaWiki:Vector.css doesn't have the same code, so only Monobook users are continuing to be punished by this (specifically Monobook users who haven't locally overridden it). Can the blue tint be dead? Please? -- MZMcBride ( talk) 23:21, 3 March 2012 (UTC)
.ns-talk #content {background-color: #FFFFC0; }
but some pages are still bluish, like "Contributions". MathewTownsend ( talk) 16:19, 19 March 2012 (UTC)
<body>...</body>
but which enclosed the <h1>...</h1>
and subsequent block elements. The source for this particular page showed that the choices were <body class="mediawiki ltr sitedir-ltr ns-9 ns-talk page-MediaWiki_talk_Common_css skin-monobook action-view">
<div id="globalWrapper">
<div id="column-content">
<div id="content">
- I picked the innermost id= (content
) and the most likely-looking class which would catch talk pages (ns-talk
), and then I styled that. The yellow was just a demonstration that shows a noticeable difference. You can pick any colour you like - white is #ffffff
. --
Redrose64 (
talk)
17:06, 19 March 2012 (UTC)
div#content {background-color: #FFFFFF; }
div#content {background-color: #FFFFFF; }
technique working in all namespaces. I fiddled about with classes because I was under the initial impression that the desired change was just to the background of talk pages, not of all pages. --
Redrose64 (
talk)
19:41, 19 March 2012 (UTC)
works beautifully! MathewTownsend ( talk) 20:03, 19 March 2012 (UTC)
Check the table on the right:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. |
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. |
foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a fadsoo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo adsa foo a foo a foo a foo a foo a foo a foo a foo adsada foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo dasa foo a foo aads foo a foo a foo a foo a foo a foo a foo a foo a asdfoo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a.
It seems to get fixed with a margin-left of 6px. -- Locos epraix 05:00, 16 January 2012 (UTC)
{| class="wikitable" style="width:30%; float:right; margin:13px 0px 13px 13px;" |- | {{Str left|{{Lorem ipsum}}|123}} |}
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. |
13px top, 13px right, 13px bottom, and 0px left
, just as the left floated table does. There may be another class that can be added to .wikitable
to alter the margins of right floating tables. Is that what you're after?
fredgandt
06:02, 16 January 2012 (UTC)
I like the idea of a .right class. But it would be nice if the .wikitable class (alone) looks good right aligned given it's widespread use. -- Locos epraix 15:31, 16 January 2012 (UTC)
{{ Dtsh}} is a variant of {{ dts}} that does not show the output. This also means that a parser function error such as invalid time is not shown and troubleshooting table sorting is painful. I would like to add some CSS so that the hidden output can be overridden in personal CSS:
/* Allow parser function error to be shown by user CSS */
span.parserfunctionerror {
display: none;
}
We can then update {{ dtsh}} to use this class. ---— Gadget850 (Ed) talk 17:58, 26 April 2012 (UTC)
displaynone
for more universal use. ---—
Gadget850 (Ed)
talk
14:58, 27 April 2012 (UTC)
The resolution of T34626 in 1.20 added a class to the default for MediaWiki:Cite references link one and MediaWiki:Cite references link many. This allows styling to remove the reference backlinks from in the printed version. To enable this, we would have to update the interface pages, since we use a custom version and add the class to Print.css. ---— Gadget850 (Ed) talk 02:26, 3 May 2012 (UTC)
.cite-backlink {display:none;}
to
MediaWiki:Print.css. ---—
Gadget850 (Ed)
talk
20:14, 3 May 2012 (UTC)The current full reversion is still bolding changes by default. Unhooray. Fifelfoo ( talk) 22:30, 10 May 2012 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I primarily work on highway articles, and I'd like to get our junction/exit list templates up to snuff on accessibility. It has been suggested that our mileposts function as the keyword for each individual row of these tables, and that they should have ! scope="row" |
coding. I've tested this in a table using class="wikitable plainrowheaders"
syntax, but that left-aligns the the column. As a column full of numbers with decimal points, those should remain right-aligned. I'm asking here for a simple fix. Can we have a class="wikitable plainrowheaders-right"
that would do the same thing, but right-align the text? Or can we change the coding that specifies that row headers using the current class must be left-aligned? Either works, and once something is implemented, I can update the templates used by us to add the row headers to thousands of highway articles' junction/exit lists. Thanks.
Imzadi 1979
→
05:16, 8 May 2012 (UTC)
<TH>
(table header). Most browsers will then render the cell as bold with centred text by default, but many editors prefer to see the data with its usual alignment and weight, because it is also data in that row of course.! scope="row" |
coding to existing tables. It seems to me that there is an exactly equivalent reasoning to support a "plainrowheaders-right" class for use where the keydata would normally be right-aligned, such as numbers. It would be less commonly used, I suspect; but for cases where it is useful, it would be clearly preferable to having to hard-code inline CSS such as ! scope="row" style="text-align:right;" |
on every row. I'd support this proposal. --
RexxS (
talk)
13:34, 8 May 2012 (UTC)![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Ok, since this doesn't seem controversial, and if it was, people would have jumped around here to oppose the suggestion by now given the brouhaha over the watchlists, I'm placing an edit request to have this added. Would an admin please add the following code?
/* Normal font styling for table row headers with scope="row" tag needing right alignment */ .wikitable.plainrowheaders-right th[scope=row] { font-weight: normal; /* @noflip */ text-align: right; }
It is exactly the same code used for class="wikitable plainrowheaders"
with two minor modifications: the right alignment and the name. Thanks,
Imzadi 1979
→
21:09, 11 May 2012 (UTC)
class="wikitable plainrowheaders"
. (The article I looked at used templates that use the core.) In short, I wouldn't have proposed a change to the CSS if the template would have worked with what's here already.
Imzadi 1979
→
22:23, 11 May 2012 (UTC)/* Right-align row header cells in tables */ .wikitable.th-right th[scope=row] { /* @noflip */ text-align: right; }
class="wikitable sortable plainrowheaders"
in an article, and it doesn't work. You can get sortable, or plainrowheaders, but not both because there isn't a "wikitable sortable plainrowheaders" class in the CSS. So if that's the case, we can't combine your class with the existing plainrowheaders class, unless there is something not documented someplace on how to combine two classes together.
Imzadi 1979
→
20:08, 15 May 2012 (UTC)
class="wikitable sortable plainrowheaders"
, but that's not an omission, it's the way that HTML 4 works. Class names cannot contain spaces - spaces are the separators between classes, and they are applied from left to right. So, when you specify class="wikitable sortable plainrowheaders"
, you're applying three separate classes in turn: first the wikitable
class is applied, then sortable
, then plainrowheaders
. If there are any contradictions, the one(s) which are applied later have precedence over the one(s) applied earlier. Thus, it's possible that plainrowheaders
overrides some or all of sortable
. Try exchanging the last two - class="wikitable plainrowheaders sortable"
- to see if that helps. --
Redrose64 (
talk)
21:25, 15 May 2012 (UTC)
class="wikitable sortable plainrowheaders"
that matters, it's the
specificity and the order they're defined in the CSS files or <style>
tags.
Anomie
⚔
01:24, 16 May 2012 (UTC)(Original thread: Template talk:Flatlist#Centering) Basically, the question is if we can add some functionality to make it possible to center a flatlist in a wikitable. For example, compare
|
with
|
or with
|
or with
|
the issue is with the code
.wikitable td ul, .wikitable td ol, .wikitable td dl { /* @noflip */ text-align: left; }
which seems sensible, but causes problems if we want to use an hlist. Frietjes ( talk) 17:54, 18 May 2012 (UTC)
/* lists in data cells are always left-aligned unless they also use the hlist class */ .wikitable.hlist td ul, .wikitable.hlist td ol, .wikitable.hlist td dl { text-align: inherit !important; }
.wikitable.hlist td ul
already has a higher specificity than .wikitable td ul
, and the !important makes it so you can't override it with <ul style="text-align:left">
if for some reason you want to do that.
Anomie
⚔
14:30, 19 May 2012 (UTC)
The people complaining about the button should deal with it until an alternative is in place, it's an aesthetic annoyance. Removing it entirely disables the ability for those of us who want to use this to mark pages, and functionally disables it. - ʄɭoʏɗiaɲ τ ¢ 16:19, 18 May 2012 (UTC)
After all the previous discussions and outcry, another unilateral step??? Seriously??? Please revert as per previous consensus. Nageh ( talk) 17:56, 18 May 2012 (UTC)
.mw-special-Watchlist #mw-watchlist-resetbutton { display: block; }
If this page weren't already admin-edit-only, it would have been protected by now; I'm somewhat tempted to full-protect it anyway just to make the point. The feature is disputed and a discussion is underway. You do not have the magic answer that everyone involved with the discussion will certainly agree with. As RnB says, leave the damn thing alone, in the Wrong Version ™, until it's finished. Failure to do so is wheel warring. Happy‑ melon 23:43, 23 May 2012 (UTC)
I'm in violent agreement with everyone that the current setup makes no sense.
But it is the current setup and every time you change it, by adding a green star or adding a "C" or changing bold to underline, or making the button visible or invisible, or maybe using some of that damned blinking text that drove everyone crazy twenty years ago, you force every user who has personalized their CSS for this feature to go back and do it again.
That's just unreasonable, even if it means that we have to live with an illogical interface for a couple of weeks.
This situation inspired me to write an essay: WP:NOTUS. — David Levy 00:13, 25 May 2012 (UTC)
I think you're significantly overstating the amount of "confusion" this situation actually causes. It's a button that has no apparent purpose; people click it, wonder what happened, and then move on.
I hardly think you'd be able to find many people who have given it anything more than a passing thought.
When considering what we do on Wikipedia, I fully endorse the point you're making in WP:NOTUS, and I think it's something that is all too often overlooked. The consideration of other editors has primacy when dictating what we should not do, and TWV, WP:BRD and so forth are all demonstrating why: the principle that we are a community that works collaboratively and always resolves differences of opinion by discussion and consensus, is more important than, and independent of, any individual issue.
We have left far more visible areas of Wikipedia in far greater disarray for far longer (like, IMO, many of the pages linked to from the Main Page, for about five years now) while we debate how best to deal with them. This is hardly the most egregious example.
And that seems fine to you? For thousands of users to discover a new button, attempt to use it, and wonder why it doesn't do anything?
Have we ever deliberately retained a broken setup that everyone agreed made no sense?
Of course it's not perfect. But Wikipedia isn't perfect.
Cough RFA. Cough Main Page. Cough ArbCom voting algorithm.
If we don't agree on how best to fix something, it tends to remain broken.
these >99.9% claims are bogus. Our readers don't have a watchlist; our editors do.
The button being there causes as much confusion as any big red button: You push it, then try to figure out if anything happened.
Having it there until a FINAL outcome is decided upon will not cause the sky to fall, will not break functionality, and will not make things difficult to read as the bold may to some.
It may perhaps confuse those who haven't encountered it yet, but our savvy editors can surely figure it out quickly enough.
As RnB mentioned though, having to update my css every two or three days is far more annoying than a button could ever be.
Is it feasible to insert a simple notation that the button is intended for use in conjunction with a feature currently disabled by default (accompanied by a link to instructions for enabling it)? While inelegant, that's vastly preferable to displaying a broken button without explanation. My primary objective is to eliminate the likelihood of confusion, one way or another. — David Levy 22:06, 25 May 2012 (UTC)
Remove any overrides you may have to restore the indicators (e.g. if you added green stars, remove the css for that). Then add this to your common.js:
importScript('User:Anomie/watchlist-change-style-selector.js'); // Linkback: [[User:Anomie/watchlist-change-style-selector.js]]
importStylesheet('User:Anomie/watchlist-change-style-selector.css'); // Linkback: [[User:Anomie/watchlist-change-style-selector.css]]
Then look near where the "Mark all pages visited" button was, and let me know what you think. Tested in Firefox and Chromium on Monobook and Vector, both with and without the "enhanced recent changes" option. Anomie ⚔ 02:18, 26 May 2012 (UTC)
Yesterday (I think), I noticed that I no longer have the small triangles that allow you to collapse and expand articles with multiple new edits (in ie9) in your watchlist. I have flushed my cache and rebooted to see if that was an issue, no change. It seems fine in Firefox still. Is this something that's been done by someone around here somewhere? Is it fixable? -- Despayre tête-à-tête 23:11, 29 May 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
The use of column-count css3 property causes [ issues on the mobile version of the page] Please introduce the following styles so that classes can be used instead on these elements where needed so that these can be optimised for mobile:
.column-count-2 {
-webkit-column-count:2;
-moz-column-count:2;
column-count:2;
}
.column-count-3 {
-webkit-column-count:3;
-moz-column-count:3;
column-count:3;
}
.column-count-4 {
-webkit-column-count:4;
-moz-column-count:4;
column-count:4;
}
.mobile .column-count-2,
.mobile .column-count-3,
.mobile .column-count-4 {
-moz-column-count:auto!important;
-webkit-column-count:auto!important;
column-count:auto!important;
-webkit-column-width:auto!important;
}
— Preceding unsigned comment added by Jdlrobson ( talk • contribs)
column-count
and column-width
in the manner described by using {{
column-count}} and {{
column-width}}. The example image does not show the mobile browser and version, nor the specific article, but it does appear to be non-English. Other language Wikipedias may implement columns in a different manner. ---—
Gadget850 (Ed)
talk
09:51, 6 June 2012 (UTC)![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Hello, I would like to implement an addition to the common.css in order to enable "tree" style lists. It is used on other language versions of wikipedia:
Extended content
|
---|
/* TREEVIEW */ .treeview ul { padding: 0; margin: 0; } .treeview li { padding: 0; margin: 0; list-style-type: none; list-style-image: none; zoom: 1; /* BE KIND TO IE6 */; } .treeview li li { background: url("https://upload.wikimedia.org/wikipedia/commons/f/f2/Treeview-grey-line.png") no-repeat 0 -2981px; padding-left: 20px; text-indent: 0.3em; } .treeview li li.lastline { background-position: 0 -5971px } .treeview li.emptyline > ul { margin-left: -1px; } .treeview li.emptyline > ul > li:first-child { background-position: 0 9px } |
Thanks -- UnQuébécois ( talk) 21:21, 14 June 2012 (UTC)
{{Arbre début}}
(which is essentially a <div class="treeview">
) and tailed with
{{Arbre fin}}
(which is essentially a </div>
). It actually looks quite good, and in visual terms is certainly easier to follow than our own
Line of succession to the British throne#Line of succession. --
Redrose64 (
talk)
13:24, 16 June 2012 (UTC)
{{Arbre/Branche finale}}
is essentially <li class="lastline">
. I guess we would also need to add
{{Arbre/Embranchement}}
(<li class="emptyline">
) and
{{Arbre/Embranchement final}}
(<li class="lastline emptyline">
), to complete the set. Of course, all these would need English names. --
Redrose64 (
talk)
15:46, 16 June 2012 (UTC)This is not really the place to discuss how we want Line of succession to the British throne#Line of succession to look, but to discuss adding the requested script to the css page to implement this type of list, but yes that is where all this started. I have already created the templates needed. I see this tree list being used in many other articles. {{TreeList start}}, {{TreeList end}}, {{TreeList/Branch}}, {{TreeList/Branch End}} and {{TreeList/Terminal Branch}}. I will work on the documentation (Translating and/or creating new) once this gets moving.-- UnQuébécois ( talk) 19:36, 16 June 2012 (UTC)
:last-child
pseudoclass. Or I suppose we could do away with it by running something like this from Common.js: if($.browser.msie && parseInt($.browser.version, 10) <= 8) {
$('.treeview li:last-child').addClass('last-child');
}
Added. I will look into importing those templates from fr. — Martin (
MSGJ ·
talk)
13:49, 22 June 2012 (UTC)
We are discussing on Template talk:Multiple issues a better way to deal with multiple issues with articles, by having {{ ambox}} collapse automatically to a more compact form when placed in a wrapper like {{ article issues}}. If this goes ahead it will involve adding some amount of code, written by User:Anomie, to this page so I am mentioning this here. If anyone is inclined to comment, perhaps they could do so over there. Thanks — Martin ( MSGJ · talk) 22:01, 14 June 2012 (UTC)
{{ editprotected}}
The coordinate display at the top the of the page is uncopy/pasteable as there no click area to start selecting without activating the link. The fix is to simply transfer right:
value to padding-right:
as
was done for Monobook already. This works for the following skins:
These skins will need another approach:
Now the default skin,
Vector, uses JavaScript adjusted padding between 16px to 24px. If we negative right alignments) are used (right:-15px;
, it risks showing horizontal scroll bars. It may be worth the risk as ~15% of clicks on GeoHack are of people selecting the plain text coordinates. —
Dispenser
21:22, 25 July 2012 (UTC)
display:none;
correctly and WikiMiniAtlas use to included alt text that copy before I got Dschwen to fix it. More importantly, Internet Explorer's glitchy selection behavior refuses to select the W, but works right to left. —
Dispenser
22:12, 25 July 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please, add the line:
span.texhtml, span.texhtml-big { font-family: MathJax_Math, serif; }
It will improve {{ math}} rendering for some users, see Wikipedia talk:WikiProject Mathematics#texhtml for explanations. Incnis Mrsi ( talk) 11:25, 27 July 2012 (UTC) 12:56, 27 July 2012 (UTC) P.S. Possibly, font-size should be increased too, we yet cannot decide it. It will become more clear when the change to font-family provided a feedback. Incnis Mrsi ( talk) 13:25, 27 July 2012 (UTC)
Hi, please see the dicussion at:
http://en.wikipedia.org/?title=Wikipedia:Help_desk&oldid=508714511#Compressing_notes_at_top_of_page — Preceding unsigned comment added by 86.179.6.55 ( talk) 03:01, 23 August 2012 (UTC)
The bullets of lists that are to the right of left flowing images are problematic. I was thinking that perhaps we could introduce something like we did with hlist. I'm calling it .listfloatfix for now. If you wrap the list in a div with this class, then you should have less trouble. There is one drawback, and that is that if the list is longer than the image, it won't flow around it, but remain indented. See also bugzilla:11782. — TheDJ ( talk • contribs) 13:01, 26 August 2012 (UTC)
.listfloatfix ol,
.listfloatfix ul,
.listfloatfix dl {
overflow: hidden;
list-style-position: inside;
padding-left: 1em;
}
.listfloatfix li,
.listfloatfix dd {
padding-left: 1.0em;
text-indent: -1.0em;
}
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
Needs some tweaking, because ol and ul behave differently (the space for bullets in ul need to be accounted for. Also no padding required for each li, and text-indent is also unnecessary). Numbered lists are a different beast, as the items will be aligned as if the numbers are part of the list item. — Edokter ( talk) — 13:54, 26 August 2012 (UTC)
.listfloatfix > ul {
overflow-x: hidden;
margin-left: 0em;
padding-left: 1.6em;
}
.listfloatfix > ol {
overflow-x: hidden;
margin-left: 0em;
padding-left: 3.2em;
}
.listfloatfix > dl {
overflow-x: hidden;
}
I'm sure you two already know this, but for anyone else following along: In a normal list, the <li>
blocks are laid out inside of the <ul>
block, with the bullets off the left edge of the first line inside the <li>
block; the <ul>
is laid out with an extra margin outside of its content box so there is room for the bullets to be displayed where they're supposed to be. When a left-floated image is involved, neither the <ul>
nor the <li>
blocks are affected (they extend "under" the image) but the line boxes are shortened to not overlap. The problem with this is that the bullets wind up in the wrong position: either they're left of the edge of the first line box (missing the extra margin they need, because that margin is far to the left under the image) or they're left of the edge of the <li>
block (underneath the image).
We can keep the <ul>
block from extending under the float by causing it to create a new "block formatting context", which in practice means we apply overflow:hidden
to it and which has the side effect that the bottom of the list doesn't wrap around the image if the list is longer than the image. But this hides the bullets, because they overflow. TheDJ's proposal moves the bullets to be elements in the text flow inside of the <li>
, and then plays with the first-line indentation versus the padding to make it look somewhat like the normal display (but this seems like it will have trouble with numbered lists). My proposal moves the extra "margin" from the outside of the <ul>
block's content area to the inside, but otherwise keeps the normal positioning of the bullet off the left of the first line of the <li>
block. A third proposal would be to move the overflow:hidden
to the <li>
(keeping those from extending under the image) and otherwise use TheDJ's proposal.
Or people could just stop using left-floated images next to lists. Anomie ⚔ 18:31, 26 August 2012 (UTC)
overflow:hidden
trick also prevents flowing around right-floated images (
example), and infoboxes and such too. I see no good reason to disable that likely-much-more-common case. And then there's the possibility of someone doing something unusual and the overflow:hidden
actually manages to hide something.
Anomie
⚔
21:29, 26 August 2012 (UTC)
.flowlist
class, and created {{
flowlist}} and {{
endflowlist}}, which can be used as a pair, or just use {{
flowlist}} and pass the list as {{{1}}}. —
Edokter (
talk) —
22:13, 26 August 2012 (UTC)Hi,
This change is syntactically invalid and breaks tools like Recess and W3C CSS validator. Please undo it.
Regards, Od1n ( talk) 20:27, 3 September 2012 (UTC)
border:
property, and has been permitted since CSS1 - indeed the
examples provided by W3C for CSS1, for
CSS2 and
CSS3 do exactly that. Note that the syntax is shown as
border: solid transparent;
and border: solid #000001;
both legal, they may also be written border: transparent solid;
and border: #000001 solid;
--
Redrose64 (
talk)
11:36, 4 September 2012 (UTC)
There are already some css entries to stop wrapping of indivdual list items in navboxes when they use the hlist class. Just thinking it would be good to include the same for infoboxes as well.
.infobox .hlist dd,
.infobox .hlist dt,
.infobox .hlist li {
white-space: nowrap; /* Nowrap list items in navboxes */
white-space: normal !ie; /* IE < 8 no-wraps entire list, so disable it */
}
.infobox .hlist dd dl,
.infobox .hlist dt dl,
.infobox .hlist li ol,
.infobox .hlist li ul {
white-space: normal; /* But allow parent list items to be wrapped */
}
And reasons not to? -- WOSlinker ( talk) 22:10, 7 August 2012 (UTC)
.hlist dd, etc.
? 「
ディノ奴
千?!」
? ·
☎ Dinoguy1000
22:25, 7 August 2012 (UTC)
The definition of the hlist class was recently
copied to Portuguese Wikipedia but when I
changed one of our templates the white-space: nowrap;
made the table cells to be wider than the width of the browser window, as if the property was set to the <ul>
element instead of each of the <li>
s. Does anyone knows how to fix that?
Helder
00:33, 16 August 2012 (UTC)
Nowrap doesn't really work well for long and narrow boxes. How to use hlist with wrapping turned off (like it was before)? GregorB ( talk) 21:28, 16 August 2012 (UTC)
I've created a simple test case on test.wikipedia.org. To see the problem, first enable the <gadget-hlist-test>, so that the CSS and JS related to the hlist class will be available. Then compare the following pages:
Using (at least) Chrome 21.0.1180.79 or Firefox 14.0.1, the items in the table appear all in one line in the third case, but in the first two cases it is normal, and only one item is shown on each line.
For some reason, MediaWiki mess up the HTML code when the MediaWiki:Recentchangestext page is added to the top of the Special:RecentChanges, and this breaks the formatting. Helder 15:25, 18 August 2012 (UTC)
...</li>
[linebreak]
<li>...
not having a linebreak in between (instead outputting ...</li>
<li>...
). This is a parser issue, and even invalid html. —
Edokter (
talk) —
15:59, 18 August 2012 (UTC)
</li>
<li>
is perfectly valid HTML. HTML doesn't require linebreaks anywhere, and (except within the <pre>...</pre>
element) treats all linebreaks outside of attribute values
as if they were simple spaces  
; they fall within the general category "whitespace". The <ul>...</ul>
element may contain only <li>...</li>
elements; whitespace between the <li>...</li>
elements is optional, not mandatory. --
Redrose64 (
talk)
17:40, 18 August 2012 (UTC)
<li>...</li>
tags as one word, hence it won't wrap in between. I don't know how to target only the textnode inside the list item in CSS; if someone can, I'd love to hear it. Until then, I think having to parser not strip the linebreaks in Special: pages is the most prudent way to go. —
Edokter (
talk) —
20:21, 18 August 2012 (UTC)
display:inline
have no independent existence. It's just that the whitespace between the list items is not inside any of the list items and so isn't affected by the nowrap on the list items. Also, it's not that the parser is stripping linebreaks between the </li>
and the following item's <li>
, it's that the wikitext list processing never generates linebreaks there in the first place (see
here); actually, Tidy is inserting these linebreaks when it processes normal pages..hlist dd:before,
.hlist li:before {
content: "\200b";
white-space: normal;
}
content: "\a"
(linefeed). This also fixed the IE6/7 problem nowrapping the entire list. Still, if you encounter a misbehaving hlist in IE6/7, please let me know. —
Edokter (
talk) —
12:58, 2 September 2012 (UTC).hnum
formatting! It depends on the entire list item to be no-wrap. I can't find a way around it. Either Mediawiki should let Tidy do Special: pages, or hlist should be banned from Special: pages. —
Edokter (
talk) —
21:45, 3 September 2012 (UTC)
.hlist.hnum ol li:before {
content: "\0a" counter(list-item) "\a0";
}
.hlist.hnum ol ol li:first-child:before {
content: "\0a(" counter(list-item) "\a0";
}
.hlist.hnum ol li::before(2)
or .hlist.hnum ol li::before::before
(
ref) are too new to be well supported yet.
Anomie
⚔
01:33, 4 September 2012 (UTC)
<ul>
, or Tidy strips it. Either way, this is not strictly related to hlist, as the error also happens without the hlist class. —
Edokter (
talk) —
08:46, 16 September 2012 (UTC)For the record, I reported one more parser bug after doing some tests to fix a problem we found while trying to use this with nested lists on ptwiki. Helder 19:40, 15 September 2012 (UTC)
I'm sure this has been discussed, but is there no fix for the trailing bullets with hlist on IE8? For example there is a trailing bullet on every line in Template:US 2012 presidential elections series, and there are no closing parenthesis. So, it seems like this is an issue with Win7/IE8 not using the "last-child" part? 198.102.153.1 ( talk) 16:15, 19 September 2012 (UTC)
:last-child
selector (but oddly it does understand :first-child
). —
Edokter (
talk) —
20:22, 19 September 2012 (UTC)The switch to HTML5 has raised various problems with alignment inheritance, but there is a longstanding problem with aligning all the cells in a table.
At present, even with the wikitable
class, table cells use default vertical alignment (vertical-align: center;
). Since wikitext prohibits adding internal style sheets, and table cells do not inherit the vertical alignment of the table element, there is no way to change the vertical alignment for all cells in a table without adding a separate style
attribute to each row.
A common desirable style is for all cells to be top-aligned (as is the default in typical spreadsheets, word-processing and DTP programs).
MediaWiki:Common.css currently applies this formatting only for .infobox td, .infobox th
. But it would be a useful option for non-infobox tables too.
I assume it would be too radical to change the default wikitable
styling. But some wikis
apparently define an additional toptextcells
class to allow the usual alignment to be overridden.
Presumably the CSS would be something like:
.toptextcells td,
.toptextcells th {
vertical-align: top;
}
or
.wikitable.toptextcells td,
.wikitable.toptextcells th {
vertical-align: top;
}
Could something like this be implemented on enwiki?
— Richardguk ( talk) 20:22, 21 September 2012 (UTC)
You are invited to participate in an RfC at Wikipedia talk:Requests for mediation/The Beatles on the issue of capitalising the definite article when mentioning that band's name in running prose. This long-standing dispute is the subject of an open mediation case and we are requesting your help with determining the current community consensus. Thank you for your time. For the mediators. ~ GabeMc ( talk| contribs) 23:35, 22 September 2012 (UTC)
Per
bug 40832, there is no point in
using @embed
here, because images loaded through an URL are not supported. Since the comment is inoffensive, maybe it is better to just add a link to the bug instead of removing it?
Helder
12:44, 8 October 2012 (UTC)
Hi.
Currently MediaWiki:Vector.css and MediaWiki:Monobook.css contain:
body.page-Main_Page h1.firstHeading { display:none; }
This hides the page title (h1) while ?title=Main_Page. This snippet applies to (the implicit) ?action=view, but it also applies to ?action=history, ?action=info, etc. I think it would be nice to limit this display:none; to only ?action=view. The header is removed for aesthetic reasons at ?action=view, but on the other actions, it's expected and its absence is a bit bothersome.
Any idea how difficult or easy this would be to implement this idea? Is there a "view" class or something that can be used? Would it require JavaScript? Any help on this would be appreciated. -- MZMcBride ( talk) 15:28, 13 October 2012 (UTC)
<body>
element also contains the action-view
class. So all that is needed is to add that class to the selector. —
Edokter (
talk) —
15:51, 13 October 2012 (UTC)?action=info
is linked (or hidden) from anywhere? Do we need to create a gadget to add/enable this link? —
Edokter (
talk) —
16:17, 13 October 2012 (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 10 | ← | Archive 12 | Archive 13 | Archive 14 | Archive 15 | Archive 16 | → | Archive 19 |
Since hlist has taken off, there are (sometimes slightly overenthousiastic) calls to turn everything into a hlist. When it was suggested that {{
navbar}} be turned into a hlist, I had to intervene. Though I understand the reasoning, I do think navbar is not a list. If the goal is to mask the various visual aspects from any elements from content in order to make it sematically correct, there are better ways. For instance, stuff like bullets, pipe symbols and other seperators that are not content, could be wrapped in a nocontent
class, which has the following properties:
.nocontent {
speak: none;
}
I don't know much about screenreaders and such (so it may need extra rules), but this would enable editors and template coders to hide the various visual elements from semantic content, such as the bullets in navbar. — Edokter ( talk) — 15:16, 24 November 2011 (UTC)
OK, have a look at the navbar sandbox version and its test page (and even the navbox test page). There remains a small spacing issue when used inline with brackets, but that scenario is never used AFAIK (I might as well remove the brackets option). Expect a lot of tweaking. Eventually, most navbar CSS will be moved to Common.css. — Edokter ( talk) — 15:19, 25 November 2011 (UTC)
As section title.
Nice to have the tools follow one down the page. Would be nice for WP:ACCESSIBILITY too. fredgandt 23:36, 24 November 2011 (UTC)
position:absolute;
set in the common.css but actually there is no mention of it. I guess it must be inherited? the only two absolute
's I can find are for navToggle and breadcrumbs. Confused as ever.
fredgandt
00:24, 25 November 2011 (UTC)
fixed
as you would not be able to scroll down all items if the entire list spans more then one screen, as is often the case with interwiki links. You can always put it in your personal CSS though. —
Edokter (
talk) —
01:02, 25 November 2011 (UTC)
← My eyes have grown sticky with the night so I've not yet looked at styling the scroll-bar (except that it can be done in webkit and apparently in IE (I am shocked!!)). Here's a quick demo of the basic stuff though.
<!DOCTYPE html> <html> <head> <style type="text/css"> #side-dish { position:fixed; background-color:#ddd; border:1px solid #888; top:8px; float:left; width:150px; height:700px; font-size:70%; overflow:auto; } #main-dish { margin-left:160px; border:1px solid #888; } p { margin:5px; } p:hover { color:#0f0; font-weight:bold; } </style> <script type="text/javascript"> var str; var count=0; document.write("<div id=\"main-dish\"></div>"); var md=document.getElementById("main-dish"); if(md) { while((++count)<201) { str="<p>"+count+"</p>"; md.innerHTML+=str; } } document.write("<div id=\"side-dish\"></div>"); var sd=document.getElementById("side-dish"); if(sd) { count=0; while((++count)<201) { str="<p>"+count+"</p>"; sd.innerHTML+=str; } } </script> </head> <body> </body> </html>
I don't think it's that bad even with the scroll-bar but I'll still look see if it can be styled (later). Thanks for the good luck wishes. I detest IE passionately. fredgandt 03:39, 25 November 2011 (UTC)
I still use a custom version of the Modern skin precisely because it was tweaked to keep the tabs and sidebar always visible; I find that to be a extremely convenient. I've been meaning to apply the same to the Vector skin, but haven't found the time to do it. I'd be happy to try on a custom style I could import to my vector.css and give feedback/offer further enhancements in return :)
(ps - I tried to
import your common.css but I saw no change even after clearing the cache. Does it work only with accompanying js? If so, would it be possible to make it work with css only?) --
Waldir
talk
11:50, 27 November 2011 (UTC)
@import url("
http://en.wikipedia.org/?title=User:Fred_Gandt/common.css&action=raw&ctype=text/css");
. Alternatively, you can use importStylesheet("User:Fred Gandt/common.css");
in your personal javascript file. —
Edokter (
talk) —
14:22, 27 November 2011 (UTC)#mw-panel { position:fixed !important; max-height:500px; overflow:auto; }
Currently there is a nice styling for the user signup form, why not applying it also for the user login form?
/* Makes it possible for the boxes in the Account Creation Process to overlap */ #userlogin, #userloginForm { margin:0; width:90% !important; max-width:100% !important; padding:1.5em; padding-top:0.75em !important; border:0; -moz-box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); -webkit-box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); -moz-border-radius: 7px; -webkit-border-radius: 7px; border-radius: 7px; background:white; background: #fff; background: -moz-linear-gradient(bottom, #fff 90%, #F5F5F5 100%); background: -webkit-gradient(linear, left bottom, left top, color-stop(90%,#fff), color-stop(100%,#F5F5F5)); background: -webkit-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: -o-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: -ms-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: linear-gradient(bottom, #fff 90%,#fff 100%); }
— Fitoschido [shout track] \\ 3 December, 2011 [20:32]
The font stacks in MediaWiki:Common.css/WinFixes.css are a true mess. Over the years, the list of exotic fonts has grown with every editor adding his/her own preferred font. Apart from the three or four MS fonts in the list, the rest of those fonts are mostly found on non-Windows machines, which is rather pointless since the file is only loaded on Windows(!). Why have fonts listed which have an installed base of less then 0.01%?
I think it is time for a cleanup, and prune this list to it's bare minimum. Therefor, I would like to do an inventory for the requirements and compile a list from scratch. Since most classes are intended to mostly fix IE issue, perhaps it is best to limit loading to IE only. Any used fonts should be readily available, preferably without requiring any downloads (as most Windows readers won't even bother with fonts). Then the list should be split into serif/sans-serif to match the several skins.
I can't do this alone, so I need input on the requirements and suggested fonts. What I can do is list the (unicode) fonts most likely available to Windows users (sorted by glyph count). — Edokter ( talk) — 21:46, 27 November 2011 (UTC)
I suspect this code should never have moved to Winfixex.css in the first place. Case in point: Template talk:Unicode#Patently useless. — Edokter ( talk) — 14:25, 1 December 2011 (UTC)
Another frustrating issue... Where IE8 and Firefox display unicode correctly, Chrome fails miserably with combining diacritics, but only under XP! This seems to be a long standing issue, judging from the miriad of bugs filed with Chromium, with no fix in sight. I'm am going to narrow the target for loading Winfixes.css to IE6/7 and Chrome under XP. — Edokter ( talk) — 19:24, 4 December 2011 (UTC)
After trimming the list, I eventually ended up with the two main unicode fonts for Windows for both {{ unicode}} and {{ IPA}}. Since it was now a single line of CSS, I opted to have it load directly in Common.js and remove WinFixes.css. Less clutter, one less HTTP request, so faster loading. — Edokter ( talk) — 22:57, 7 December 2011 (UTC)
I posted about this not too long ago but removed the thread since I chalked it up to PEBKAC... but on further inspection, this issue seems to be legitimate. I'm having trouble finding where in the CSS this is, but the navbox and templates that transclude the class (e.g., {{hat}}) no longer seem to center the title in Firefox and Opera, though it seems to work fine in IE. I'm not sure if there's something non-compliant in the CSS that's breaking that particular aspect of the class. The problem seems to have started not too long ago, and I suspected it might be this edit that's causing the issue, but I've tried reverting to the previous version already and the problem corrected itself temporarily, but is back now, which is quite odd. I'd rather not continue reverting and testing, but if someone else also has the same issue and can figure out what's going on, whether it's the CSS itself or something with MediaWiki, that would be helpful. Thanks. -- Kinu t/ c 22:18, 6 December 2011 (UTC)
text-align:center;
, but a better solution is to have a seperate class for these archive templates. —
Edokter (
talk) —
22:59, 6 December 2011 (UTC)I've got a couple style defs I'd like to add:
/* On wide screens, show these as two columns */
.portal-column-left {
float: left;
width: 50%;
}
.portal-column-right {
float: right;
width: 49%;
}
.portal-column-left-wide {
float: left;
width: 60%;
}
.portal-column-right-narrow {
float: right;
width: 39%;
}
@media only screen and (max-width: 800px) {
/* Decouple the columns on narrow screens */
.portal-column-left,
.portal-column-right,
.portal-column-left-wide,
.portal-column-right-narrow {
float: inherit;
width: inherit;
}
}
Many portal pages like Portal:Literature and Portal:Science create two-column layouts by wrapping a float-left and a float-right div with specified percentage widths in a bigger div with open & close. This looks great on a wide screen, but on narrow windows (especially on mobile screens!) you end up with a really ugly result such as Portal:Literature on mobile. Something like these styles should disable the floats & the fixed widths on narrower screens, so it automatically devolves into placing the two "columns" vertically, with no shrinkage: much nicer on a small mobile screen.
Any objection to adding these styles globally and trying swapping more of them in? Experimentally using them on Portal:Literature/Mobile redesign attempt. (only works if you add the styles to your .css or the globals, otherwise you'll see the one-column layout) -- brion ( talk) 22:09, 7 December 2011 (UTC)
.portal-column-full {
float: left;
width: 100%;
}
width: 100% important; float: inherit !important;
on mobile, rather than setting up different classes for each width and float location? --
Yair rand (
talk)
01:37, 8 December 2011 (UTC)The following, which was added as a sort of bridge while hlist is deployed to navboxes containing explicit padding styles, is not always being applied. There is a difference between the use of listclass=hlist
and bodyclass=hlist
.
.navbox .hlist td dl,
.navbox .hlist td ol,
.navbox .hlist td ul {
padding: 0.125em 0; /* Adjust hlist padding in navboxes */
}
In the case of 'body' the padding is applied, but not for 'list'. This is because for 'list' the class is being assigned to the TD, while for 'body' it is applied to the table itself (inner one, the TD's), and this result in the above selectors not matching; the class is on the TD, not above it.
See here where I changed to body and noticed a rendering change to all the rows (no comments on the single item list; it's a stub for anyone adding to the below item).
I'm thinking the above selectors need to be relaxed: drop the TDs. Maybe drop the navbox class, too. I think this was working but then changed. FWIW, this may be the time to drop it to 0.1em as widening the application of this after so many hlists have been deployed as 'list' will result in a lot of navboxes getting taller. Up to Edokter... Alarbus ( talk) 07:29, 8 December 2011 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
The desired line is:
table.infobox.geography.othername { font-size: 80% }
More details at Template_talk:Infobox_settlement#Resize_request SSzatmari ( talk) 15:51, 13 December 2011 (UTC)
Just wondering if we need the space before the colon in the rule
/* Generate interpuncts */
.hlist dt:after {
content: " :";
}
The place where I saw it used was {{ The Holocaust}}, where the spaces appeared to be extraneous. - CapitalR ( talk) 18:54, 16 December 2011 (UTC)
Note: I have added a link to this page from Village Pumps, e.g Wikipedia:Village pump (technical) (line four: "See also:..."). - DePiep ( talk) 19:37, 16 December 2011 (UTC)
In the example below, the colors are a little off, and both event and function names should be bold.
default { state_entry() { llSay(0,"Foobar!!"); } }
I'd be happy to provide a full example script containing all the components, if the styles can be improved.
In the example below, both the function names should be bold and dark blue.
var foo=encodeURI("blahdiblah");
var bar=encodeURIComponent("blahdiblah");
I'm sure if one function is not correctly styled, there must be others (functions, methods etc.). fredgandt 04:57, 18 December 2011 (UTC)
encodeURIComponent
. It would perhaps be an idea to create a test script for all languages supported, that we can use to keep tabs on the styling. Big job, but worth doing. I'll sort the LSL report out later.
fredgandt
06:03, 18 December 2011 (UTC)I replaced a hardcoded TOC in an article here and here. Is there a template for an hlist TOC? It would be even better if the presentation were similar to what was replaced, but I'm not sure if that is possible. Perhaps a TOC-hlist variation would be possible? Thank you! 174.56.57.138 ( talk) 15:07, 26 December 2011 (UTC)
Is there a way to pass css from the TOC definition down to the list? My particular case is
Template:MTGkeywordsTOC, where my "align=center" tags appear in the td
block, but the list css overrides that in the ul
block right inside it, as shown by Chrome:
<tr>
<td align="center">
<ul>
<li>
and
.mw-content-ltr .toc ul, .mw-content-ltr #toc ul, .mw-content-rtl .mw-content-ltr .toc ul, .mw-content-rtl .mw-content-ltr #toc ul {
text-align: left;
}
-- Temporarily Insane ( talk) 09:04, 3 January 2012 (UTC)
Text marked up with <code> is very small, as the second sentence in this example shows:
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.Can we make it a bit bigger, and thus more easily readable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:08, 21 January 2012 (UTC)
Does anyone know why we don't use "white-space:pre-wrap" or something similar to prevent text overflowing on the right? I have it in common.css on my MW installation, and I add it manually to any <pre> tags I use here without any ill effects I've noticed. I'm probably missing something obvious, though... Begoon talk 08:22, 25 January 2012 (UTC)
<pre>
is to format the text exactly as entered. If text breaks out, then it isn't formatted properly. (But I also have the pre-wrap in my CSS...) —
Edokter (
talk) —
11:22, 25 January 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Per
MediaWiki talk:Common.css/Archive 13#Styling for dfn tags, the following needs to be added, to prevent various browsers (not all – Chrome for one doesn't do it, but the change won't affect Chrome users at all) from auto-italicizing <dfn>...</dfn>
instances, which aside from being inconsistent doesn't agree with any use of italics sanctioned by
WP:MOS, and directly conflicts with a lot of things. The code:
/* Styling for defining instances of terms. */ dfn { font-style: inherit; }
The dfn
element is pure semantic markup, it is not typographic and should not be automatically visually distinct in any way, or problems immediately result, of many kinds. At this time, per that previous detailed discussion at which consensus was arrived at to make this change, only, and the fact that nothing's changed since then, no other styling needs to be applied for dfn, and none is envisioned an time soon, but this change definitely does need to happen. I've been having to manually work around the italics nonsense in {{
dfn}}, etc. —
SMcCandlish
Talk⇒〈°⌊°〉
Contribs.
23:49, 11 February 2012 (UTC)
<dfn>
now. Are there any examples where dfn is used raw? —
Edokter (
talk) —
00:36, 12 February 2012 (UTC)
<dfn>
with a CSS one-liner is so that every time someone is trying to use it, in a template or otherwise, they don't have to figure out WTF is going on and how to work around it when stuff italicizes for no apparent reason (and only some of the time, as various templates usable inside a <dfn>
could override the style, even aside from very likely browser problems; no one tested the issue on any of the profusion of *n*x browsers, for example, only Windows and Mac ones). Assuming they're even competent to work around it manually - not everyone knows CSS and how to add it to HTML elements. I don't know why we're arguing about this. There was already a consensus to do this, it just got archived and I forgot to editprotect-request it. Nothing has changed other than one browser's behavior (on the platform you tested it on), which isn't relevant anyway, because we want to avoid the italics universally (actually, the fact that Chrome is doing it now, too, strengthens not weakens the rationale – now no known browsers are doing what we want). —
SMcCandlish
Talk⇒〈°⌊°〉
Contribs. 01:44, 12 February 2012 (UTC) *Note: It's bogus because the W3C specs do not recommend it,
[3]
[4] and they don't even use it in the default all-browsers style sheet that the entire Web's display is essentially based on.
[5] What happened is either Netscape or IE, I forget which (probably IE, because their track record for standards compliance and weird experimentation was far worse) had it italicized this way back in the early to mid 1990s, and eventually the other one switched to emulate the competitor, then later browsers started doing what the big two of the era did, just to keep cranky designers happy, instead of doing what made sense. —
SMcCandlish
Talk⇒〈°⌊°〉
Contribs.
04:50, 12 February 2012 (UTC)
<cite>
in core (who's default is also italics), so that is where this should be done as well. In the mean time, I'll add it here. —
Edokter (
talk) —
11:25, 12 February 2012 (UTC)
Is the code for account creation still needed? — Edokter ( talk) — 00:40, 12 February 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Per suggestion on Village pump, could someone add the needed selectors to the formatting of NavFrames? The specific change is highlighted on that discussion. Helder 20:34, 31 August 2011 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I was wondering if is it too late to regret my choise of applying the styles directly to the mw-collapsible* classes. I was testing
an script which collapses old talk page threads on Portuguese Wikipedia and when I tried it on enwiki I realised that Anomie's suggestion would have been better than mine, because this change is indeed causing unwanted styling to appear on elements which we make collapsible by using mw-collapsible
(which force us to
override it every time).
So, could you revert that change? Helder 16:44, 14 February 2012 (UTC)
See MediaWiki talk:Common.js#Do not create NavFrame buttons if the new class "mw-collapsible" is used. Helder 14:05, 5 March 2012 (UTC)
An unresolved issue is discussed at Template talk:Birth date and age#Age doesn't show up on mobile wikipedia. Your assistance would be appreciated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:38, 20 February 2012 (UTC)
Hi, I do not have a clue how this stuff works, but FYI the following discussion:
Template talk:Navbox#Small bug
The spaces are clearly incorrect. If their inclusion really was an intentional design decision, then that decision was wrong (unless it was a compromise consequence of avoiding worse difficulties elsewhere, or something of that nature, of course). 86.177.105.189 ( talk) 03:52, 14 February 2012 (UTC)
Can this be fixed such that the trailing spaces before and after parentheses rising from the ** form of hlist are removed? Or encode it so the spaces only surround the interpunct instead of being placed before and after the list items?— Ryulong ( 竜龙) 09:30, 2 March 2012 (UTC)
Edokter (I got it), would anyone of your standing even contemplate this ugly try:
1. For the opening bracket, use ")" (our regular closing bracket). 2. Envelop it in RLO-PDF "bidi directional enforcing brackets": they write this single character R-to-L, not L-to-R (which is idle for an isolated single character) and since it is a bracket, bidi rule mirrors the bracket, using its mirror bracket: "(" 'closing bracket in R-to-L'. In code, it is RLO)PDF:
‮)‬
→ )<li>
tag as a hidden text node, and all browsers seperate text nodes and block element with a space. There is simply no way around that. Any attempt to circumvent this behaviour with tricks like direction-reversal or negative margins is bound to fail... believe me, I tried. —
Edokter (
talk) —
20:59, 4 March 2012 (UTC)
<ul>
and <li>
to be inline elements, not block elements. Consider the HTML output by MediaWiki for a fairly generic list:<div class="hlist">
<ul>
<li>foo
<ul>
<li>bar</li>
</ul>
</li>
<li>baz</li>
</ul>
</div>
display:inline
is given to the <ul>
and <li>
elements, it doesn't get ignored. And since the parens come "between" the linebreaks before/after the <ul>...</ul>
and the linebreaks before/after the first/last <li>
(the effective HTML with the generated parens is something like <li>foo (<ul> <li>bar</li> </ul>) </li>
), you get a space in the display. Unfortunately, there seems to be no way to get MediaWiki to output a list without these breaks, thanks to Tidy..hlist ul ul li:first-child:before
and .hlist ul ul li:last-child:after
instead (stupid IE<9), then the open/close parens would be after/before the newlines before/after the first/last <li>
and everything would render correctly (the effective HTML with the generated parens would be something like <li>foo <ul> (<li>bar</li>) </ul> </li>
). Or you could wait for browsers to support the CSS3 word-spacing
property and then try to get the word-spacing on the <ul>
s (but not the {{
li}}s) set to -100%
, causing the spaces to have zero width. Or you could wait for browsers to support CSS4 and the text-space-collapse:discard
property to use in the same manner..hlist ul ul li:first-child:before
and .hlist ul ul li:last-child:after
warrants some testing. However, I have IE8 to contend with, and IE6/7 may put up an even bigger fight. I'll report back. —
Edokter (
talk) —
09:47, 18 March 2012 (UTC)<ol>
. I didn't touch IE6/7 yet, I'll see about that later. Currently MediaWiki:Monobook.css still has the blue background tint on certain namespaces. I just noticed that MediaWiki:Vector.css doesn't have the same code, so only Monobook users are continuing to be punished by this (specifically Monobook users who haven't locally overridden it). Can the blue tint be dead? Please? -- MZMcBride ( talk) 23:21, 3 March 2012 (UTC)
.ns-talk #content {background-color: #FFFFC0; }
but some pages are still bluish, like "Contributions". MathewTownsend ( talk) 16:19, 19 March 2012 (UTC)
<body>...</body>
but which enclosed the <h1>...</h1>
and subsequent block elements. The source for this particular page showed that the choices were <body class="mediawiki ltr sitedir-ltr ns-9 ns-talk page-MediaWiki_talk_Common_css skin-monobook action-view">
<div id="globalWrapper">
<div id="column-content">
<div id="content">
- I picked the innermost id= (content
) and the most likely-looking class which would catch talk pages (ns-talk
), and then I styled that. The yellow was just a demonstration that shows a noticeable difference. You can pick any colour you like - white is #ffffff
. --
Redrose64 (
talk)
17:06, 19 March 2012 (UTC)
div#content {background-color: #FFFFFF; }
div#content {background-color: #FFFFFF; }
technique working in all namespaces. I fiddled about with classes because I was under the initial impression that the desired change was just to the background of talk pages, not of all pages. --
Redrose64 (
talk)
19:41, 19 March 2012 (UTC)
works beautifully! MathewTownsend ( talk) 20:03, 19 March 2012 (UTC)
Check the table on the right:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. |
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. |
foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a fadsoo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo adsa foo a foo a foo a foo a foo a foo a foo a foo adsada foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo dasa foo a foo aads foo a foo a foo a foo a foo a foo a foo a foo a asdfoo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a.
It seems to get fixed with a margin-left of 6px. -- Locos epraix 05:00, 16 January 2012 (UTC)
{| class="wikitable" style="width:30%; float:right; margin:13px 0px 13px 13px;" |- | {{Str left|{{Lorem ipsum}}|123}} |}
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. |
13px top, 13px right, 13px bottom, and 0px left
, just as the left floated table does. There may be another class that can be added to .wikitable
to alter the margins of right floating tables. Is that what you're after?
fredgandt
06:02, 16 January 2012 (UTC)
I like the idea of a .right class. But it would be nice if the .wikitable class (alone) looks good right aligned given it's widespread use. -- Locos epraix 15:31, 16 January 2012 (UTC)
{{ Dtsh}} is a variant of {{ dts}} that does not show the output. This also means that a parser function error such as invalid time is not shown and troubleshooting table sorting is painful. I would like to add some CSS so that the hidden output can be overridden in personal CSS:
/* Allow parser function error to be shown by user CSS */
span.parserfunctionerror {
display: none;
}
We can then update {{ dtsh}} to use this class. ---— Gadget850 (Ed) talk 17:58, 26 April 2012 (UTC)
displaynone
for more universal use. ---—
Gadget850 (Ed)
talk
14:58, 27 April 2012 (UTC)
The resolution of T34626 in 1.20 added a class to the default for MediaWiki:Cite references link one and MediaWiki:Cite references link many. This allows styling to remove the reference backlinks from in the printed version. To enable this, we would have to update the interface pages, since we use a custom version and add the class to Print.css. ---— Gadget850 (Ed) talk 02:26, 3 May 2012 (UTC)
.cite-backlink {display:none;}
to
MediaWiki:Print.css. ---—
Gadget850 (Ed)
talk
20:14, 3 May 2012 (UTC)The current full reversion is still bolding changes by default. Unhooray. Fifelfoo ( talk) 22:30, 10 May 2012 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I primarily work on highway articles, and I'd like to get our junction/exit list templates up to snuff on accessibility. It has been suggested that our mileposts function as the keyword for each individual row of these tables, and that they should have ! scope="row" |
coding. I've tested this in a table using class="wikitable plainrowheaders"
syntax, but that left-aligns the the column. As a column full of numbers with decimal points, those should remain right-aligned. I'm asking here for a simple fix. Can we have a class="wikitable plainrowheaders-right"
that would do the same thing, but right-align the text? Or can we change the coding that specifies that row headers using the current class must be left-aligned? Either works, and once something is implemented, I can update the templates used by us to add the row headers to thousands of highway articles' junction/exit lists. Thanks.
Imzadi 1979
→
05:16, 8 May 2012 (UTC)
<TH>
(table header). Most browsers will then render the cell as bold with centred text by default, but many editors prefer to see the data with its usual alignment and weight, because it is also data in that row of course.! scope="row" |
coding to existing tables. It seems to me that there is an exactly equivalent reasoning to support a "plainrowheaders-right" class for use where the keydata would normally be right-aligned, such as numbers. It would be less commonly used, I suspect; but for cases where it is useful, it would be clearly preferable to having to hard-code inline CSS such as ! scope="row" style="text-align:right;" |
on every row. I'd support this proposal. --
RexxS (
talk)
13:34, 8 May 2012 (UTC)![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Ok, since this doesn't seem controversial, and if it was, people would have jumped around here to oppose the suggestion by now given the brouhaha over the watchlists, I'm placing an edit request to have this added. Would an admin please add the following code?
/* Normal font styling for table row headers with scope="row" tag needing right alignment */ .wikitable.plainrowheaders-right th[scope=row] { font-weight: normal; /* @noflip */ text-align: right; }
It is exactly the same code used for class="wikitable plainrowheaders"
with two minor modifications: the right alignment and the name. Thanks,
Imzadi 1979
→
21:09, 11 May 2012 (UTC)
class="wikitable plainrowheaders"
. (The article I looked at used templates that use the core.) In short, I wouldn't have proposed a change to the CSS if the template would have worked with what's here already.
Imzadi 1979
→
22:23, 11 May 2012 (UTC)/* Right-align row header cells in tables */ .wikitable.th-right th[scope=row] { /* @noflip */ text-align: right; }
class="wikitable sortable plainrowheaders"
in an article, and it doesn't work. You can get sortable, or plainrowheaders, but not both because there isn't a "wikitable sortable plainrowheaders" class in the CSS. So if that's the case, we can't combine your class with the existing plainrowheaders class, unless there is something not documented someplace on how to combine two classes together.
Imzadi 1979
→
20:08, 15 May 2012 (UTC)
class="wikitable sortable plainrowheaders"
, but that's not an omission, it's the way that HTML 4 works. Class names cannot contain spaces - spaces are the separators between classes, and they are applied from left to right. So, when you specify class="wikitable sortable plainrowheaders"
, you're applying three separate classes in turn: first the wikitable
class is applied, then sortable
, then plainrowheaders
. If there are any contradictions, the one(s) which are applied later have precedence over the one(s) applied earlier. Thus, it's possible that plainrowheaders
overrides some or all of sortable
. Try exchanging the last two - class="wikitable plainrowheaders sortable"
- to see if that helps. --
Redrose64 (
talk)
21:25, 15 May 2012 (UTC)
class="wikitable sortable plainrowheaders"
that matters, it's the
specificity and the order they're defined in the CSS files or <style>
tags.
Anomie
⚔
01:24, 16 May 2012 (UTC)(Original thread: Template talk:Flatlist#Centering) Basically, the question is if we can add some functionality to make it possible to center a flatlist in a wikitable. For example, compare
|
with
|
or with
|
or with
|
the issue is with the code
.wikitable td ul, .wikitable td ol, .wikitable td dl { /* @noflip */ text-align: left; }
which seems sensible, but causes problems if we want to use an hlist. Frietjes ( talk) 17:54, 18 May 2012 (UTC)
/* lists in data cells are always left-aligned unless they also use the hlist class */ .wikitable.hlist td ul, .wikitable.hlist td ol, .wikitable.hlist td dl { text-align: inherit !important; }
.wikitable.hlist td ul
already has a higher specificity than .wikitable td ul
, and the !important makes it so you can't override it with <ul style="text-align:left">
if for some reason you want to do that.
Anomie
⚔
14:30, 19 May 2012 (UTC)
The people complaining about the button should deal with it until an alternative is in place, it's an aesthetic annoyance. Removing it entirely disables the ability for those of us who want to use this to mark pages, and functionally disables it. - ʄɭoʏɗiaɲ τ ¢ 16:19, 18 May 2012 (UTC)
After all the previous discussions and outcry, another unilateral step??? Seriously??? Please revert as per previous consensus. Nageh ( talk) 17:56, 18 May 2012 (UTC)
.mw-special-Watchlist #mw-watchlist-resetbutton { display: block; }
If this page weren't already admin-edit-only, it would have been protected by now; I'm somewhat tempted to full-protect it anyway just to make the point. The feature is disputed and a discussion is underway. You do not have the magic answer that everyone involved with the discussion will certainly agree with. As RnB says, leave the damn thing alone, in the Wrong Version ™, until it's finished. Failure to do so is wheel warring. Happy‑ melon 23:43, 23 May 2012 (UTC)
I'm in violent agreement with everyone that the current setup makes no sense.
But it is the current setup and every time you change it, by adding a green star or adding a "C" or changing bold to underline, or making the button visible or invisible, or maybe using some of that damned blinking text that drove everyone crazy twenty years ago, you force every user who has personalized their CSS for this feature to go back and do it again.
That's just unreasonable, even if it means that we have to live with an illogical interface for a couple of weeks.
This situation inspired me to write an essay: WP:NOTUS. — David Levy 00:13, 25 May 2012 (UTC)
I think you're significantly overstating the amount of "confusion" this situation actually causes. It's a button that has no apparent purpose; people click it, wonder what happened, and then move on.
I hardly think you'd be able to find many people who have given it anything more than a passing thought.
When considering what we do on Wikipedia, I fully endorse the point you're making in WP:NOTUS, and I think it's something that is all too often overlooked. The consideration of other editors has primacy when dictating what we should not do, and TWV, WP:BRD and so forth are all demonstrating why: the principle that we are a community that works collaboratively and always resolves differences of opinion by discussion and consensus, is more important than, and independent of, any individual issue.
We have left far more visible areas of Wikipedia in far greater disarray for far longer (like, IMO, many of the pages linked to from the Main Page, for about five years now) while we debate how best to deal with them. This is hardly the most egregious example.
And that seems fine to you? For thousands of users to discover a new button, attempt to use it, and wonder why it doesn't do anything?
Have we ever deliberately retained a broken setup that everyone agreed made no sense?
Of course it's not perfect. But Wikipedia isn't perfect.
Cough RFA. Cough Main Page. Cough ArbCom voting algorithm.
If we don't agree on how best to fix something, it tends to remain broken.
these >99.9% claims are bogus. Our readers don't have a watchlist; our editors do.
The button being there causes as much confusion as any big red button: You push it, then try to figure out if anything happened.
Having it there until a FINAL outcome is decided upon will not cause the sky to fall, will not break functionality, and will not make things difficult to read as the bold may to some.
It may perhaps confuse those who haven't encountered it yet, but our savvy editors can surely figure it out quickly enough.
As RnB mentioned though, having to update my css every two or three days is far more annoying than a button could ever be.
Is it feasible to insert a simple notation that the button is intended for use in conjunction with a feature currently disabled by default (accompanied by a link to instructions for enabling it)? While inelegant, that's vastly preferable to displaying a broken button without explanation. My primary objective is to eliminate the likelihood of confusion, one way or another. — David Levy 22:06, 25 May 2012 (UTC)
Remove any overrides you may have to restore the indicators (e.g. if you added green stars, remove the css for that). Then add this to your common.js:
importScript('User:Anomie/watchlist-change-style-selector.js'); // Linkback: [[User:Anomie/watchlist-change-style-selector.js]]
importStylesheet('User:Anomie/watchlist-change-style-selector.css'); // Linkback: [[User:Anomie/watchlist-change-style-selector.css]]
Then look near where the "Mark all pages visited" button was, and let me know what you think. Tested in Firefox and Chromium on Monobook and Vector, both with and without the "enhanced recent changes" option. Anomie ⚔ 02:18, 26 May 2012 (UTC)
Yesterday (I think), I noticed that I no longer have the small triangles that allow you to collapse and expand articles with multiple new edits (in ie9) in your watchlist. I have flushed my cache and rebooted to see if that was an issue, no change. It seems fine in Firefox still. Is this something that's been done by someone around here somewhere? Is it fixable? -- Despayre tête-à-tête 23:11, 29 May 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
The use of column-count css3 property causes [ issues on the mobile version of the page] Please introduce the following styles so that classes can be used instead on these elements where needed so that these can be optimised for mobile:
.column-count-2 {
-webkit-column-count:2;
-moz-column-count:2;
column-count:2;
}
.column-count-3 {
-webkit-column-count:3;
-moz-column-count:3;
column-count:3;
}
.column-count-4 {
-webkit-column-count:4;
-moz-column-count:4;
column-count:4;
}
.mobile .column-count-2,
.mobile .column-count-3,
.mobile .column-count-4 {
-moz-column-count:auto!important;
-webkit-column-count:auto!important;
column-count:auto!important;
-webkit-column-width:auto!important;
}
— Preceding unsigned comment added by Jdlrobson ( talk • contribs)
column-count
and column-width
in the manner described by using {{
column-count}} and {{
column-width}}. The example image does not show the mobile browser and version, nor the specific article, but it does appear to be non-English. Other language Wikipedias may implement columns in a different manner. ---—
Gadget850 (Ed)
talk
09:51, 6 June 2012 (UTC)![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Hello, I would like to implement an addition to the common.css in order to enable "tree" style lists. It is used on other language versions of wikipedia:
Extended content
|
---|
/* TREEVIEW */ .treeview ul { padding: 0; margin: 0; } .treeview li { padding: 0; margin: 0; list-style-type: none; list-style-image: none; zoom: 1; /* BE KIND TO IE6 */; } .treeview li li { background: url("https://upload.wikimedia.org/wikipedia/commons/f/f2/Treeview-grey-line.png") no-repeat 0 -2981px; padding-left: 20px; text-indent: 0.3em; } .treeview li li.lastline { background-position: 0 -5971px } .treeview li.emptyline > ul { margin-left: -1px; } .treeview li.emptyline > ul > li:first-child { background-position: 0 9px } |
Thanks -- UnQuébécois ( talk) 21:21, 14 June 2012 (UTC)
{{Arbre début}}
(which is essentially a <div class="treeview">
) and tailed with
{{Arbre fin}}
(which is essentially a </div>
). It actually looks quite good, and in visual terms is certainly easier to follow than our own
Line of succession to the British throne#Line of succession. --
Redrose64 (
talk)
13:24, 16 June 2012 (UTC)
{{Arbre/Branche finale}}
is essentially <li class="lastline">
. I guess we would also need to add
{{Arbre/Embranchement}}
(<li class="emptyline">
) and
{{Arbre/Embranchement final}}
(<li class="lastline emptyline">
), to complete the set. Of course, all these would need English names. --
Redrose64 (
talk)
15:46, 16 June 2012 (UTC)This is not really the place to discuss how we want Line of succession to the British throne#Line of succession to look, but to discuss adding the requested script to the css page to implement this type of list, but yes that is where all this started. I have already created the templates needed. I see this tree list being used in many other articles. {{TreeList start}}, {{TreeList end}}, {{TreeList/Branch}}, {{TreeList/Branch End}} and {{TreeList/Terminal Branch}}. I will work on the documentation (Translating and/or creating new) once this gets moving.-- UnQuébécois ( talk) 19:36, 16 June 2012 (UTC)
:last-child
pseudoclass. Or I suppose we could do away with it by running something like this from Common.js: if($.browser.msie && parseInt($.browser.version, 10) <= 8) {
$('.treeview li:last-child').addClass('last-child');
}
Added. I will look into importing those templates from fr. — Martin (
MSGJ ·
talk)
13:49, 22 June 2012 (UTC)
We are discussing on Template talk:Multiple issues a better way to deal with multiple issues with articles, by having {{ ambox}} collapse automatically to a more compact form when placed in a wrapper like {{ article issues}}. If this goes ahead it will involve adding some amount of code, written by User:Anomie, to this page so I am mentioning this here. If anyone is inclined to comment, perhaps they could do so over there. Thanks — Martin ( MSGJ · talk) 22:01, 14 June 2012 (UTC)
{{ editprotected}}
The coordinate display at the top the of the page is uncopy/pasteable as there no click area to start selecting without activating the link. The fix is to simply transfer right:
value to padding-right:
as
was done for Monobook already. This works for the following skins:
These skins will need another approach:
Now the default skin,
Vector, uses JavaScript adjusted padding between 16px to 24px. If we negative right alignments) are used (right:-15px;
, it risks showing horizontal scroll bars. It may be worth the risk as ~15% of clicks on GeoHack are of people selecting the plain text coordinates. —
Dispenser
21:22, 25 July 2012 (UTC)
display:none;
correctly and WikiMiniAtlas use to included alt text that copy before I got Dschwen to fix it. More importantly, Internet Explorer's glitchy selection behavior refuses to select the W, but works right to left. —
Dispenser
22:12, 25 July 2012 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please, add the line:
span.texhtml, span.texhtml-big { font-family: MathJax_Math, serif; }
It will improve {{ math}} rendering for some users, see Wikipedia talk:WikiProject Mathematics#texhtml for explanations. Incnis Mrsi ( talk) 11:25, 27 July 2012 (UTC) 12:56, 27 July 2012 (UTC) P.S. Possibly, font-size should be increased too, we yet cannot decide it. It will become more clear when the change to font-family provided a feedback. Incnis Mrsi ( talk) 13:25, 27 July 2012 (UTC)
Hi, please see the dicussion at:
http://en.wikipedia.org/?title=Wikipedia:Help_desk&oldid=508714511#Compressing_notes_at_top_of_page — Preceding unsigned comment added by 86.179.6.55 ( talk) 03:01, 23 August 2012 (UTC)
The bullets of lists that are to the right of left flowing images are problematic. I was thinking that perhaps we could introduce something like we did with hlist. I'm calling it .listfloatfix for now. If you wrap the list in a div with this class, then you should have less trouble. There is one drawback, and that is that if the list is longer than the image, it won't flow around it, but remain indented. See also bugzilla:11782. — TheDJ ( talk • contribs) 13:01, 26 August 2012 (UTC)
.listfloatfix ol,
.listfloatfix ul,
.listfloatfix dl {
overflow: hidden;
list-style-position: inside;
padding-left: 1em;
}
.listfloatfix li,
.listfloatfix dd {
padding-left: 1.0em;
text-indent: -1.0em;
}
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
Needs some tweaking, because ol and ul behave differently (the space for bullets in ul need to be accounted for. Also no padding required for each li, and text-indent is also unnecessary). Numbered lists are a different beast, as the items will be aligned as if the numbers are part of the list item. — Edokter ( talk) — 13:54, 26 August 2012 (UTC)
.listfloatfix > ul {
overflow-x: hidden;
margin-left: 0em;
padding-left: 1.6em;
}
.listfloatfix > ol {
overflow-x: hidden;
margin-left: 0em;
padding-left: 3.2em;
}
.listfloatfix > dl {
overflow-x: hidden;
}
I'm sure you two already know this, but for anyone else following along: In a normal list, the <li>
blocks are laid out inside of the <ul>
block, with the bullets off the left edge of the first line inside the <li>
block; the <ul>
is laid out with an extra margin outside of its content box so there is room for the bullets to be displayed where they're supposed to be. When a left-floated image is involved, neither the <ul>
nor the <li>
blocks are affected (they extend "under" the image) but the line boxes are shortened to not overlap. The problem with this is that the bullets wind up in the wrong position: either they're left of the edge of the first line box (missing the extra margin they need, because that margin is far to the left under the image) or they're left of the edge of the <li>
block (underneath the image).
We can keep the <ul>
block from extending under the float by causing it to create a new "block formatting context", which in practice means we apply overflow:hidden
to it and which has the side effect that the bottom of the list doesn't wrap around the image if the list is longer than the image. But this hides the bullets, because they overflow. TheDJ's proposal moves the bullets to be elements in the text flow inside of the <li>
, and then plays with the first-line indentation versus the padding to make it look somewhat like the normal display (but this seems like it will have trouble with numbered lists). My proposal moves the extra "margin" from the outside of the <ul>
block's content area to the inside, but otherwise keeps the normal positioning of the bullet off the left of the first line of the <li>
block. A third proposal would be to move the overflow:hidden
to the <li>
(keeping those from extending under the image) and otherwise use TheDJ's proposal.
Or people could just stop using left-floated images next to lists. Anomie ⚔ 18:31, 26 August 2012 (UTC)
overflow:hidden
trick also prevents flowing around right-floated images (
example), and infoboxes and such too. I see no good reason to disable that likely-much-more-common case. And then there's the possibility of someone doing something unusual and the overflow:hidden
actually manages to hide something.
Anomie
⚔
21:29, 26 August 2012 (UTC)
.flowlist
class, and created {{
flowlist}} and {{
endflowlist}}, which can be used as a pair, or just use {{
flowlist}} and pass the list as {{{1}}}. —
Edokter (
talk) —
22:13, 26 August 2012 (UTC)Hi,
This change is syntactically invalid and breaks tools like Recess and W3C CSS validator. Please undo it.
Regards, Od1n ( talk) 20:27, 3 September 2012 (UTC)
border:
property, and has been permitted since CSS1 - indeed the
examples provided by W3C for CSS1, for
CSS2 and
CSS3 do exactly that. Note that the syntax is shown as
border: solid transparent;
and border: solid #000001;
both legal, they may also be written border: transparent solid;
and border: #000001 solid;
--
Redrose64 (
talk)
11:36, 4 September 2012 (UTC)
There are already some css entries to stop wrapping of indivdual list items in navboxes when they use the hlist class. Just thinking it would be good to include the same for infoboxes as well.
.infobox .hlist dd,
.infobox .hlist dt,
.infobox .hlist li {
white-space: nowrap; /* Nowrap list items in navboxes */
white-space: normal !ie; /* IE < 8 no-wraps entire list, so disable it */
}
.infobox .hlist dd dl,
.infobox .hlist dt dl,
.infobox .hlist li ol,
.infobox .hlist li ul {
white-space: normal; /* But allow parent list items to be wrapped */
}
And reasons not to? -- WOSlinker ( talk) 22:10, 7 August 2012 (UTC)
.hlist dd, etc.
? 「
ディノ奴
千?!」
? ·
☎ Dinoguy1000
22:25, 7 August 2012 (UTC)
The definition of the hlist class was recently
copied to Portuguese Wikipedia but when I
changed one of our templates the white-space: nowrap;
made the table cells to be wider than the width of the browser window, as if the property was set to the <ul>
element instead of each of the <li>
s. Does anyone knows how to fix that?
Helder
00:33, 16 August 2012 (UTC)
Nowrap doesn't really work well for long and narrow boxes. How to use hlist with wrapping turned off (like it was before)? GregorB ( talk) 21:28, 16 August 2012 (UTC)
I've created a simple test case on test.wikipedia.org. To see the problem, first enable the <gadget-hlist-test>, so that the CSS and JS related to the hlist class will be available. Then compare the following pages:
Using (at least) Chrome 21.0.1180.79 or Firefox 14.0.1, the items in the table appear all in one line in the third case, but in the first two cases it is normal, and only one item is shown on each line.
For some reason, MediaWiki mess up the HTML code when the MediaWiki:Recentchangestext page is added to the top of the Special:RecentChanges, and this breaks the formatting. Helder 15:25, 18 August 2012 (UTC)
...</li>
[linebreak]
<li>...
not having a linebreak in between (instead outputting ...</li>
<li>...
). This is a parser issue, and even invalid html. —
Edokter (
talk) —
15:59, 18 August 2012 (UTC)
</li>
<li>
is perfectly valid HTML. HTML doesn't require linebreaks anywhere, and (except within the <pre>...</pre>
element) treats all linebreaks outside of attribute values
as if they were simple spaces  
; they fall within the general category "whitespace". The <ul>...</ul>
element may contain only <li>...</li>
elements; whitespace between the <li>...</li>
elements is optional, not mandatory. --
Redrose64 (
talk)
17:40, 18 August 2012 (UTC)
<li>...</li>
tags as one word, hence it won't wrap in between. I don't know how to target only the textnode inside the list item in CSS; if someone can, I'd love to hear it. Until then, I think having to parser not strip the linebreaks in Special: pages is the most prudent way to go. —
Edokter (
talk) —
20:21, 18 August 2012 (UTC)
display:inline
have no independent existence. It's just that the whitespace between the list items is not inside any of the list items and so isn't affected by the nowrap on the list items. Also, it's not that the parser is stripping linebreaks between the </li>
and the following item's <li>
, it's that the wikitext list processing never generates linebreaks there in the first place (see
here); actually, Tidy is inserting these linebreaks when it processes normal pages..hlist dd:before,
.hlist li:before {
content: "\200b";
white-space: normal;
}
content: "\a"
(linefeed). This also fixed the IE6/7 problem nowrapping the entire list. Still, if you encounter a misbehaving hlist in IE6/7, please let me know. —
Edokter (
talk) —
12:58, 2 September 2012 (UTC).hnum
formatting! It depends on the entire list item to be no-wrap. I can't find a way around it. Either Mediawiki should let Tidy do Special: pages, or hlist should be banned from Special: pages. —
Edokter (
talk) —
21:45, 3 September 2012 (UTC)
.hlist.hnum ol li:before {
content: "\0a" counter(list-item) "\a0";
}
.hlist.hnum ol ol li:first-child:before {
content: "\0a(" counter(list-item) "\a0";
}
.hlist.hnum ol li::before(2)
or .hlist.hnum ol li::before::before
(
ref) are too new to be well supported yet.
Anomie
⚔
01:33, 4 September 2012 (UTC)
<ul>
, or Tidy strips it. Either way, this is not strictly related to hlist, as the error also happens without the hlist class. —
Edokter (
talk) —
08:46, 16 September 2012 (UTC)For the record, I reported one more parser bug after doing some tests to fix a problem we found while trying to use this with nested lists on ptwiki. Helder 19:40, 15 September 2012 (UTC)
I'm sure this has been discussed, but is there no fix for the trailing bullets with hlist on IE8? For example there is a trailing bullet on every line in Template:US 2012 presidential elections series, and there are no closing parenthesis. So, it seems like this is an issue with Win7/IE8 not using the "last-child" part? 198.102.153.1 ( talk) 16:15, 19 September 2012 (UTC)
:last-child
selector (but oddly it does understand :first-child
). —
Edokter (
talk) —
20:22, 19 September 2012 (UTC)The switch to HTML5 has raised various problems with alignment inheritance, but there is a longstanding problem with aligning all the cells in a table.
At present, even with the wikitable
class, table cells use default vertical alignment (vertical-align: center;
). Since wikitext prohibits adding internal style sheets, and table cells do not inherit the vertical alignment of the table element, there is no way to change the vertical alignment for all cells in a table without adding a separate style
attribute to each row.
A common desirable style is for all cells to be top-aligned (as is the default in typical spreadsheets, word-processing and DTP programs).
MediaWiki:Common.css currently applies this formatting only for .infobox td, .infobox th
. But it would be a useful option for non-infobox tables too.
I assume it would be too radical to change the default wikitable
styling. But some wikis
apparently define an additional toptextcells
class to allow the usual alignment to be overridden.
Presumably the CSS would be something like:
.toptextcells td,
.toptextcells th {
vertical-align: top;
}
or
.wikitable.toptextcells td,
.wikitable.toptextcells th {
vertical-align: top;
}
Could something like this be implemented on enwiki?
— Richardguk ( talk) 20:22, 21 September 2012 (UTC)
You are invited to participate in an RfC at Wikipedia talk:Requests for mediation/The Beatles on the issue of capitalising the definite article when mentioning that band's name in running prose. This long-standing dispute is the subject of an open mediation case and we are requesting your help with determining the current community consensus. Thank you for your time. For the mediators. ~ GabeMc ( talk| contribs) 23:35, 22 September 2012 (UTC)
Per
bug 40832, there is no point in
using @embed
here, because images loaded through an URL are not supported. Since the comment is inoffensive, maybe it is better to just add a link to the bug instead of removing it?
Helder
12:44, 8 October 2012 (UTC)
Hi.
Currently MediaWiki:Vector.css and MediaWiki:Monobook.css contain:
body.page-Main_Page h1.firstHeading { display:none; }
This hides the page title (h1) while ?title=Main_Page. This snippet applies to (the implicit) ?action=view, but it also applies to ?action=history, ?action=info, etc. I think it would be nice to limit this display:none; to only ?action=view. The header is removed for aesthetic reasons at ?action=view, but on the other actions, it's expected and its absence is a bit bothersome.
Any idea how difficult or easy this would be to implement this idea? Is there a "view" class or something that can be used? Would it require JavaScript? Any help on this would be appreciated. -- MZMcBride ( talk) 15:28, 13 October 2012 (UTC)
<body>
element also contains the action-view
class. So all that is needed is to add that class to the selector. —
Edokter (
talk) —
15:51, 13 October 2012 (UTC)?action=info
is linked (or hidden) from anywhere? Do we need to create a gadget to add/enable this link? —
Edokter (
talk) —
16:17, 13 October 2012 (UTC)