MediaWiki talk:Vector.css/Archive 1

Background of lists
How do we change the background color of lists created by or *? Currently the color is white, instead of transparent. Then we have this code: generating this (use the vector skin):   A  B  Note the background color of the circle. Helder (talk) 21:41, 4 July 2009 (UTC)


 * This is a known issue with the vector skin 19514. This is just the first iteration of the skin, and refinements will folllow. —Th e DJ (talk • contribs) 22:37, 4 July 2009 (UTC)
 * Thanks for the link to bugzilla ;-) Helder (talk) 15:01, 5 July 2009 (UTC)

White space
Could someone add the following code, please? It temporarily fixes a white space bug. I already reported it on 19567. Thanks in advance.--Totie (talk) 19:25, 7 July 2009 (UTC)
 * 1) SiteNotice { padding: 0 0.9em; }
 * Looks reasonable enough; ✅. 「 ダイノ ガイ 千？！ 」? · Talk⇒Dinoguy1000 20:05, 7 July 2009 (UTC)
 * My mistake, it should be, not   (capitalization).--Totie (talk) 20:51, 7 July 2009 (UTC)
 * Fixed. I also added the relative bodyContent that is added in the future r52855, when this rev is deployed, it can be removed from this page again. We also should have more sensible coordinates and topicon positioning. —Th e DJ (talk • contribs) 21:28, 7 July 2009 (UTC)
 * Thank you.--Totie (talk) 21:35, 7 July 2009 (UTC)

It seems to be fixed now. The bug was fixed in r52855, and the current version of en.wikipedia.org is r53410.--Totie (talk) 09:43, 18 July 2009 (UTC)
 * This is not yet fixed. I'll reopen the bug. —Th e DJ (talk • contribs) 10:43, 18 July 2009 (UTC)
 * It's now really fixed with 67784 and 67928 and has just been deployed with 70605, please remove the workaround. --Entlinkt (talk) 04:36, 7 August 2010 (UTC)

Navbox skinning: font-size
For some reason navboxes are showing up without the smaller font-size declaration that is in Common.css, making Navbox text appear larger than in Monobook. I just cleared my cache and the problem persisted. --Izno (talk) 21:13, 8 July 2009 (UTC)
 * Please always provide examples and browser version. —Th e DJ (talk • contribs) 21:20, 8 July 2009 (UTC)
 * This is already fixed upstream by this. Since all Vector fixes are likely to be deployed today or tomorrow, I won't add any specific rules for this. —Th e DJ (talk • contribs) 21:26, 8 July 2009 (UTC)
 * K, thx for checking. Not a big issue. --Izno (talk) 22:26, 8 July 2009 (UTC)

Logo
Perhaps you could add the following code, to show the full logo (uncropped). Here's a picture of the bug (Safari 4). --Totie (talk) 16:29, 9 July 2009 (UTC)
 * I do not see this problem (Safari 4 as well). Do you have any gadgets or javascript enabled that might be influencing this ? —Th e DJ (talk • contribs) 16:49, 9 July 2009 (UTC)
 * I found the error. I set my default font-size to 13px (browser default is 16px). MediaWiki scales down the relative size of the logo box and cuts off a small margin of the logo. Very annoying I must say, since I rely on the font-size. Perhaps I can address this at Bugzilla.--Totie (talk) 17:33, 9 July 2009 (UTC)

TOC indents
It's bothered me for a while that the TOC doesn't indent subheadings in Vector like it does in Monobook (not to mention it hurts usability). Are there any bug reports on this, and can we add a workaround here until it gets properly addressed? 「 ダイノ ガイ 千？！ 」? · Talk⇒Dinoguy1000 20:49, 24 July 2009 (UTC)
 * This is already fixed in the master code. it's not really straightforward to backport on to the current code however, so I left it like this, hoping the new code will be deployed soon. —Th e DJ (talk • contribs) 00:10, 25 July 2009 (UTC)
 * Fair enough. Do you think you could at least provide a quick-and-dirty hack to hold me over until the fix goes live (feel free to stick it straight in boy, that didn't sound right... )? 「 ダイノ ガイ 千？！ 」? · Talk⇒Dinoguy1000 08:21, 27 July 2009 (UTC)
 * I suppose a quick fix is not that simple. It will be updated as soon as possible I guess.--Totie (talk) 08:37, 27 July 2009 (UTC)
 * Yes, that was indeed the reason it wasn't that simple. However, looking at this straight from the CURRENT source, I found a way around this problem with super specificity and over-importance. It's now deployed. :D —Th e DJ (talk • contribs) 09:52, 27 July 2009 (UTC)

Good Article
Hi, I think this should be added for good articles. Thanks Abraham (talk) 11:53, 16 April 2010 (UTC)


 * That template doesn't exist. If you want to propose that we put a GA icon next to the corresponding language links then bring it up at the Village pump.  — Dispenser 17:02, 16 April 2010 (UTC)

texhtml size increase
Coud the following be added to this stylesheet?

It's copied from the monobook style sheet and increases the size of formulae rendered with &lt;math&gt;&lt;/math&gt; and math to better match the size of formulae that are rendered by the LaTeX renderer as images. The discussion that added it there is here. See also here and here. The mismatch means pages created by editors using the monobook skin often look a lot worse under the vector skin - or at least that would partly explain the problem. I've added to my own vector.css and it improves such pages significantly. -- JohnBlackburne wordsdeeds 10:20, 24 April 2010 (UTC)


 * Uncontroversial change, so i went ahead and did it right away. This was always supposed to be used for all monobook like skins. —Th e DJ (talk • contribs) 12:44, 24 April 2010 (UTC)

Subscript rendering problem
I am too unsophisitcated to identify the problem. However, misalignment shows up with formulas like $$\mathbf{e_1}$$ or $$\boldsymbol {e_1}$$, but doesn't happen when no subscripts are present as in $$\ell$$ or $$\mathit {l} $$. However, $$\ell$$ appears slightly smaller than surrounding text, while $$\mathit l $$ appears much larger than regular text. This very large $$\mathit l $$ causes a large blank space between the line with $$\mathit l $$ and the previous line. Brews ohare (talk) 15:02, 26 April 2010 (UTC)
 * See discussion here, but I think it might be a side effect of


 * in Common.css combined with Firefox's rendering, though I could not find anything when searching.-- JohnBlackburne wordsdeeds 15:12, 26 April 2010 (UTC)

Hi John: Thanks for your help. I tried your suggestion to change Special:MyPage/monobook.css, but without effect. The rendering of $$l$$ (that is, $$l$$ )is identical with $$\mathit l$$ (that is, $$\mathit l$$ ) and is a tad larger than  I  (that is,  I  ) in Firefox. It is inconsistent with the sizing of $$\ell$$ (that is, $$\ell$$ ) and is startling. Brews ohare (talk) 15:39, 26 April 2010 (UTC)


 * Since everyone can have different settings for Math, please note if you are talking about math rendered as images vs math rendered as HTML. There is a big difference (Math rendered as images has a fixed size and cannot be influenced). —Th e DJ (talk • contribs) 16:25, 26 April 2010 (UTC)


 * Thanks for that observation: I'd say $$\ell$$ ( $$\ell$$ ), $$\mathbf l$$ ( $$\mathbf l$$ ), $$\mathfrak l $$ ( $$\mathfrak l$$ ), and $$\boldsymbol l$$ ( $$\boldsymbol l$$ ) are images, but $$\mathit l $$ ( $$\mathit l$$ ) and $$\mathrm l $$ ( $$\mathrm l$$ ) are not. The problem is that any of these that aren't an image are too large in in-line text.   In many font choices, this large size produces an ugly display with startlingly large letters. It also malforms subscripts as in $$e_l, e_{\mathrm l },  $$, which look very poor because the subscripts are too high. (On the other hand $$e_{\ell}$$ forces the entire symbol to be an image, not just the subscript.) Large size also causes wide line spacings.


 * Very peculiarly, including a single image version of ℓ in a list as in $$ e_{\ell}, e_l, e_{\mathrm l } $$ makes all&thinsp; the formatting appear as images, just because $$\ell$$ is in the list. Brews ohare (talk) 19:07, 26 April 2010 (UTC)
 * This is all expected behavior as far as I can tell. Elements in HTML mode are dependent on the font that your browser selects (not all glyphs are present in the default font). Math in image mode is consistent but has many other problems (line height issues with sub or super script elements for instance) and a fixed fontsize. This is an inevitable side effect of there not yet being a full fledged Math support defined for browsers as well as issues with lack of the required glyphs in the current fonts (especially on windows). —Th e DJ (talk • contribs) 19:10, 26 April 2010 (UTC)
 * Hmm, it might be that the specification for   does override the default behavior.... Not sure what the best approach is here. Personally i think we should render all math in images. they are just impossible to get correct. —Th e DJ (talk • contribs) 19:22, 26 April 2010 (UTC)

Wikitable, prettytable
In the old skin,  and   were aliases, but now... Why was the latter not implemented in this skin? That will have ‘broken’ a lot of articles... A. di M. (talk) 11:02, 15 May 2010 (UTC)
 * No, nothing to do with the new skin. We just removed prettytable from the English Wikipedia CSS. It had been deprecated for years and we have removed all uses that we could find. A few likely still exist, but they will just have to be converted. —Th e DJ (talk • contribs) 13:40, 15 May 2010 (UTC)

Interwiki stars are not shown
The css-code for the left panel has appearently been changed. The "panel" class has been renamed "mw-panel", which causes problem with the current code for the interwiki stars. The following two rows should be updated:

#panel div.portal div.body ul li.GA {

#panel div.portal div.body ul li.FA {

should be replaced with. --Kildor (talk) 20:56, 10 June 2010 (UTC)


 * Adding {editprotected}. Personally, I would shorten this to  or   to avoid possible future issues like this one. — AlexSm 21:44, 10 June 2010 (UTC)
 * I replaced both occurrences of of #panel with #mw-panel. Does that work? HJ Mitchell &#124; Penny for your thoughts?   22:08, 10 June 2010 (UTC)
 * Yes. Thank you! --Kildor (talk) 22:48, 10 June 2010 (UTC)

Remove "Title override"
The code for was added on Nov 2009. This is an ugly CSS hack that "works around" DISPLAYTITLE limitations and it's used on about 50 user and user_talk page. It definitely shouldn't be supported in the global CSS file. — AlexSm 15:03, 14 June 2010 (UTC)
 * I'm not so sure about that. It's the only thing that makes it work at least somewhat skin independant... Propose deletion nomination of the template instead. —Th e DJ (talk • contribs) 17:01, 14 June 2010 (UTC)


 * If I made some userbox and claimed that it needs some global CSS, would it be added to Vector.css as well? Seriously, this template does NOT need to work at all. P.S. By the way, the result looks really ugly in most (if not all) browsers. — AlexSm 00:37, 15 June 2010 (UTC)
 * Indeed, the result is very ugly. It also ruins a lot of scripts; most scripts that modify the page's title in some way, such as add extra information under it next to "Wikipedia, the free encyclopedia", is covered. Icons in the top-right corner, such as those that indicate if the user is an admin or has rollback rights, are also covered. In addition, Title override is not the only template to use this method. Over time I've come across a few, such as User:One/Title, that do the same thing. These are mostly in the User namespace because they are written to be customized for a small group of people, typically. Gary King  ( talk ) 05:14, 15 June 2010 (UTC)
 * Nominated for deletion. —Th e DJ (talk • contribs) 12:59, 16 June 2010 (UTC)

Someone want to do the same for this template: User:One/Title? I'd do it myself, but I don't usually deal with XfD-type stuff. Gary King ( talk  ·  scripts )  06:17, 16 July 2010 (UTC)

FlaggedRevs CSS
I have a few comments. Anyone else have other ideas ? —Th e DJ (talk • contribs) 00:26, 16 June 2010 (UTC)
 * There is no need to force display, unlike topicons, these elements are not hidden by default (yet). I wonder what these things look like in nostalgia however, so we might want to change that.
 * The padding overwrites the default value of 2px. I like the default better actually. Either way, 1 or 2, set it in one place and don't overwrite
 * For me 3em looks better, unless the intent is to "hook" the element to the bottomline, which i'm not in favor of, because it is almost impossible to get correct on all browsers.


 * Some context to "Pending changes" would be nice, since I hadn't realized that we were talking about the new code added here. Why was that spot chosen, why not put it by the toolbox on the left long with the "What links here" link.  — Dispenser 01:30, 16 June 2010 (UTC)

A doubt
May I know, What is the purpose of this block?--Praveen: talk 06:16, 8 July 2010 (UTC)
 * It removes the top margin from the "welcome to wikipedia" banner on the main page. Leaving only the margin bodyContent already has by itself. —Th e DJ (talk • contribs) 10:38, 8 July 2010 (UTC)

Thanks DJ--Praveen: talk 13:22, 8 July 2010 (UTC)

Deleted image for "Link GA"
See File talk:Monobook-bullet-ga.png. I couldn't look current image for Link GA in vector skin. But, I can look. Please, fix it.--Frozen-mikan (talk) 09:40, 9 August 2010 (UTC)
 * Thanks. :) (Other skins ok?) --Frozen-mikan (talk) 15:59, 9 August 2010 (UTC)
 * Fixed monobook as well. I don't believe the other skins have iw FA/GA indicators. —Th e DJ (talk • contribs) 12:04, 10 August 2010 (UTC)
 * Skins "Chick", "Simple" and "MySkin" are Monobook-ish and they'd have the icons if somebody added them from Monobook.css. — AlexSm 13:16, 10 August 2010 (UTC)

Changes to diffs appearance
I suggest adding the following code:

This will increase the fontsize of diffs, as the current (default) fontsize is miniscule. It also pushes the text to the top of a cell which makes comparison easier. This code has been in monobook since 2004. — Edokter • Talk  • 23:32, 18 October 2010 (UTC)


 * I take it there are no objections. I've gone ahead and put it in. — Edokter • Talk  • 21:29, 19 October 2010 (UTC)

Top edit link too large.
Ever noticed that the page title, being a h1.firstHeading, is not the same size as other h1 headers? It is slightly larger, namely 1.0em x 1.6em, as opposed to 188% x 0.8em (=1.5em). Not a big deal, but it does cause the top edit link to be too large (default size is 53% of h1 headers, and it only affects Vector). Setting it to 50% would fix this. Any objections to adding the following code? — Edokter</b> • Talk  • 15:34, 18 November 2010 (UTC)
 * Top edit link is a gadget, and not part of the normal Mediawiki, so any styling should be added to the gadget. —Th e DJ (talk • contribs) 17:32, 18 November 2010 (UTC)
 * I'll pose the question over there. — <b style="color:#008">Edokter</b> • Talk  • 17:53, 18 November 2010 (UTC)

Change "You have new messages bar" back to orange
editprotected

Please verify the following code will work properly, and implement:

See Village pump (technical). A change was made to the colour that was not discussed on en.wiki, and therefore has no local consensus. This restores the status quo. Code written by Kingpin13 here. –<b style="font-family:verdana; color:black">xeno</b> talk 20:47, 16 February 2011 (UTC)
 * Is this just on vector or all skins? Nakon  20:49, 16 February 2011 (UTC)
 * It is still orange for me in monobook, but I'm not sure about the others. See also: MediaWiki talk:Common.css –<b style="font-family:verdana; color:black">xeno</b> talk 20:50, 16 February 2011 (UTC)
 * This would only effect vector, the change was originally made because this colour scheme works well with vector, so it won't have been made to any other skins. I'll probably make this change soon if no one else does, it seems pretty clear that the en community prefer orange. xeno, why don't you just make it yourself? - Kingpin13 (talk) 20:52, 16 February 2011 (UTC)
 * Would rather someone more comfortable with css and editing the Mediawiki namespace do it. Not that I don't trust your code. –<b style="font-family:verdana; color:black">xeno</b> talk 20:59, 16 February 2011 (UTC)
 * Heh, well I know it works with Chrome. I think I'll go and test it in Firefox, Opera, IE6, IE7, IE8, and Safari, just to be on the safe side. Although they all support background-color and border, so there shouldn't be any problems. - Kingpin13 (talk) 21:02, 16 February 2011 (UTC)
 * Fine in all of those obviously, so no surprises there. - Kingpin13 (talk) 21:06, 16 February 2011 (UTC)
 * Done. —Th e DJ (talk • contribs) 21:04, 16 February 2011 (UTC)

Obsolete code?
Is the code marked with /* Increase fontsize of diffs. Remove when 1.19 is live. */ still necessary? We are using MW 1.20 already... Helder 13:53, 6 July 2012 (UTC)
 * ✅ —Th e DJ (talk • contribs) 09:19, 2 August 2012 (UTC)

Vector-specific styles for
The following styles are no longer necessary after MW 1.20wmf10 went live:

The same styles as the ones in MediaWiki:Monobook.css can be used (maybe you should consider moving it to common.css, even?):

This is thanks to this change: https://gerrit.wikimedia.org/r/#/c/18992/ (I just made a similar edit at pl.wiki:, this is a default gadget.) Matma Rex pl.wiki talk 20:37, 30 August 2012 (UTC)


 * ✅. — Edokter  ( talk ) — 22:18, 30 August 2012 (UTC)

font-size of #coordinates from 85 % to 92%
Can we change the  of   from 85% to 92%? This should, together with removing the  containing a   from Coord/display/title, make the font-size as large as in the tagline "From Wikipedia, the free encyclopedia". —Ruud 03:11, 16 February 2013 (UTC)
 * Sounds good to me. But this will impact other skins as well, so I need to check them all. — Edokter  ( talk ) — 17:31, 16 February 2013 (UTC)

Missing article titles in IE 6
Article titles are missing everywhere in IE 6. This is triggered by the rule The background is that IE 6 doesn't properly support selectors with multiple classes –  really means   in IE 6. The impact can be limited by swapping the classes: Monobook has the same problem. --Entlinkt (talk) 13:56, 27 May 2013 (UTC)
 * Wow... just wow. I'll swap the classes, so only the main page is affected. Dear oh dear... — Edokter  ( talk ) — 19:26, 27 May 2013 (UTC)
 * BTW. MSIE 6.0 is about to drop to under 1% of the requests (according to some interpretations, it already has). This means that more and more you will notice that things will start breaking. Bad issues will be fixed where possible, but everything that is still in a readable state, will not be considered broken. JS support for MSIE 6.0 has sort of dropped, it will probably only give you the most basic reading and editing experience. Do keep reporting whatever is truly 'unreachable' please. —Th e DJ (talk • contribs) 19:34, 27 May 2013 (UTC)

Protected edit request on 3 March 2014
Per Village pump (proposals)/Archive 109 and Template talk:Pp-meta, please change line 45 from  to.

Jackmcbarn (talk) 21:34, 3 March 2014 (UTC)
 * ✅. — Edokter  ( talk ) — 23:35, 3 March 2014 (UTC)

External links icons removed
Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at 63725. Regards, Nemo 09:45, 10 April 2014 (UTC)

Header template
Is the header on this page still relevant ("The Vector skin is part of Wikipedia's Usability Initiative and still actively under development.")? Following the link tells me that the Usability Initiative has finished. Thanks. – Wdchk (talk) 21:01, 20 April 2014 (UTC)
 * Not really. Removed. — Edokter  ( talk ) — 21:20, 20 April 2014 (UTC)

Protected edit request on 23 July 2014 (Fix typos in comments)
I noticed a few typos in the code comments that I thought perhaps should be fixed:
 * On the first line: "Typograhy" should, presumably, be "Typography"
 * In the "FR topicon position" section: "it's" should be "its"; "ensure" should be "ensures"

— Jaydiem (talk) 18:33, 23 July 2014 (UTC)
 * Red information icon with gradient background.svg Not done for now: It's not worth worrying about, because (as you say) it's all in comments. But next time we need to add or amend one of the rules, we can certainly go over text in comments. -- Red rose64 (talk) 19:04, 23 July 2014 (UTC)
 * Which will surely be forgotten, so I did it anyway...  20:07, 23 July 2014 (UTC)

Protected edit request on 4 September 2014
Hi. I have two requests.

This first is to switch from using  to   throughout the file.

This matches changes in core, https://git.wikimedia.org/commit/mediawiki%2Fcore.git/d6508e4aafd1e687824c8bfaeabf2f5758ca659a

The second is to add  to the list of selectors for.

Parsoid opted to use a span instead of sup for wrapping references because the superscript is presentational. Unfortunately, the following change created some visual difference between the php and parsoid output. https://en.wikipedia.org/w/index.php?title=MediaWiki%3AVector.css&diff=623705630&oldid=620385881

For example, https://parsoid-tests.wikimedia.org/visualdiff-item/pngs/enwiki/Phone_Call.diff.png

Thanks.

Arlolra (talk) 00:20, 4 September 2014 (UTC)
 * I have deactivated the editprotected because all changes need to be thoroughly discussed first. Feel free to reactivate when you have consensus. Regards &mdash; Martin (MSGJ · talk) 07:23, 4 September 2014 (UTC)


 * The section using div#content is targeting the Typography Refresh only. I don't know if that is affected as well (we'll know soon enough), in which case I will monitor and make the change. As to the references; the Parsoid team should really make up its mind on which parser (and associated style) is leading; sub/sup is still used and styled by the PHP parser in core, so that is what will be styled here.  08:44, 4 September 2014 (UTC)
 * I don't understand this response. The proposed changes are fixes for local hacks which became incompatible with MediaWiki (or Parsoid) due to ongoing development – perhaps they're not causing problems yet, but they might in the future. These definitely need fixing. Matma Rex talk 11:35, 4 September 2014 (UTC)
 * I'll have to look into the exact request later, but overall this sounds like the kind of change a sysop or global editinterface user will do without question or discussion as part of uncontroversial maintenance following MediaWiki software updates. It doesn't visually or functionally affect the wiki in any way. In fact, not making these changes will cause things to no longer work the same. It probably sounds like a bigger deal than it actually is if you're not knowledgeable about software development practices. Most updates don't require local customisations to be updated, but when they do (like this one), they're usually announced ahead of time so that one may update local code it in advance. Thus avoiding temporary disruption between the update rolling out and the local code being fixed. Krinkle (talk) 15:50, 4 September 2014 (UTC)
 * Hi Erwin, Just so there is no confusion, regarding references, we are not asking you to deactivate styling for PHP parser output (sup/sub), just asking that you add additional styling for span.reference so that Parsoid HTML is also styled identically. These reflect changes to core and will help ensure that Parsoid HTML renders identically to PHP parser output which is something that editors would appreciate as much as us. If not inconvenient, please hop onto IRC on #mediawiki-parsoid if you have any lingering concerns about this that requires a longer discussion. We can post a summary here later. Thanks. SSastry (WMF) (talk) 16:32, 4 September 2014 (UTC)
 * I can't find styling for span.reference (but I don't use VE). However, this should be moved to VE/Parsoid CSS once the Typography Fixes are merged (once I restore all repos under Windows).  00:10, 5 September 2014 (UTC)


 * Just one question: has scope for the content space (div#content) been changed globally? I don't have current code at hand, just asking because the Typography Refresh uses this scope, and the CSS here needs to match this.  23:43, 4 September 2014 (UTC)
 * If by 'scope' you mean selector, and by 'globally' you mean in the Vector skin, then yes, in this change: https://gerrit.wikimedia.org/r/#/c/153775/ Matma Rex talk 23:53, 4 September 2014 (UTC)
 * OK.  00:10, 5 September 2014 (UTC)

Padlock for secure links
MediaWiki has removed padlocks to the right of external https links (like the one in this very sentence). This does not show here because the padlocks were customized: /* Blue instead of yellow padlock for secure links. */ .link-https { background: url(//upload.wikimedia.org/wikipedia/en/0/00/Lock_icon_blue.gif) center right no-repeat; /* @noflip */ padding-right: 16px; } The above section, which intended to make icons less distracting, now has the opposite effect. It is no longer needed. --Chealer (talk) 03:23, 17 September 2014 (UTC)
 * 1) bodyContent a.external[href ^="https://"],
 * Red information icon with gradient background.svg Not done: please establish a consensus for this alteration before using the template. -- Red rose64 (talk) 11:32, 17 September 2014 (UTC)
 * +1 for removing this. Helder 12:39, 17 September 2014 (UTC)
 * Support removal as well.  16:36, 17 September 2014 (UTC)
 * Yes, it seems reasonable. –<b style="font-family:verdana; color:black">xeno</b> talk 16:58, 17 September 2014 (UTC)
 * +1 for removing this. Removing it was also supported by a number of folks in 54604 (with no objections). Quiddity (talk) 19:24, 17 September 2014 (UTC)


 * Pretty clear this can go. It was initially intended to replace the yellow padlocks anyway. Secure links are pretty standard, so no need to distinguish them. I'm removing it... from all skins.  20:45, 17 September 2014 (UTC)

fix phab link in comment (first line)
fix phab link in comment (first line). 66653 -> T66653. --Jeremyb (talk) 19:00, 18 December 2014 (UTC)

P.S. the todo list at the top of this talk page could use followup. bug was closed ~10 months ago.


 * All done. Thanks.  19:40, 18 December 2014 (UTC)