Jump to content

MediaWiki talk:Common.css/Archive 15

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10←Archive 13Archive 14Archive 15Archive 16Archive 17→Archive 19

Mobile website: hide-when-compact and Template:Multiple issues

{{edit requested}} I was surprised recently to see that the Wikipedia mobile site uses the full template text within {{Multiple issues}}. For example, compare the difference between http://wiki.riteme.site/wiki/Foster%27s_Home_for_Imaginary_Friends and http://en.m.wikipedia.org/wiki/Foster%27s_Home_for_Imaginary_Friends as an example. When I posted a question on Template talk:Multiple issues to find out what may be causing the issue, the response I received is that it has something to do with the <span class="hide-when-compact">...</span> in {{ambox/core}}, and that the class hide-when-compact is defined in MediaWiki:Common.css. I admit this is all over my head. Any suggestions would be gretaly appreciated. Thanks! GoingBatty (talk) 23:08, 18 October 2012 (UTC)

I think that the "compact-ambox" rules would need to be copied to MediaWiki:Mobile.css. Hopefully someone more familiar with the mobile site will happen by to confirm or correct that. Anomie⚔ 15:33, 19 October 2012 (UTC)
Done. It would be nice if we could create some nice styling for all the mbox templates that are suited for mobile devices btw. http://en.m.wikipedia.org/wiki/Talk:Foster%27s_Home_for_Imaginary_Friends and http://en.m.wikipedia.org/wiki/Foster%27s_Home_for_Imaginary_Friends definetly show we still need to spend some time on that. —TheDJ (talk • contribs) 08:49, 22 October 2012 (UTC)
Thanks - the Multiple issues template looks much better on the mobile site. And you're right, the fact that the {{WikiProjectBannerShell}} template on the mobile site displays much larger than it does on the regular site is also a concern. Thanks! GoingBatty (talk) 00:55, 23 October 2012 (UTC)

noprint

I think "noprint" can be removed from MediaWiki:Print.css, because it is defined on skins/common/commonPrint.css. Helder 13:48, 25 October 2012 (UTC)

done —TheDJ (talk • contribs) 14:51, 25 October 2012 (UTC)

The geography class in Mobile view

Please see Template talk:Infobox settlement#Another not-quite-right where there is a difference in behaviour between mobile and "normal". I'm pretty sure that most (if not all) is because the "geography" class is absent from MediaWiki:Mobile.css. --Redrose64 (talk) 09:55, 19 November 2012 (UTC)

Quite possibly. Things are only added to the mobile view on a case by case basis. Often with different styling then for normal view. —TheDJ (talk • contribs) 12:48, 19 November 2012 (UTC)
Checked, this is not specific to geography class. Mobile view just ignores almost all inline styling, and that is the issue here as well. The current strategy of the mobile team is "we just should not use so many inline styles, and if anything breaks by ignoring them, we should see what to do to fix that". In this case that means, we should add a proper class for centered thumbnails if you ask me, so that we can properly set alignment. —TheDJ (talk • contribs) 13:01, 19 November 2012 (UTC)

Help

help me if possible I have this problem so well

Common.css/Archive 15

{{{Infobox polygon}}} in english


from left to right I think the Template is incorrect click here to see [1] in somali --abshir (talk) 12:04, 3 December 2012 (UTC)

This page is for discussing changes to site-wide CSS on the English Wikipedia. If you think there is a bug in a template that you cannot figure out, you might try Wikipedia:Help desk, Wikipedia:Village pump (technical), or an equivalent forum that might exist on the Somali Wikipedia. However, as currently stated, your question is unclear. Which page are you seeing the problem on, and what does "from left to right" refer to? (Both English and Somali seem to be left-to-right languages.) PleaseStand (talk) 16:53, 3 December 2012 (UTC)

You have solved the problem, but there is another problem click here

http://so.wikipedia.org/wiki/Template:Hydrogen should move from left to right, the first was very good, also wanted to know what the problem is? if it is the Template. Thanks for the help. --abshir (talk) 23:20, 3 December 2012 (UTC)

Agree. There's been various problems all day with the formatting. Currently the main page is fixed, but the jinxed formatting is still showing up on the Watchlist - namely Personal tools, Namespaces, Actions and Search show up as nonclickable big words at the top of the page. They partially overlap the clickable words, such as "Talk", "Watchlist", "Contributions" etc. MathewTownsend (talk) 23:28, 3 December 2012 (UTC)

Sublists not wrapping

it appears the recent changes have made it so sublists using hlist no longer linewrap in Firefox 17 (see Template:Albania topics for example, but with a narrow screen). Frietjes (talk) 21:15, 5 December 2012 (UTC)

Should be fixed (or at least in 5 minutes). — Edokter (talk) — 21:22, 5 December 2012 (UTC)
Now it's broken in Webkit! — Edokter (talk) — 21:30, 5 December 2012 (UTC)
okay, it now wraps, but in a very odd way. as I narrow the browser window, I can get a single bullet to appear on one line, rather than before when they would always float with the items. Frietjes (talk) 21:35, 5 December 2012 (UTC)
now back to normal with the last change. Frietjes (talk) 21:41, 5 December 2012 (UTC)

there have been a couple editors who have expressed the desire to make the following work 

{{navbox with collapsible groups|navbar=plain
| title = title
| group1 = group1
| list1  = list1
| belowclass = navbox-title
| below = below
}}

in other words, make it so the navbox-title class can be applied to the below section. currently, this doesn't work, since the navbox-title class is restricted to table headings, and won't work with table rows. beyond this, it could be useful to apply the same color, consistency, to other elements, like div headings, etc. So, I was wondering a few things,

  1. Would it be a problem if the navbox-title class were extended to more than just th in tables?
  2. Would it be a good idea to have a more generic set of css color definitions that match the navbox definitions that could be applied in other places, for example, navbox-title and navbox-abovebelow are frequently used for coloring of headings in sidebars and infoboxes?
  3. Would it be possible to make these css definitions work for div elements as well (e.g., for use with {{hidden}} which uses NavFrame)?

I suppose I could see if I could get an additional field added to navbox, for a "below heading", but that doesn't facilitate uses within div elements. thank you. Frietjes (talk) 16:28, 16 December 2012 (UTC)

The navbox-title background color is not bound to th actually, so the above should work in theory, even on divs. However, navbox title refuses to override navbox-abovelelow class in the above example, even though specificallity is the same. To answer you questions:
  1. As explained above, .navbox-title background color is not bound to th. But changing specificallity will generate problems as the CSS ruleset is very complex.
  2. If other templates arleady utilize these classes succesfully, why add extra rules?
  3. As these rules are not bould to any specific element, they are generally free to be used on any element. But beware that more specific rules will override them. — Edokter (talk) — 17:54, 16 December 2012 (UTC)
okay, I misread the stylesheet, and you are correct that the following does work,
<table class="navbox">
<tr><th class="navbox-title">Title</th></tr>
<tr><td class="navbox-abovebelow">Above</td></tr>
<tr><td class="navbox-title">Below</td></tr></table>
Title
Above
Below
but the problem is that in my example, I am essentially doing this
<table class="navbox">
<tr><th class="navbox-title">Title</th></tr>
<tr><td class="navbox-abovebelow">Above</td></tr>
<tr><td class="navbox-abovebelow navbox-title">Below</td></tr></table>
Title
Above
Below
so you are saying that we cannot make this work without causing other problems? the entire reason for doing any of this is to avoid
<table class="navbox">
<tr><th class="navbox-title">Title</th></tr>
<tr><td class="navbox-abovebelow">Above</td></tr>
<tr><td class="navbox-abovebelow" style="background:#ccf">Below</td></tr></table>
since this looks very strange if you use a different css, which I do since I am visually impaired. Frietjes (talk) 18:15, 16 December 2012 (UTC)

Mobile Site rules are not generic

I ran an audit on a large mobile page and found that many of the rules that have been introduced to Mobile.css are not generic enough http://pastebin.com/afWkca2m

Please can these rules be removed or made to be more generic? — Preceding unsigned comment added by Jdlrobson (talk • contribs) 20:48, 26 October 2012 (UTC)

All rules are generic, but they are not used on all pages; it depends on how certain templates are being used on the page you are watching. — Edokter (talk) — 21:20, 26 October 2012 (UTC)
There is no way to fix this, until we have the possibility to define style specific to templates and/or pages. It's either this, or inline styling. —TheDJ (talk • contribs) 13:09, 19 November 2012 (UTC)
...aka bugzilla:15075. Helder 23:33, 19 December 2012 (UTC)

Patch not to print mw-navigation

I've submitted a patch to core not to print mw-navigation. This will hide "Navigation menu". Superm401 - Talk 21:39, 17 December 2012 (UTC)

Infobox/row styles

Hi all, I've started a discussion on moving the hardcoded styles in {{Infobox/row}} to Common.css, at Template talk:Infobox#Infobox/row styles and would appreciate comments. 「ディノ奴千？！」? · ☎ Dinoguy1000 20:40, 19 December 2012 (UTC)

improving unicode support - RfC for significant changes

Common.css editors (and other interested parties), please see recent discussion at Template talk:Unicode and then head over to User:ChristTrekker/UnicodeSymbol for work-in-progress. ⇔ ChristTrekker 17:47, 12 December 2012 (UTC)

I think this is virtually ready. Should we move ahead with implementation as part of template:unicode, or something else, or is there further comment? ⇔ ChristTrekker 23:44, 27 December 2012 (UTC)

Reduce gap between wrapped groupname lines?

Hello. I've noticed that navbox groupnames that have been made to wrap (e.g. |group1name = This groupname<br/>made to wrap appear by default to have a line-height out of proportion with the rest of the template (i.e. the lists). Here's a test example:


(Hopefully, the "Lorem ipsum" text has generated enough fake links to cause the lists to wrap where you are and give something to compare with group2's wrapped name.)

This, however, seems more in proportion here:


This was achieved by adding |groupstyle=padding:0.35em 1.0em;line-height:1.3em; (and the small group4 to check the padding). Anything wider than 1.3em seems too wide. Here's 1.25em for comparison:


Anything less than this is probably too close together. I'm suggesting, therefore, that the navbox groupname code is amended to include a styling of padding:0.35em 1.0em;line-height:[1.3em or 1.25em];, which I think would mean adding it to the "th.navbox-group" section of Common.css..? Hence my posting this suggestion / request here – apologies if this is incorrect.

Anyone agree / disagree / don't mind? CsDix (talk) 15:31, 20 December 2012 (UTC)

PS Here's the instance that reminded me to post the above: [2]

just be careful that you don't screw up existing methods for fixing this which use {{longlink}}. the line-height part probably won't conflict, but the padding might. Frietjes (talk) 17:27, 20 December 2012 (UTC)
If needs be, isn't it {{longlink}} that should change in response to modifying Common.css rather than Common.css accommodate {{longlink}}..? (After some experimentation, however, I'm pretty confident that padding:0.35em 1.0em; given a line-height of 1.25em or 1.3em closely approximates the present default padding.) CsDix (talk) 19:19, 21 December 2012 (UTC)
Still on my to-fix-list. The data cells have an inherited line-height of 1.5em and padding of 0.25em. The same should apply for the group cells. I will investigate any potential issues. — Edokter (talk) — 23:13, 20 December 2012 (UTC)
Thanks, Edokter. I'd suggest, though, that a line-height of 1.25em or 1.3em is more desirable. Compare the below, where the groupstyle line-height is 1.5em, with the 1.25em and 1.3em examples above:
The whole point is to match the groups with the lists in lineheight and padding. Using different values will give odd results; anything under 1.5em will look too crowded, especially when it contains sub- or superscript. — Edokter (talk) — 22:04, 21 December 2012 (UTC)
Are you sure? Here, with the Firefox-based browser I'm using (Palemoon), space is automatically created to accommodate super/subscripts regardless of line-height. For wrapped groupnames, a line-height of 1.5em is (still) too wide. CsDix (talk) 20:33, 22 December 2012 (UTC)
Of course space is automatically created; that creates the oddness. Also, anything else then 1.5em causes misalignment with the lists (as it actually does now). Simply changing the lineheight and padding without regard to the lists does create unwanted oddities, but I think I have come up with a solution, which I will implement shortly. — Edokter (talk) — 20:52, 22 December 2012 (UTC)
Okay – thanks for taking this on – but please bear in mind that (1) 1.5em is too wide for groupnames (compare examples above; it really does need to be something around 1.25em to 1.3em); and (2) if anything less would – in some instances – cause misalignments, then so be it, as those instances (using super/subscripts in groupnames) would surely be few and far between – and, even when they do occur, I imagine they'd be unlikely to involve more than a single linewrap, i.e. not drawing attention to any misalignment. CsDix (talk) 22:48, 22 December 2012 (UTC)
Sorry, but any line-height lower then 1.5em borders on illegible under default font-sizes. I see no point in having the groups have their lines closer together then the lists. With the fix now implemented, the lines should be vilibly closer together now, and align with the lists when they have an equal number of lines. — Edokter (talk) — 23:11, 22 December 2012 (UTC)
Curious – what you describe ("any line-height lower then 1.5em borders on illegible under default font-sizes") isn't the case here, as the examples above should show where you are. In fact, they're still as legible as anything else when the default font-size is reduced using Ctrl+mousewheel. Here are two screenshots (apologies for relatively low quality):


Reduced by one Ctrl+mousewheel turn


Reduced by a further Ctrl+mousewheel turn

The point in having groupname lines actually a little closer together (1.25em/1.3em rather than 1.5em) is because they're otherwise more likely to be perceived as being separate items, contrary to their being one item wrapped across more than one line. Or, to put it another way, groupname lines spaced by 1.5em are perceived to be more widely spaced apart than list lines spaced by 1.5em. (The usual bolding of groupnames also tends to add to this effect.) Or, to put it a third way, it's all a Gestalt thing. The "bottom line" (apologies) is that groupname lines spaced 1.5em apart look noticeably more widely spaced apart than list lines spaced 1.5em apart (and therefore a bit odd). CsDix (talk) 23:30, 23 December 2012 (UTC)

Hlists

I just saw this diff: http://wiki.riteme.site/w/index.php?title=MediaWiki%3AMobile.css&diff=526898381&oldid=526788120

Could you explain what the "major breakage" is? I believe that a ul.hlist is a common requirement of web pages and I believe a solution in the core of the mobile site would be much more useful and manageable then Common.css - I personally worry a lot about css bloat which Mobile:Common.css can greatly contribute to.

Is it documented anywhere how this is used? We currently have some experimental features in our beta around random functionality which require a ul.hlist with no margin or list-style and several of the changes in this wiki page are disrupting testing of this feature. I would be very keen to find a solution in the code that appeases everyone and removes the need for any mention of hlist here... — Preceding unsigned comment added by Jdlrobson (talk • contribs) 22:59, 18 December 2012 (UTC)

Sorry to respond so late. I don't know what, if any, features of hlist are incorporated in MobileFrontEnd core, but what I do know is that those changes made to Mobile.css did in fact break hlist formatting for me when I tested them in Chrome and Opera Mobile (emulator) with the experimantel mode enabled; at first, the change from display: inline; to display: inline-block; broke in virtually every browser. When .hlist ul was removed alltogether, I did not get any formatting at all (which from my viewpoint is a major breakage, unless I am doing something wrong), which sparked my remark that MobileFrontEnd might not be up-to-date here. As thing are now, all hlist CSS from Common.css is mirrored in Mobile.css (sans the IE stuff), and my hope is that hlist will end up in MediaWiki core CSS. But since hlist is still not even finalized here, it may be slightly premature to put it in MFE core. Whatever the case, these CSS changes should be tested on test.wiki, not here.
I'm more then happy to provide insight into hlist, but I need to know where the main discussion is taking place. — Edokter (talk) — 20:15, 28 December 2012 (UTC)

hcomma

Not sure if there'd be any demand for it here, but I've developed a comma analog to hlist on the Yu-Gi-Oh! Wikia, and maybe it's general-purpose enough to justify adding to the hlist styles here (where it could then benefit from maintenance and development alongside the "canon" hlist styles). The style can be added with a single rule here if the rule is added under the interpuncts rule in the "generate interpuncts" section; on the YGO Wikia, however, this style is kept separate so I don't have to work around it when updating the hlist styles, which means the styles for the sublist closing parenthesis has to be duplicated there.

The CSS we're currently using (minus the duplicated "reset" code): 

/* Comma-separated hlist */
.hlist.hcomma dd:after,
.hlist.hcomma li:after {
    content: ",";
}

「ディノ奴千？！」? · ☎ Dinoguy1000 01:38, 1 January 2013 (UTC)

I was thinking about expanding the available styles to hlist as well, without having to do much overhaul. Adding certain subclasses is the way to go. But I'd like to know if there is a demand for it before implementing it as well. — Edokter (talk) — 12:43, 1 January 2013 (UTC)
I'm not the one to ask, since I haven't been active here for quite a while, but I could point to a case or two of a comma-delimited list which is currently just that, but would be more semantic as an hcomma ul list.
Since I posted this, BTW, we've added three other classes, that add plus signs, minus signs, or slashes as the delimiter instead; expanding hlist with these is nothing short of delightful in ease and neatness (as one non-obvious example, originally in the reset rules I was specifying the .hcomma selector, because I wasn't sure if specificity would get in the way of a straight copy-paste of the reset rules, so if I kept that the same, I'd have to duplicate the selectors for each of hplus, hminus, and hslash... instead, I tried removing the .hcomma from the rules, and it Just Worked). =D 「ディノ奴千？！」? · ☎ Dinoguy1000 22:04, 1 January 2013 (UTC)
This seems excessive; we should seek to maintain a consistent UI where possible. Where commas have been used I have personally and simply converted their usage to the normal hlist usage. hcomma might have a use, but where it would have a use would be inline to markup lists within paragraphs, which most people don't normally do anyway, because that doesn't even cross their minds... --Izno (talk) 19:46, 20 January 2013 (UTC)

Reasoning for hwrap

Just querying into the reasoning for the addition of the hwrap CSS. Where is that purported to be used or is used? --Izno (talk) 20:07, 20 January 2013 (UTC)

hlist normally applies nowrap to list items, but this can be troublesome where long list items may not fit, such as in sidebars. hwrap allows long list items to be wrapped. — Edokter (talk) — 21:09, 20 January 2013 (UTC)

See Wikipedia:Village pump (technical)#Navboxes and touch devices; given the silence there, I will propose here that navbox show/hide links should be made bigger. (I gave a few reasons at the village pump post.)

Here's the basic code: 

.navbox-title .collapseButton, .navbox-title .expandButton {
font-size: 110%;
}

Including the square brackets in the clickable part of the link (as suggested at VPT) would require JavaScript changes, and might be unpopular (as it would presumably alter the appearance of all our show/hide links, and might not even be possible if we are dependent on a jQuery module). But this CSS change would be a great improvement to begin with.

Could someone please add this? — This, that, and the other (talk) 11:06, 8 January 2013 (UTC)

I have commented on your original proposal at VPT. Sorry for not responding sooner, but I think you raise an interesting issue about whether there is any point in hiding navboxes at all. It would be a shame to increase the "[expand]" text size when it is already quite ugly! — Richardguk (talk) 12:34, 8 January 2013 (UTC)
What you have said at VPT is true. However, I think it would be simpler to enact this CSS change as a first step to overcome the immediate usability problems with the existing setup. Making more substantial changes to the way navboxes work would really require broader consensus. — This, that, and the other (talk) 06:13, 9 January 2013 (UTC)
Thanks. I wouldn't want to delay more modest progress with my bigger proposal! But, in the meantime, it would be great if your specific proposal could be implemented in a prettier way by making the area surrounding the link text clickable, rather than making the ugly text bigger (and thereby uglier!). — Richardguk (talk) 06:27, 9 January 2013 (UTC)
That would be quite difficult to implement, although it would be really nice. Anything beyond a simple cosmetic change would require JavaScript changes, which I am keen to avoid for now. — This, that, and the other (talk) 09:02, 9 January 2013 (UTC)

Since there is no objection to this proposal (Richardguk raises some good points, but they are not directly related to my CSS proposal here), could an admin please add the required code? — This, that, and the other (talk) 23:48, 21 January 2013 (UTC)

Disabled edit request. After some tests, this code would throw off the centering of the title (which admittedly could be avoided by targeting the link instead). I have a better idea though. The entire title bar could do with a makeover. I was thinking about grouping all controls, including the v-t-e links, to the right, while left-aligning the title itself. At the same time, I want to give the controls a button-like appearance to give the actual links some breathing space. This involves changing navbox, navbar and the collapsibleTable code in Common.js, but nothing that potentially breaks anything. It would look something like this (HTML mockup):
Navbox title goes hereviewtalkedithide ▲
— Preceding unsigned comment added by Edokter (talk • contribs) 10:37, 29 January 2013‎
The effect of throwing off the centering is negligible (especially when all the navboxes have the change applied!) The benefits of making show/hide bigger would outweigh the minor (barely noticeable) aesthetic inconvenience of title misalignment.
As for your suggestion, I think that would be confusing for readers - it would not be clear what the "view/talk/edit" links do and many would click on them, only to end up in a mysterious land called template-space. — This, that, and the other (talk) 09:01, 30 January 2013 (UTC)
That is already the case with the v-t-e links. Also remember that every experienced template editor once found him/herself in this once mysterious land. — Edokter (talk) — 11:28, 30 January 2013 (UTC)

{{editprotected}} Hi. If possible, please add the following CSS rule as a temporary workaround for the positioning of the 'Help' link in Special:ArticleFeedbackv5. The current CSS causes it to be superimposed on top of RfC notice added to MediaWiki:Articlefeedbackv5-header-message on 21 January 2012. 

/**
 * Kludge. Fixes position of AFTv5 'help' link while [[WP:RFC/AF]] notice is on 
 * [[MediaWiki:Articlefeedbackv5-header-message]]. Please remove this rule once the
 * RFC concludes (somewhere around 2013-02-21).
 */
#articleFeedbackv5-header-links {
  position: relative;
  right: 0;
  top: 40px;
}

If this request is fulfilled, I intend to follow up once the notice is removed to request that this CSS rule be removed as well. Thanks! --Ori.livneh (talk) 18:15, 22 January 2013 (UTC)

Done. --Closedmouth (talk) 11:03, 30 January 2013 (UTC)

centering an hlist in Compact ToC

I'm not sure it's that important, but per this thread, the conversion of Compact ToC to hlist means that the contents can no longer be centered. the core issue can be seen here,

this was fixed for wikitable awhile back by adding an inherit for hlist for wikitables. Frietjes (talk) 00:28, 13 February 2013 (UTC)

Proposal to rename Catalogue of CSS classes

Please comment at Wikipedia talk:Catalogue of CSS classes#Suggested move. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:37, 8 March 2013 (UTC)

Double bold effect

when I view the three examples above in Firefox/Linux, they all look the same. however, in various browsers in Windows 7, they do not look the same. there is a "double bold effect" in either the second example, the third example, or both, depending on the browser. is there any way to resolve this issue here? for example, modifying the strong or bold tags when they are inside a navbox-title class? it looks even worse if there are font and background colors involved. Frietjes (talk) 18:45, 11 February 2013 (UTC)

note that this is not just a problem with navboxes, but I see the same thing with infoboxes, if there is a bold tag inside of a table heading. here the double bold effect is in the middle example. Frietjes (talk) 18:47, 11 February 2013 (UTC)

I've got Windows XP and five browsers (Firefox 18.0.2; IE7; Chrome 24; Opera 12.12; Safari 5.1.7). The examples above look the same in all five - no double-bold. Sounds like Windows version is the factor. --Redrose64 (talk) 20:38, 11 February 2013 (UTC)
They all look the same on Windows 7 with FF18, but with IE9 I see this effect on the second and third navbox and the second infobox. On those elements, the titles are wrapped in <b>...</b>. --— Gadget850 (Ed) talk 20:56, 11 February 2013 (UTC)
on my Windows 7 laptop with FF18.02, the second two navboxes are double bold, and the middle infobox is double bold. the same pattern, but even more pronounced, for IE9. the problem was originally reported to me by SMUconlaw who is using Windows 7 with FF 17.0.1. it does seem to be related to Windows 7. Frietjes (talk) 21:11, 11 February 2013 (UTC)
May be related to Wikipedia:Village pump (technical)/Archive 106#Template link font, which also concerned extra-bold from nested <b> and <strong> elements. Reported at VPT on 1 January 2013 by User:Simply south using Firefox and an unspecified operating system. — Richardguk (talk) 21:19, 11 February 2013 (UTC)
Something to do with DirectX vs GDI rendering. In Firefox, you can go to about:config and set gfx.font_rendering.directwrite.enabled to false and then restart Firefox to stop the extra bolding. -- WOSlinker (talk) 21:23, 11 February 2013 (UTC)

seems to be related to the arial font,

Arial Test 1 Test 2 Test 3

Times Test 3 Test 4 Test 5

Helvetica Test 6 Test 7 Test 8

in the cases above, I only see the issue with arial, and I also found this thread. Frietjes (talk) 21:25, 11 February 2013 (UTC)

Unstyled TH elementTH element enclosing text to which a B element has been applied
Unstyled TD elementTD element enclosing text to which a B element has been applied

See right. That's the table cells from the infobox examples from above, stripped of clutter and rearranged 2x2. For me, the bottom left is normal weight, and the other three are equally bold. --Redrose64 (talk) 21:42, 11 February 2013 (UTC)

Hi, I reported this issue to Frietjes a while back. I'm using Windows 7 and Firefox 19.0.2. For me, the text at bottom left is normal weight, the text at top left and bottom right are bold, and the text at the top right is double bold. As for Frietjes' example, Tests 1 and 2 (Arial) are double bold, as are Tests 6 and 7 (Helvetica). Hope that helps. — SMUconlaw (talk) 08:34, 12 March 2013 (UTC)

Edit protected

Please remove the following CSS, as the AFTv5 RFC has closed: 

/**
 * Kludge. Fixes position of AFTv5 'help' link while [[WP:RFC/AF]] notice is on 
 * [[MediaWiki:Articlefeedbackv5-header-message]]. Please remove this rule once the
 * RFC concludes (somewhere around 2013-02-21).
 */
#articleFeedbackv5-header-links {
  position: relative;
  right: 0;
  top: 40px;
}

--Izno (talk) 18:08, 12 March 2013 (UTC)

Done. — Edokter (talk) — 19:17, 12 March 2013 (UTC)
Thanks, Izno and Edokter! --MZMcBride (talk) 05:47, 16 March 2013 (UTC)

Remove div.mw-warning-with-logexcerpt

Hi. I propose removing div.mw-warning-with-logexcerpt from this stylesheet. This would have the effect of making sections wrapped in this code no longer have an ugly red background. The styling would automatically revert to using the default (built-in) MediaWiki styling, which seems completely sufficient here. Thoughts? Objections? --MZMcBride (talk) 05:50, 16 March 2013 (UTC)

Where can I see this in action? Warnings are generally styled with a red beckground. — Edokter (talk) — 10:19, 17 March 2013 (UTC)
Special:Contributions/RickK is an example in action. I view block notices as distinct from warnings. --MZMcBride (talk) 00:36, 19 March 2013 (UTC)
I see. Personally, I think the red background is appropriate there. — Edokter (talk) — 20:16, 19 March 2013 (UTC)
It feels pretty hostile to me. And a little scarlet letter-y. It looks like Meta-Wiki does this too, but I'm not sure a big red box is needed here. Maybe it could just have a red border and a white or transparent background? --MZMcBride (talk) 06:51, 20 March 2013 (UTC)
I think this is a quite old practice. It's basically the same style as our old deletion templates before they were turned into the red ambox'es in 2007. I have no issue with applying an alternative visual style for this, but this is also the first time it has been brought up in a very long time, so I doubt it is really important. I pasted a copy of the html below so we can discuss style suggestions. —TheDJ (talk • contribs) 09:57, 20 March 2013 (UTC)
Thank you for the examples below. :-) I think the alternative is significantly better. --MZMcBride (talk) 18:41, 20 March 2013 (UTC)
I disagree. Red denotes something 'important', and a blocked account is important enough not to risk being unnoticed. — Edokter (talk) — 19:15, 20 March 2013 (UTC)

Current

This account is currently blocked. The latest block log entry is provided below for reference:

View full log

Alternative

This account is currently blocked. The latest block log entry is provided below for reference:

View full log

New style for tables with alternating row colors

I would like to create a table with alternating row colors. This can be done easily with the following code, creating a 'alternating' CSS style: 

 table.alternating tr:nth-child(even) {
   background:#EFEFEF;
 }

I've tested this out with current browsers on User:Quantum7/Alternating with User:Quantum7/common.css, and haven't seen any problems.

This functionality cannot be duplicated using simple row-level style elements because the table must support sorting. Would this be a reasonable feature to add to common.css? Adding 56 bytes globally across wikipedia seems unnecessary, but I was unable to find a way to include article-specific stylesheets. Can anyone suggest an alternate implementation? --Quantum7 21:04, 25 March 2013 (UTC)

User:Writ Keeper pointed out in another discussion that this code would really belong in all the separate global skins, so that the colors look good. I fully agree with that. However, I would still like some community feedback on whether this is a good feature to add globally. --Quantum7 21:16, 25 March 2013 (UTC)
I'm personally not a fan of striped tables myself.
Aside from preference, that's CSS3, which means that only modern browsers will work with it (coughIEcough). --Izno (talk) 21:42, 25 March 2013 (UTC)

Previous discussion:

--— Gadget850 (Ed) talk 22:34, 25 March 2013 (UTC)

Thanks for the links, Gadget. So if this was suggested multiple times in 2010, why was it never implemented? The issue of being ignored by old browsers is even less of a problem now. Can we get this implemented? --Quantum7 20:12, 26 March 2013 (UTC)
Dunno. Wikimedia Analytics - User Agent Breakdown by Browser shows IE9 at 8.45% and IE10 at 0.70%, leaving IE8 and below at 8.75%. --— Gadget850 (Ed) talk 12:11, 27 March 2013 (UTC)
I think the biggest problem in both previous discussions, was actually picking the right color, not so much browser support (if you are depending on this to communicate information, you are doing it wrong :D ) —TheDJ (talk • contribs) 14:19, 27 March 2013 (UTC)
TheDJ is right from my recollection. I think that there was a suggestion that the most accessible colour to use would be white, which maximised the contrast with text or links for most skins.
What has never been demonstrated is the value of alternating colours beyond "I like them". Using a wikitable already provides a visual guide to the eye when scanning across a row by the use of cell borders, so the need for alternating colours is unproven. Nevertheless, as ever-wider displays become commoner, the use of alternating colours in full-width tables may make more sense. --RexxS (talk) 17:37, 27 March 2013 (UTC)
Jessica Enders did a rigorous study of zebra striping.[3] It surveyed asthetic preferences, as well as tested information retrieval for complex tables. Basically, the paper draws two conclusions:
  • There is a strong subjective preference for zebra stripped tables
  • Information retrieval (speed and accuracy) was either the same or better for zebra stripped tables compared to plain or lined tables.
I'm not saying we should change the default table style or anything, but for complex tables it would be nice to have a zebra striping option. --Quantum7 19:41, 27 March 2013 (UTC)
The survey is interesting, but I think calling it "a rigorous study" does a real disservice to the concept of rigour. Consider all of the comments and note the fact that her previous study "measured performance as users completed a series of tasks and found no statistically significant improvement in accuracy—and very little statistically significant improvement in speed when zebra stripes were implemented." If there is high quality research - and I'm not finding anything in Google scholar searches - then we need to make sure we are comparing tables that already have shaded headers and cell borders if we want to estimate any potential impact on wikitables. Having said that, there does appear to be a large component of individual preference, so I wouldn't object to having a "zebra" class available for tables, as long as it did not worsen the accessibility of wikitables for the visually impaired. For what it's worth, I wouldn't support the use of #EFEFEF as background-color for just that reason. --RexxS (talk) 22:22, 27 March 2013 (UTC)

Obsolete skin files

Shall I go ahead and delete all the obsolete skin files for Simple, Chick, Standard, Nostalgia and Myskin? — Edokter (talk) — 18:01, 23 April 2013 (UTC)

It appears that the old skins

now fallback on Vector. --Redrose64 (talk) 18:11, 23 April 2013 (UTC)

Vector is the default fallback for 'any' unknown skin name. Due to removal, these skins are now effectively unknown. If you had them enabled, then they are still set in your prefs btw. If we were to change the default to VectorOmega, you would get that skin since your 'set' skin is still unknown. Only if you actively switch you preference, you will set a new 'fixed' skin for you as a user.—TheDJ (talk • contribs) 18:17, 23 April 2013 (UTC)
(e/c) Why not, if something comes back, we can undelete without a problem. —TheDJ (talk • contribs) 18:17, 23 April 2013 (UTC)
Done. Now to clean up the CSS catalogue. — Edokter (talk) — 19:02, 23 April 2013 (UTC)

"Updated since last visit" markers

It has been over a year since watchlist notification was turned on, only to be hidden immediately after. Now that the CSS has long been changed to allow better control over how to show changed watchlist items, I proposed to change the bullets back then, which met no opposition, but I never got around to implement it. So if there are no objection, I can put CSS in place the will replace the standard bullets ( and ) with green bullets ( and ), and re-enable the reset button. — Edokter (talk) — 14:07, 4 May 2013 (UTC)

Restore default style for HTML cite element

We used to wrap entire citation lines in a element, in some old citation templates. Now we are using HTML5, and the standard prohibits this kind of use. The element should be styled as italic by default, and can continue to be restyled for particular purposes (like citing a chapter, which appears in quotation marks instead of italics).

The italic styling will not interfere with readability, but it will help editors find any remnants where the element has been (mis-)used in this way.

The selector cite should be removed from the style sheet: 

/* Default styling for titles of works, styling for the title of an article
   within a periodical, or a contribution within a compilation. */
cite,
.citation cite.article,
.citation cite.contribution {
    font-style: inherit;
}

 —Michael Z. 2013-02-27 22:15 z

Previous conversation was at Template talk:Citation#Semantic HTML. —Michael Z. 2013-02-27 22:17 z

As best I can see, this was added because cite was used to enclose an entire citation at one point, and italics was not desired. Here is some discusion. Under HTML5, <cite> is now only for titles. To me, restoring the default is proper. We aren't currently using <cite> in any of the citation templates, but I suspect we will add it down the road. --— Gadget850 (Ed) talk 12:44, 18 March 2013 (UTC)
Sure why not. We should probably fix those {{quote}} templates that use it, but then I don't see why we need this defined here any more, restoring the default seems proper. —TheDJ (talk • contribs) 20:59, 19 March 2013 (UTC)
I will take on that task. --— Gadget850 (Ed) talk 22:08, 19 March 2013 (UTC)
If there is no objection, then I will make that update when I have a block of time. I have a list of templates that will need to be updated. --— Gadget850 (Ed) talk 20:57, 27 March 2013 (UTC)
 Done --— Gadget850 (Ed) talk 00:46, 28 March 2013 (UTC)

"font-style: italic" for cite and cite.periodical

Given the above removal, is this CSS still needed, or can it be removed as well? 

/* Styling for the title of any work within a citation,
   or specifically the title of a periodical. */
.citation cite,
.citation cite.periodical {
    font-style: italic;
}

「ディノ奴千？！」? · ☎ Dinoguy1000 21:53, 24 May 2013 (UTC)

Should be OK. I can't think of any template where these classes are used. --  Gadget850 talk 00:28, 25 May 2013 (UTC)

cite: included work titles

We cleaned up <cite> so that it formats titles in italics. This is great for main titles, but not for included works such as chapters and articles. Seems to me that we can create a class to style this: 

.includedtitle:before {font-style: normal; content: '\22';}
.includedtitle {font-style: normal;}
.includedtitle:after {font-style: normal; content: '\22';}

Then you simply wrap the content in <cite class="includedtitle">...</cite> causing the font to show as normal and the content wrapped in quotes. Thus we have the semantics that <cite> adds to the title and the visual presentation of the included title. And yes, I know that the before and after pseudo-elements won't work in older browsers. This would also allow user to style the quotes however they like and allow porting to other sites that use different quote styles. --  Gadget850 talk 19:07, 7 June 2013 (UTC)

MediaWiki:Mobile.css documentation

There are a huge amount of various definitions for .hlists in MediaWIki:Mobile.css. The hlist class is used in the mobile skin ui and today we ran into various problems with the mobile's site design in a deployment (which adds talk pages to the beta mode of the site) due to existence of rules in MediaWiki:Mobile.css. I had no choice but to remove them temporarily as I couldn't work out how to make the css rules more specific and this seemed like a better option then reverting an entire deployment.

https://en.m.wikipedia.org/wiki/Special:MobileDiff/558513706...558513848

I'm hoping to be able to reinstate this in a different form with your help. Apologies for this inconvenience.

It would be useful if these rules were better documented and made more specific where possible to show where they are used so when these occasions do arise I can do something better than deleting them. For example in this case I suspect some of the rules are used by infoboxes so it would be good if they were only targeted to infoboxes.

I've also spent a lot of time removing unnecessary CSS rules on mobile which were copied and pasted from MediaWiki:Common.css but were actually unused. Would be great if someone could have a look through and see if anymore are unnecessary. It's essential we keep the CSS on mobile as lean as possible to minimise the download size.

Feel free to chat with me on #wikimedia-mobile in irc.freenode.org — Preceding unsigned comment added by Jon (WMF) (talk • contribs) 22:42, 5 June 2013 (UTC)

@Jon (WMF): We should talk; I build hlist. I cannot imagine what kind of trouble you are getting. hlist is invoked only when called upon. Several templates use it, mainly navbox. The parts you just killed now makes them (and everything else hlist) illegible, as the list items are no longer separated. hlist should only affect HTML lists. It cannot be more specific, because it has a fairly broad application, BUT it should not interfere with other elements. I really like to know what errors you are getting, because having no separators in horizontal lists is pretty bad. (There is a test page here for stand-alone hlists.) — Edokter (talk) — 19:22, 6 June 2013 (UTC)
This is a simple classname clash. Jorm used hlist as a way to make a list horizontal. Per chance, we are using the same classname, but next to making the list horizontal, we added functionality on top to add list separators. There are two options, either we change the classname, or mobile project changes their classname. —TheDJ (talk • contribs) 09:35, 7 June 2013 (UTC)
I call precedence then; the hlist class has been in use for over a year now here. Whatever he introduced should be reverted, because the existing uses for hlist are now severely broken in mobile. As a side note; why is Jorn trying to reinvent the wheel? — Edokter (talk) — 17:08, 7 June 2013 (UTC)
I suppose you mean Jon, not Jorm? If Jon, it might be worth e-mailing him, as he seems pretty inactive on this wiki (other than to modify mobile.css). I agree that it was pretty disingenuous of him to just delete a whole chunk of mobile.css without actually fixing the source of the problem. — This, that and the other (talk) 11:15, 9 June 2013 (UTC)
Hey... the reuse in CSS is incredibly important [1]. On mobile this is EXTREMELY important when you consider problems that effect mobile such as data charges and bandwidth. Every little helps. So I take your 2 options and provide a 3rd option - "Make mobile project and Mobile.css classes more compatible".

Firstly, I made a minor tweak to the CSS to limit these rules so that they work on the stable deployed version of Wikipedia but not the beta site (who's ui uses it) until I can work out better ways to dealing with this. We have another deployment window on Tuesday before which I hope to fix this clash. I hope this keeps us all happy for the time being since it means your navbox styles work and it means the beta site does not look completely broken preventing users from using talk and editing which I'd argue are very important :)

Now I think about optimisation for mobile a lot. Yes it would be easier for us to choose a new css class here but reuse it exactly what we should be doing here. The .hlist is actually quite the widely used class outside Wikipedia. I've seen it in CSS files on the last 6 or so projects I've worked on. When I've encountered it in another projects it usually means "a list that is horizontal" and nothing else, although unfortunately here it seems to mean a lot more which I wasn't aware of. However that said I believe we should be finding patterns and working towards consolidation of MediaWiki:Mobile.css and mobile core css itself. We already have a terrible habit of reinventing the wheel (for example the CSS of infobox and navbox have a lot of overlap!) - if you visit the Barack Obama of Wikipedia with javascript disabled and run Chrome dev tools it reveals the scary fact that "505 rules (63%) of CSS not used by the current page." This is extremely wasteful. On mobile alas this is also slowly becoming a problem "133 rules (51%) of CSS not used by the current page". This bloat increases page load.

Note I am extremely interested in ways we can limit styling to only the pages that need it. I have been exploring template specific css in my research time (e.g. Template:Navbox would have a corresponding css file Template:Navbox.css). I have asked for better documentation in the MediaWiki:Mobile.css so I can understand what the rules are used for. I would love if you could provide this so we can optimise even further where necessary. Please please please don't see my edits as an attack but a challenge to improve loading times for our many increasing numbers of users in the global south.

I will keep you posted and sorry about this clash but I hope you see the potential here for greater good and don't see this as an attack on your work - more a teething problem! [1] http://www.slideshare.net/stubbornella/css-bloat Jon (WMF) (talk) 23:52, 9 June 2013 (UTC)

I suggest you check WP:CSS, although take it with a grain of salt, since it is quite outdated in places. (For example, .sysop-show is now used in speedy deletion tags, and probably other places too). But it will answer some of the questions in your mobile.css comments. In addition, the Wikipedia search tool actually picks up CSS class names: for example, searching in all namespaces for "nounderlines" shows that this class is actually used in very few articles and is probably not needed in mobile.css. As for "what is IPA?", what better place to look than an encyclopedia? — This, that and the other (talk) 00:25, 10 June 2013 (UTC)

Thanks This, that. I wasn't aware of WP:CSS and that is interesting - https://wiki.riteme.site/wiki/Wikipedia:Catalogue_of_CSS_classes#Classes was exactly what I was looking for. I'm aware of using search to find css class names although it's not 100% reliable (class="IPA foo", class="foo IPA bar" class="IPA" are all ways that the IPA class could be used) and it does worry me that certain rules are so underused. Ideally I would like to see rules commented with links to their templates to help understand their usage. Although I was aware of what an IPA is - I was more interested in how it was used. Looking at that table it seems to be exist there for "Font-selection fixes for Windows, for IPA". Looking closer I also see that the rule in Mobile.css is only removing an underline and mobile removes underlines by default - so this rule is unnecessary (https://wiki.riteme.site/w/index.php?title=MediaWiki%3AMobile.css&diff=559249441&oldid=559137660) - this is exactly why I'm challenging rules! :-) Jon (WMF) (talk) 16:19, 10 June 2013 (UTC)

The IPA rule is there to remove underlines on hover (and also for those who switch on "always underline links" in their preferences), because descenders are crucial to the understanding of IPA text. Do mobile platforms have an equivalent to "hover"? If not the rule can probably go. For the record, .compact-ambox is used by {{ambox}} in its compact form (e.g. {{expand section}}). Also, .rellink is used by {{rellink}} to produce "see also" and "main article" lines, e.g. Andrei Tarkovsky#Awards, and .dablink is likewise used by {{hatnote}} (I found these out by simply searching the Template namespace for "rellink" and "dablink"). — This, that and the other (talk) 05:26, 11 June 2013 (UTC)
I lie: .compact-ambox is used by {{multiple issues}} in order to hide the box, etc. around individual issue tags in the "new syntax" - you should have a play with it and see. I think these CSS rules need a bit of work: compare the desktop and mobile displays of issue tags in Alain de Lille and Matanivanua, for instance. There are plenty more articles to play with in mostly old syntax and mostly new syntax. — This, that and the other (talk) 10:58, 11 June 2013 (UTC)

OK, I was pretty pissed and frustrated to see navboxes broken again, until I realized I have the mobile beta site enabled. But in future, please provide any reasoning, including links, testcases and settings involved when making edits. Information is severy lacking. Now I would like to see pages where these failures occur, so I can gain some insight. — Edokter (talk) — 17:56, 11 June 2013 (UTC)

I agree, Edokter, but at the same time, a lot of what we have put in mobile.css is itself "severely lacking" in information. — This, that and the other (talk) 00:53, 12 June 2013 (UTC)

I also agree, documentation everywhere would help better (hence the original request!). Please let me know what is unclear about mobile styling. In terms of the current issue, currently the damage is limited to http://imgur.com/EUwCdec on beta (notice the dots). Ideally we should be able to limit these rules to the content itself (#content on mobile #bodyContent on desktop) - this will avoid any overlap with the UI. The UI for mobile is still very much in a state of flux as we add new features such as editing and talk pages. Until we have some stability there are going to be a few clashes of this sort but a general agreement to limit the scope of rules in Mobile.css to #content (just the content of the article itself) should avoid any future problems of this kind. Is this acceptable to you? Jdlrobson (talk) 19:26, 12 June 2013 (UTC)

request to remove an ancient edit

Please look at this edit. basically, it assigns white background to images inside divs inside thumbs.

at the time, "monobook.css" really meant "wikipedia's CSS". however, when vector became the default skin, this specific rule was not transferred to either vector.css or common.css, with the bizarre result that monobook differs from the default skin not only in the interface, but also in the content. IMO, the content is supposed to be independent of the skin.

this caused some issues with recent changes to {{Chess diagram}} (which was switched to use Module:Chessboard, for vast improvement in performance, and modest enhancements of the capabilities). part of the move was changing the image files we use for the pieces themselves, to utilize "transparent background" images. this is a good thing to do on several levels, and it took another 3-4 weeks for someone to notice that this caused monobook users to see the pieces with white background (neither the "white" nor the "black" squares this template presents are really white).

we do use this technique of displaying one image on top of another in other places (e.g. the way "pushpins" are displayed in "location map" templates). this rule means that such uses can't be inside "thumbs", even though it will show perfectly for default/vector users, just because of monobook. i think this css rule should be removed: there is no justification to create this discrepancy between the different skins, and it's way too late to add it for non-monobook users (it's not even clear if this is a good rule). in short - please remove it.

peace קיפודנחש (aka kipod) (talk) 19:05, 12 June 2013 (UTC)

Actually, there is a similair rule in Common.css, div thumb img.thumbimage, which targets thumb images more specifically. So it seems that rule is redundant. I'll remove it. — Edokter (talk) — 19:25, 12 June 2013 (UTC)
Thanks. peace - קיפודנחש (aka kipod) (talk) 21:49, 12 June 2013 (UTC)

Fonts

There is a discussion and request (here) for better support for more fonts, which would involve a change to this page. If there are any comments about this, please can you do so over there? — Martin (MSGJ · talk) 20:10, 21 May 2013 (UTC)

We now have a HUGE fontstack added that benefit a very low number of users. This is ten times worse then the original Unicode fontstack that was removed over a year ago for that same reason. I propose we remove this, as the benefits are very vague. — Edokter (talk) — 16:39, 8 June 2013 (UTC)
Reiterating my intention to remove this... I want some cases to prove this code is indeed needed, else I intend to remove it. — Edokter (talk) — 21:37, 22 June 2013 (UTC)

Discussion about spacing between lists (refs/ELs) and navboxes

There seems to be a protracted, site-wide style war between editors who prefer more and those who prefer less vertical space above the first navbox. This mostly involved edit warring by manually adding and removing blank lines and similar devices. Luckily, it seems that a uniform technical solution exists for this issue. Unfortunately, participation in the discussion at WT:MOS has been rather low and took a turn for personalization recently. Perhaps people watching this page have an opinion on how much spacing looks good? If so, please contribute at WT:MOS, for the sake of keeping the discussion in one place. Thanks, Someone not using his real name (talk) 13:44, 27 June 2013 (UTC)

Per bugzilla:50077 it seems unwanted that VisualEditor shows the "placeholder" edit notices English Wikipedia inserts with a redlink to create the notice. If this is true, you can use the following to hide it.

Please add the following to MediaWiki:Common.css, below: 

.sysop-show, .accountcreator-show {
    display: none;
}

/**
 * Hide the redlink generated by {{Editnotice}},
 * this overrides the ".sysop-show { display: none; }" above that applies
 * to the same link as well.
 */
.ve-init-mw-viewPageTarget-toolbar-editNotices-notice .editnotice-redlink {
    display: none !important;
}

Krinkle (talk) 01:34, 3 July 2013 (UTC)

 Done, thanks. Legoktm (talk) 03:52, 3 July 2013 (UTC)

Visual Editor pick background

According to @This, that and the other: at bugzilla:50415#c4, the pink background would be added via CSS here. John Vandenberg (chat) 04:12, 5 July 2013 (UTC)

Hmm, sorry I didn't get to this. I was wrong in that bug comment, and it looks like we need to file a separate VisualEditor bug about this shortcoming. I'll do so shortly. — This, that and the other (talk) 04:17, 5 July 2013 (UTC)
bugzilla:50783. — This, that and the other (talk) 04:22, 5 July 2013 (UTC)
No worries, I just didnt want to forget it. Sysops editing through protection can result in desysops, and we and we can get banner-worn and disregard the protection template. The colour has helped me more than once. Thanks for raising the bug. John Vandenberg (chat) 12:45, 5 July 2013 (UTC)

Anoneditwarning in VisualEditor

We should bring the yellow background into common.css and disable it in VE. See MediaWiki_talk:Anoneditwarning#VisualEditor. ESanders (WMF) (talk) 10:32, 16 July 2013 (UTC)

Someone answer a question for me please

I noticed when reviewing several wiki templates that I'm seeing the following: id="mw-content-text" But I find no reference to that in the css file, can someone point me to where that is coming from? — Preceding unsigned comment added by 96.35.210.116 (talk) 18:49, 18 July 2013 (UTC)

Please give examples of the templates where this is a problem, also, does it show: (i) in the template's wikicode; (ii) on the template page; or (iii) in atricles which use that template? --Redrose64 (talk) 19:57, 18 July 2013 (UTC)

Implement ability to highlight certain rows in the info action

Hi. Please add the following code to MediaWiki:Common.css: 

/* Highlight data points in the info action if specified in the URL */
body.action-info :target {
    background: #DEF;
}

I tested this code on the test Wikipedia. This allows table rows to be highlighted based on the URL. Examples: [4] [5]. I believe this is an uncontroversial request. Let me know if you have any questions or need any additional information from me. --MZMcBride (talk) 20:34, 18 July 2013 (UTC)

 Done. Legoktm (talk) 23:29, 18 July 2013 (UTC)

{{Navbar}}/Module:Navbar is useless in the VisualEditor; it consumes space, and it renders links that only make sense if they can be clicked on.

Navbars should always be transcluded into mainspace via an intermediary template ({{infobox}}/{{navbox}}/etc), so the following should always do the trick 

.ns-0 .ve-ce-protectedNode * .navbar { display: none !important; }

John Vandenberg (chat) 11:39, 28 July 2013 (UTC)

I'm not in favor of this. Visual editor should render a page as much in the same way as a normal page view. Instead, I think in the long run, you'd want to put some sort of 'noninteraction' flag on it that when clicked explains to the user that it is 'non editable'. —TheDJ (talk • contribs) 12:59, 28 July 2013 (UTC)
Why? The Visual Editor layout on your screen has no relation to the normal page view on my mobile phone. The TOC is removed from the Visual Editor; the categories are removed; etc. sigh. ;-) John Vandenberg (chat) 13:14, 28 July 2013 (UTC)
Ah, so this is a mobile issue. Might have mentioned the code should go in Mobile.css then... (Note that its talk page redirects here; the talk page for Common.css.) — Edokter (talk) — 13:25, 28 July 2013 (UTC)
navbar is already disabled on mobile afaik. my point was that layout is device independent; each of our screens are different, so we can't expect visual editor and rendered page to be identical, and visual editor cant be used to define precise layout. Anyway, I do accept there is a consistency argument to be made, and I'm not overly concerned either way - this is why we have per-user css ;-) John Vandenberg (chat) 14:08, 28 July 2013 (UTC)

.pdf false positive

http://wiki.riteme.site/w/index.php?title=.pdf shouldn't really have an Adobe icon... is there any way we could avoid things like this? — PublicAmpers&(main account • talk • block) 16:24, 2 August 2013 (UTC)

Where is this used? Any link that includes a URL with a defined external link icon, such as http://wiki.riteme.site//index.php?title=.avi will add an icon. --  Gadget850 talk 21:14, 2 August 2013 (UTC)

Appearance of Wikidata edits in the watchlist

Edits to a Wikidata item currently appear in the watchlist as given below:

  • (diff | hist) . . Fire retardant (Q1354051); 02:13 . . Kanags (talk | contribs) (Language link added: ta:தீச்சுணக்கு)

Of the contained links, i.e. diff, hist, page name, item number, user name, user talk, user contribs and (if contained) interlanguage link, only one is within en.wikipedia. All the other go to Wikidata or in the example above to ta.wikipedia. Therefore, I suggest the following two changes:

  • Coloring all non-internal links (everything except the link to the Wikipedia page) as external links, i.e. in a brighter blue (like ta:தீச்சுணக்கு as opposed to Fire retardant)
  • Adding a d in analogy to b for bot edits or m for minor edits

Thoughts? --Leyo 13:11, 13 June 2013 (UTC)

Submit it in bugzilla. Seems like a useful feature. —TheDJ (talk • contribs) 13:33, 26 June 2013 (UTC)
Unfortunately, I do not have any experience in bugzilla. I would highly appreciate if someone could do that for me. --Leyo 14:08, 26 June 2013 (UTC)
→ bugzilla:50893 --Leyo 16:22, 18 July 2013 (UTC)
Unfortunately, there does not seem to be any response or activity. --Leyo 21:25, 26 August 2013 (UTC)

Mobile: 'Title' coordinates not showing

Please see WP:VPT#Mobile: 'Title' coordinates not showing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:20, 27 August 2013 (UTC)

IPA font

Hallo,

If I understand correctly, currently special fonts are added for IPA only in Windows XP using MediaWiki:Common.js.

Windows XP is not the only system that lacks good fonts for IPA - many systems do. Now that the English Wikipedia has web fonts that are able to show IPA, they should be used consistently and the Windows XP hack should be removed.

You can see a showcase of some fonts at User:Amire80/IPA. My suggestion is Gentium, possibly with enlarged size. --Amir E. Aharoni (talk) 12:03, 25 August 2013 (UTC)

The webfonts won't be updated until thursday. Even then, I'm not quite sure how to use them. I will need to look that up. — Edokter (talk) — 21:19, 26 August 2013 (UTC)
Gentium is already here.
There are several ways to use them. Some languages have a webfont defined by the lang attribute, for example Saurashtra: ꢱꣃꢬꢵꢰ꣄ꢜ꣄ꢬꢵ.
They can also be used by simply using font-family with the right name. IPA templates already apply the IPA class wherever needed, so all that is needed is .IPA { font-family: Gentium; }. --Amir E. Aharoni (talk) 21:32, 26 August 2013 (UTC)
I need to know what triggers the font to load. Simply calling the font may not work if the font is not triggered by a lang attribute. Also, is the Gentium font the full font or a trimmed down webfont, which may not contain all the IPA characters? — Edokter (talk) — 23:47, 26 August 2013 (UTC)
Found the doc. I'm afraid only fonts specified inline using spans will be atomatically loaded; the extension will not pick up fonts specified in Common.css. What would work better is configuring USL by adding "IPA" as a language. — Edokter (talk) — 00:02, 27 August 2013 (UTC)
It will work. The extensions searches for all elements with class=, and applies the webfont if there is a relevant font-family. class="IPA" is already applied by templates, so it will work. I already did it in the Hebrew Wikipedia, see w:he:חלאנביירפוחלגווינגיחל for an example. --Amir E. Aharoni (talk) 05:45, 27 August 2013 (UTC)
... And yes, it's the full Gentium. --Amir E. Aharoni (talk) 06:46, 27 August 2013 (UTC)
Personally I find Gentium butt ugly and I much prefer my Mac's native fonts. —TheDJ (talk • contribs) 08:37, 27 August 2013 (UTC)
Most people don't have a Mac, or any other operating system that has built in fonts that support IPA well. You can disable it in your private CSS. If you have another good font that is Free and supports IPA well, we can add it. If not, do you see any technical reason not to use Gentium as the default for IPA? --Amir E. Aharoni (talk) 12:24, 27 August 2013 (UTC)
It is a very large font, and most IPA strings I come across work very well on XP with the current default. Are there any non-XP cases where it fails? — Edokter (talk) — 12:43, 27 August 2013 (UTC)

Could you do the same for Unicode Mathematical Operators (class="texhtml"), namely MathJax fonts? Concrete examples of use can be found here. Incnis Mrsi (talk) 18:59, 28 August 2013 (UTC)

Webfonts are for cases where normal fonts do not work. That is not the case for texhtml. — Edokter (talk) — 08:29, 29 August 2013 (UTC)
I have an outstanding patch for our Math extension that would allow MathJax users to choose which font they want to use btw. —TheDJ (talk • contribs) 09:00, 29 August 2013 (UTC)

MediaWiki:Group-autoconfirmed.css

Does anyone oppose the creation of MediaWiki:Group-autoconfirmed.css with the following content? 

/* CSS placed here will affect autoconfirmed users only */ 
span.wp_autoconfirmedonly { display: inline !important; }
div.wp_autoconfirmedonly { display: block !important; }

--Leyo 13:11, 11 September 2013 (UTC)

What does it do? — Edokter (talk) — 18:35, 25 September 2013 (UTC)
It allows that e.g. an error message is shown to autoconfirmed users, but not to readers:
<span class="wp_autoconfirmedonly" style="display:none;">Sample error message, e.g. concerning a parameter error in a template.</span>
--Leyo 22:05, 25 September 2013 (UTC)
Apart from practical issues (mobile?), why would we want to hide errors from readers? Fixing errors is how I started editing. — Edokter (talk) — 22:25, 25 September 2013 (UTC)
I am referring to technical errors that only skilled users can fix.
My question was concerning the actual code. --Leyo 10:06, 26 September 2013 (UTC)
This could have potential uses in only displaying a message when it is relevant to the user. In this case, it could be about moving a page, which only auto-confirmed editors can do. I support such a feature. — Martin (MSGJ · talk) 19:40, 26 September 2013 (UTC)
Any request of changes to the code above? The naming should be consistent with the local standards. --Leyo 09:31, 28 September 2013 (UTC)
Change the underscores to hyphens. Also make sure that it works on mobile; I understand that mobile strips all inline CSS, which means "display:none;" may not work (but I'm not sure). — Edokter (talk) — 09:55, 28 September 2013 (UTC)
I believe you're right about mobile. The solution is, of course, to put .wp-autoconfirmedonly { display: none } in MediaWiki:Common.css. That also lets us get rid of the !important, which is another good change to make. Anomie⚔ 13:26, 28 September 2013 (UTC)
I see we already have a similair construct for sysops and accountcreators, so the code should be:
/* Show hidden items that have class="autoconfirmed-show". */
div.autoconfirmed-show, p.autoconfirmed-show {
  display: block !important;
}
span.autoconfirmed-show, small.autoconfirmed-show {
  display: inline !important;
}
table.autoconfirmed-show {
  display: table !important;
}
li.autoconfirmed-show {
  display: list-item !important;
}
...and have .autoconfirmed-show added to the list of hidden group classes in Common.css. — Edokter (talk) — 14:35, 28 September 2013 (UTC)
Looks fine to me. --Leyo 23:35, 28 September 2013 (UTC)
 Done. — Edokter (talk) — 10:46, 29 September 2013 (UTC)

CSS regarding background of thumbimages

Hi all,

could the section currently reading 

/* Makes the background of a framed image white instead of gray.
   Only visible with transparent images. */
div.thumb img.thumbimage {
    background-color: #fff;
}

be changed to 

/* Makes the background of a framed image white instead of gray.
   Only visible with transparent images. */
div.thumb .thumbimage {
    background-color: #fff;
}

The current selector produces a problem regarding {{Multiple image}} which includes the correct class definition but on a table cell – therefore the white background is not applied to thumbs created using the template. As I see no simple way to change this in the template I think it's best to change this in common.css. --Patrick87 (talk) 14:49, 3 October 2013 (UTC)

After a quick scan for specificity collisions, there seems to be no conflict.  Done. — Edokter (talk) — 20:12, 3 October 2013 (UTC)

Proposed change to self-linking buttons

In order to avoid the problem outlined at Wikipedia:Village_pump_(technical)#Wikipedia:Questions, I suggest the following CSS code be added to the end of this file, in order to visually distinguish navigation buttons that are actually self-links: 

/* Show self-linking buttons, e.g. on [[Wikipedia:Questions]], in a different color */
.selflink .ui-button { cursor: default; }
.selflink .mw-ui-{{subst:#switch:{{subst:lc:blue}}|green=constructive|blue=progressive|red=destructive}} .ui-button-text { background: #008; }
.selflink .mw-ui-{{subst:#switch:{{subst:lc:green}}|green=constructive|blue=progressive|red=destructive}} .ui-button-text { background: #060; }
.selflink .mw-ui-{{subst:#switch:{{subst:lc:red}}|green=constructive|blue=progressive|red=destructive}} .ui-button-text { background: #802; }

Thanks, — This, that and the other (talk) 07:09, 1 October 2013 (UTC)

Are there any comments or concerns about adding the proposed code? — Martin (MSGJ · talk) 09:53, 3 October 2013 (UTC)
I think the use case is too minor to warrant inclusion. — Edokter (talk) — 19:49, 3 October 2013 (UTC)
I've disabled this request for now, pending further discussion. I must admit my ititial thought was along the lines of Edokter's. Is there another way to achieve the same objective? — Martin (MSGJ · talk) 07:57, 4 October 2013 (UTC)
One could assign the ui-state-disabled class to the button, but that involves some template coding. — Edokter (talk) — 21:43, 4 October 2013 (UTC)
Yes, that is probably a better solution. — This, that and the other (talk) 04:35, 5 October 2013 (UTC)

Horizontal lists: make ordinals appear by default when using ordered lists

Posted to WP:VPR with absolutely nor response, so posting here.

Since its inception, horizontal lists have become very popular. But during its creation, some insisted that the ordinals (numbers) do not appear when using a horizontal ordered list. This has never sat right with me. I propose that horizontal ordered lists show their ordinals by default, by means of deprecating the hnum class. Here is why:

  • Just as with using regular HTML lists, people expect ordinals to be shown when using ordered lists. The same principle should apply to horizontal lists: If one does not want to show ordinals, one should not use an ordered list to begin with.
  • Hiding the ordinals by default creates an accessibility issue... not for those with screenreaders, but ironically for the seeing. Where screen readers still read out the ordinals, they are hidden from view on the display. Why this is not seen as a valid accessibility issue is beyond me. — Edokter (talk) — 18:36, 25 September 2013 (UTC)

No response for several days; I have removed the hnum class. — Edokter (talk) — 15:12, 28 September 2013 (UTC)

An ordered list does not necessarily imply numerical order. It can be used to indicate a list of years, for which the presence of numbers is non-obvious.
Please readd the CSS, or add a way to hide the numbers without adding inline CSS. --Izno (talk) 16:01, 28 September 2013 (UTC)
Why is it always after the fact that people start complaining? Ayway, my motivation is simple: horizontal lists, ordered and unordered, should behave exactly like regular HTML lists. You wouldn't use a regular ordered list for years, so why do so in a horizontal list? The years themselves indicate the order, so there is no need to add underlying (and hidden!) semantics. Adding hidden semantics in this case is a huge accessability no-no. That is why I removed them. — Edokter (talk) — 19:04, 28 September 2013 (UTC)
"add a way to hide the numbers without adding inline CSS" seems to be a reasonable compromise. Frietjes (talk) 16:54, 29 September 2013 (UTC)
That proves rather more complex then you'd think. I would have to add more CSS to show less HTML. — Edokter (talk) — 18:28, 29 September 2013 (UTC)
I'm skeptical that it's that much more complex. The amount of CSS is also rather irrelevant, given caching and ResourceLoader (and all the other things that are done. --Izno (talk) 20:31, 29 September 2013 (UTC)

I'm hardly complaining, Edokter. :^) In this case, I simply haven't been keeping daily (or even weekly) track of en.wp activities and happened to see the changes made on my watchlist.

"You wouldn't use a regular ordered list for years" -> Citation needed. I at least have done precisely that. Another use case: Marking up a list of media, arranged in whatever way (by always some order, of course). I don't necessarily want the numbers to show, and I think an alphabetical order you definitely wouldn't want numbers to show.

"The years themselves indicate the order," That's like saying "double spacing words in the source of an HTML document implies that we're using paragraphs—why do we have an <p> element?"...

I'm puzzled why you would say that this is an accessibility no-no. Whether the semantics are obvious to a human user seems largely irrelevant—the use of semantic tags isn't for sighted-readers (or else we'd still be using <i> where we should be using <em>, etc). --Izno (talk) 17:09, 29 September 2013 (UTC)

the use of semantic tags isn't for sighted-readers... Semantic tags are for everyone. I would like to see where you used ordered lists with years, and particularely, how you used them. Did you hide the ordinals? If so, how? I think the burden is on you to prove the necessity for non-default list behaviour to be default. — Edokter (talk) — 18:28, 29 September 2013 (UTC)

Plainly they aren't, else we wouldn't be indenting using <dd>, nor would it have been the case that HTML 4 (and earlier) was the mess that it was.

I used them as one might expect (and indeed I hid the ordinals as was the default), but that's beside the point, because it treats me like the crazy one. The use case is valid, regardless whether you think so or not and whether or not there's one person out there or five hundred using it like such. What needs judgement is whether the fact that any number of people are using it is enough to justify the "keeping" of that CSS. It seems to me that you should probably have run a scan on how many times hlist hnum was used to see its use, as opposed to just hlist, in as many templates with numerical lists as possible.

On an aside, last I checked, the BRD cycle works like "bold", "revert", then "discuss". The only reason we're discussing now rather than after a revert is because I can't edit the CSS file (and perhaps because the CSS file should have consensus before changes). :^)

As I said, I'm also open to having the default displayed, non-default not-displayed. --Izno (talk) 20:31, 29 September 2013 (UTC)

I wouldn't know how to scan for the use of ordered lists without hnum. And scanning for 'hlist hnum' doesn't tell me anything. I would like to see a valid use of ordered lists with hidden ordinals, in regular HTML lists. You still haven't pointed me to one. My viewpoint remains that hlist should behave like a regular list. Show me a case using a regular list with hidden ordinals, and I will add an option to do the same for hlist. — Edokter (talk) — 21:22, 29 September 2013 (UTC)
just fixed one here, there are likely many more. Frietjes (talk) 23:04, 10 October 2013 (UTC)

Print.css .skin-simple

Just wondering if the .skin-simple items in Print.css are still needed? -- WOSlinker (talk) 20:00, 29 September 2013 (UTC)

Nope, removed. — Edokter (talk) — 08:51, 12 October 2013 (UTC)

VisualEditor customisations to interface messages

MediaWiki:Anoneditwarning and MediaWiki:Newarticletext need to be customised if VE is active. The workaround on bugzilla:53746 is to make use of the CSS selector (.ve-available or .ve-not-available - see [6]) which is added to the body element. To do this, I think we need two common CSS rules like: 

body.ve-available * .ve-not-available { display: none }
body.ve-not-available * .ve-available { display: none }

Then the interface messages can use "<span class=".ve-available">yay</span><span class=".ve-not-available">boo</span>" and the appropriate one will appear depending on the editor. John Vandenberg (chat) 09:26, 18 October 2013 (UTC)

FYI, if you go this way, a few recommendations:
  1. The class is on <html>, not <body> (so "body.ve-available" and "body.ve-not-available" don't work). Anyhow, don't use either tagname in the selector as this is an implementation detail. The class name is something we intend to support and will work on its own. The tagname is redundant and will only get out of sync.
  2. The * part seems redundant and only slows down the selector engine by making an arbitrary requirement on matching elements against a wildcard that have to be at least 2 levels deep.
  3. Avoid naming this classname the same as the one from VisualEditor. They have a different meaning and would likely interfere with VisualEditor's stylesheet. Name it something else (e.g. ve-available-only and ve-not-available-only)
  4. Merge the rules, no need for two :-)
For example:
.ve-available .ve-not-available-only,
.ve-not-available .ve-available-only {
    display: none;
}
--Krinkle (talk) 16:52, 18 October 2013 (UTC)
Thanks Krinkle; that all sounds good. Any other suggestions before we go ahead? Is there another way we could go about this? John Vandenberg (chat) 21:23, 18 October 2013 (UTC)

Template editors

Could someone here (Edokter?) take a look at the edit request at Wikipedia talk:Editnotice#Edit request on 19 October 2013: Template editors? There is a proposal there to add css MediaWiki:Common.css to allow template editors to view links to edit notices and group notices. — Mr. Stradivarius ♪ talk ♪ 03:49, 19 October 2013 (UTC)

I took care of it :) Legoktm (talk) 04:09, 19 October 2013 (UTC)

Edit request — Nastaliq by default

Hello, everyone... I actually wanted to abolish the use of {{Nastaliq}} for rendering Urdu text in Nastaliq. Please incorporate a couple of lines of code to MediaWiki:Common.css so that Urdu text is rendered by default in Nastaliq font just by using {{lang-ur|...}} or {{lang|ur|...}}: 

:lang(ur)
{
    font-size: 150%;
    font-family: "Jameel Noori Nastaleeq", "Urdu Typesetting", "IranNastaliq", "Nafees Nastaleeq", "Nafees Nastaleeq v1.01", "Nafees", "Pak Nastaleeq", "PDMS_Jauhar", "Alvi Lahori Nastaleeq", "Fajer Noori Nastalique", sans-serif;
}

I hope people do not have any objection to this.—ШαмıQ✍ @ 08:20, 3 November 2013 (UTC)

 Not done. MedaiWiki now has built-in support for non-latin scripts in the form of the Universal Language Selector, which uses webfonts where necessary (see the old webfont documentation on how to use it). If your script is not (yet) supported, ask for support here. — Edokter (talk) — 11:11, 3 November 2013 (UTC)
And why would this make a welcome addition to the ULS? Who's to say anybody other than en.wiki want Nastaliq for Urdu? ar.wiki have done everything in their power to banish Amiri. — Lfdder (talk) 12:07, 3 November 2013 (UTC)
What makes you assume that it is non welcome, or that it cannot be possible to support two things at the same time ? I suggest to bring you concerns to the language team, they are usually very welcoming to any kind of feedback and open to making changes if you can truly convince them of the necessity of a change. —TheDJ (talk • contribs) 11:37, 4 November 2013 (UTC)
I think you misunderstood me. This isn't something I think should be added to the ULS; it's a stylistic change. — Lfdder (talk) 12:42, 4 November 2013 (UTC)
Quite so. This is the change produced:—ШαмıQ✍ @ 20:14, 4 November 2013 (UTC)
Nastaliq (sans-serif: the style preferred for Persian and Urdu)
Naskh (serif: the style preferred for Arabic)
Both read the same. But the Nastaliq one is the de facto style used for Urdu and is always preferred over Naskh (the default for Urdu now)

Re-requesting per comments above. — Lfdder (talk) 00:32, 6 November 2013 (UTC)

Disabled again. Stylistic or not, non-Latin fonts are now the domain of ULS. Further, this use case is too minor to warrant inclusion in Common.css. The current template should be adequate in handling those few scenarios that require it. — Edokter (talk) — 19:52, 6 November 2013 (UTC)
You just don't get it, do you? — Lfdder (talk) 20:48, 6 November 2013 (UTC)
I get it... you want a specific font for a specific script. Common.css is not the place. ULS is the the new tool for all language-, script- and font related issues. — Edokter (talk) — 21:04, 6 November 2013 (UTC)
I, personally, couldn't care less what font is used for Urdu. I can't read Urdu. But I know that this doesn't be long in either a template, or the ULS. — Lfdder (talk) 21:27, 6 November 2013 (UTC)
It certainly does not belong here with such a limited use case. Script-specific fonts do belong in ULS. — Edokter (talk) — 22:07, 6 November 2013 (UTC)
The only 'script-specific' fonts that belong in the ULS are those of scripts that modern systems don't support out of the box. — Lfdder (talk) 22:22, 6 November 2013 (UTC)
I just want to double check why you would need something like this to begin with... Is it to force a more consistent and predictable font selection by the browser ? So that it doesn't use Arial/Helvetica for instance ? As far as I know, ULS doesn't really support that yet, it only knows "system" which is an unspecified order. —TheDJ (talk • contribs) 10:08, 7 November 2013 (UTC)
Not quite. If we want to use Nastaliq for Urdu, then it should be a global setting. We shouldn't need to plug in an extra template every time. I've already explained why this doesn't belong in the ULS. — Lfdder (talk) 11:06, 7 November 2013 (UTC)
@TheDJ: The sans-serif style is what differentiates Urdu from Arabic... So much that even in the UAE, a predominantly Arab country where everything in Arabic is in Serif, (and Urdu is nowhere) I found a few trilingual (Arabic, English, Urdu) signboards which had an Urdu inscription (which is a rare case, and that too) in Nastaliq. Let alone in Pakistan, where everything in Urdu is in Nastaliq. Even newspapers in Pakistan were handwritten until a few years ago, when they did not have proper Nastaliq fonts, even though they could have easily typed them using serif (Naskh). But instead they chose to get them handwritten in Nastaliq. So I think where Urdu has to be, we need it to be rendered in Nastaliq. The ULS may contain support for scripts who have their specific fonts to render them. (E.g. you may need Devanagari fonts to render Hindi properly, you may need Chinese/Japanese fonts to render the Han characters properly—there is no option. You can't read it otherwise) But for Urdu it is a specific style (sans-serif) needed to render it on-wiki, as it is on paper. And agreed with Lfdder... I actually add a lot of Urdu transcriptions here, and I need to add the {{Nastaliq}} template every time for something that should be done by default. Hope it's clear.—ШαмıQ✍ @ 11:44, 7 November 2013 (UTC)
OK, for me this indicates even more that it belongs in ULS, if it is not possible in ULS, then it should be MADE possible in ULS. But for the short future, I would not object to having this in Common.css I think. I'm wondering if just "font-family: sans-serif; " would work properly as well. Is the explicit font order required here ? —TheDJ (talk • contribs) 12:14, 7 November 2013 (UTC)
Yeah I think we can drop out most of these (Iran Nastaliq is for Farsi, Pak Nastaliq is for Shahmukhi, the rest are all the same thing) But just using sans-serif won't work. There are a lot of sans-serif fonts and surprisingly, many Latin sans-serif fonts actually render Arabic scripts in serif! (including Arial and many others I've checked—basically, you will get the same result if you render Arabic in either Arial or Times New Roman—so there are specific sans-serif fonts for Urdu.) Well, we can cancel out others to give:
font-family: "Jameel Noori Nastaleeq", "Urdu Typesetting", sans-serif;

Here, Urdu Typesetting is the new Urdu font from Microsoft that is available on all Windows 8/8.1 devices and Jameel is a Noori Nastaliq font prepared with the help of an expert Nastaliq calligrapher which is available free of cost and can be easily installed on older devices.—ШαмıQ✍ @ 12:50, 7 November 2013 (UTC)

For the gajillionth time, why should this go in the ULS? The ULS is universal to every MediaWiki installation. It is not desirable that this change is made universal anywhere but on English Wikipedia. — Lfdder (talk) 14:26, 7 November 2013 (UTC)
For the same amount of time, why the hell would we want to have something en.wp specific ? I simply don't get it. Either you read urdu, and you'd want to view it this way, or you don't. It's not like being able to read English somehow would want to make you read urdu in a different way.. —TheDJ (talk • contribs) 14:29, 7 November 2013 (UTC)

No... It is that the ur.wiki may not welcome it. They have got a consensus or something for not using Nastaliq (and I don't know why) Their Common.css has Nastaliq nowhere. They use Arial instead. What's more, they've got another consensus for not using Urdu numerals. They insist on using Latin numerals in an Urdu encyclopaedia (0123456789 instead of ۰۱۲۳۴۵۶۷۸۹). I got a scolding once by an admin for that. They even got the logo changed from Nastaliq to Naskh... (and I don't know why...) See this, where a user uploaded a file with the text in "Nafees" Naskh font with the summary: "Per community request". (I am unable to find where this request was made. The version dated 22:59, November 23, 2011 is the actual Nastaliq version) And currently, the ULS has the only option of Nafees font for Urdu (which I suspect they might have recommended) In spite of all that, I've asked three admins there if there is any issue regarding the use of Nastaliq and also posted the same on the ur.wiki talk of common.css... For the time being, we may just have Nastaliq for en.wiki.—ШαмıQ✍ @ 16:11, 7 November 2013 (UTC)

That was all I was asking for... Font settings of ULS can be made flexible per installation btw, so that is a solvable issue if need be. I tested the following, and it seems to work quite well. At the same time I suggest filing a bug at ULS to find a long term solution for these problems. This uses preferably some locally installed fonts, the ULS web font NafeesWeb and lastly falls back to anything sans-serif. font-size change is not required because we are not wrapping in a span anymore with this. —TheDJ (talk • contribs) 09:31, 8 November 2013 (UTC)
:lang(ur)
{
    font-family: "Jameel Noori Nastaleeq", "Urdu Typesetting", "NafeesWeb", sans-serif;
}
We've already made it abundantly clear we don't want this added to the ULS; file your own tickets. What problems? This is a perfectly fine long-term solution. — Lfdder (talk) 11:49, 8 November 2013 (UTC)
The ULS can't include Jameel... They want freely-licensed fonts there.—ШαмıQ✍ @ 13:48, 8 November 2013 (UTC)

Re-re-requesting. — Lfdder (talk) 18:11, 10 November 2013 (UTC)

Sorry, but if there is going to be no attempt to have this incorporated in ULS, then I see no reason to put it in Common.css, temporary or not. We really should not encourage any methods for font selection that bypasses Mediawiki's native mechanism. Further more, enwiki would be the only project deviating from the norm. This sounds like you're trying to push a personal preference. I really need a stronger consensus before adding any fonts, especially when it bypasses ULS. Please stop using the edit protected template repeatedly, and start a discussion on WP:VPP to measure consensus for such a change. — Edokter (talk) — 19:19, 10 November 2013 (UTC)

BTW, this is a nice blogpost on the topic of Nastaliq vs. Naskh https://medium.com/writers-on-writing/9ce935435d90 I agree with Edokter that on issues like this we should only deviate as a way to deploy changes before they went trough complicated implementations. If there is no interest in pushing this further into the eco system, it makes little sense to do it only for en.wp. —TheDJ (talk • contribs) 15:40, 11 November 2013 (UTC)

@Syed Wamiq Ahmed Hashmi:, @Lfdder: do you guys have any experience with Hussaini Nastaleeq ? Would be nice if we could evaluate that font for inclusion. It's MIT licensed, which is rather free, though I think open font license would be preferred. —TheDJ (talk • contribs) 11:24, 12 November 2013 (UTC)
Hmmm... A really good font. Not as 'Noori' as Jameel (with a slight variation in glyphs and ligatures), but it really works. I would very much like it we could get this one here. Thank you TheDJ for finding this out. I didn't know about it before. —ШαмıQ✍ @ 12:04, 12 November 2013 (UTC)
I have created a ticket asking for addition, so that we can do some further testing with it. —TheDJ (talk • contribs) 13:10, 12 November 2013 (UTC)

Horizontal lists: Default nowrap behaviour for list items disabled

I have disabled the default nowrap behaviour for list items in horizontal lists. The reason is simple: in its core it does not play well with Internet Explorer, and each subsequent fix caused other issues, the latest of which crashed IE8 on several pages. So I am done trying to acomplish the impossible and removed the core cause. This means list items may wrap across two lines. I think this minor cosmetic issue is an acceptable sacrifice for gaining stability accross the board. If you must have non-wrapping list item, then use {{nowrap}} inline, or add the .nowraplinks class to navboxes. — Edokter (talk) — 13:42, 17 November 2013 (UTC)

look pretty horrible now in FF and chrome. where was the "IE8 crash" happening? if this is the flag image problem, the fix is to add a nbsp between the bullet and the flag. Frietjes (talk) 14:32, 17 November 2013 (UTC)
Horrible != broken. See the latest "Can't use IE8" topics in WP:VPT. It was only the last straw in a long string of issues that were caused by trying to fix yet another IE problem. I am done with fixes, workarounds and hacks for IE; it just does not want to handle white-space:nowrap; properly, so unfortunately it spoils it for ohter browsers. — Edokter (talk) — 15:22, 17 November 2013 (UTC)
so we go back to {{nowrap begin}}/{{nowrap end}}/{{·wrap}}/{{wrap}}? Frietjes (talk) 15:56, 17 November 2013 (UTC)
Rather not. I never got why wrapping is so frowned upon anyway, but someone really wanted it nowrap. Try adding the .nowraplinks class to navboxes instead (all list items are/should be links after all). — Edokter (talk) — 16:03, 17 November 2013 (UTC)
frequently there is text associated with the link, e.g., see the top line of Template:Massachusetts House of Representatives). Frietjes (talk) 18:05, 17 November 2013 (UTC)
I never proclaimed .nowraplinks to be a universal solution. Fact is, nowrap causes too many issues because IE does not play nice. Blame Microsoft. — Edokter (talk) — 18:10, 17 November 2013 (UTC)

As noted in bug 35,337, MediaWiki doesn't currently swap in a high-resolution version of the site logo for systems with high-resolution screens. As a result, the Wikipedia logo on every page here is blurry/pixelated on many mobile devices. The Vietnamese Wikipedia has temporarily worked around this issue, and you can see the result in File:Wikipedia logo comparison at 2×.png. The following code would work around the issue here: 

/* [[MediaZilla:35337]] */
@media (-webkit-min-device-pixel-ratio: 1.5), (min--moz-device-pixel-ratio: 1.5), (min-resolution: 1.5dppx), (min-resolution: 144dpi) {
	#p-logo a {
		background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/204px-Wikipedia-logo-v2-en.svg.png") !important;
		background-size: 136px auto;
	}
}
@media (-webkit-min-device-pixel-ratio: 2), (min--moz-device-pixel-ratio: 2), (min-resolution: 2dppx), (min-resolution: 192dpi) {
	#p-logo a {
		background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/270px-Wikipedia-logo-v2-en.svg.png") !important;
		background-size: 135px auto;
	}
}

It looks like a fair amount of code, but it does exactly the same thing that MediaWiki does automatically on images embedded in articles. The various versions of the media query are for cross-browser compatibility [7], but only -webkit-min-device-pixel-ratio and min-resolution seem to be required for the latest crop of browsers. Users with normal-resolution screens will be unaffected this code, while users with 1.5× or 2× screens will end up loading two copies of the logo, one at 1× and the other at either 1.5× or 2×.

 – Minh Nguyễn (talk, contribs) 10:27, 11 November 2013 (UTC)

Are there any comments / concerns about this request? Otherwise I shall deploy. — Martin (MSGJ · talk) 09:10, 12 November 2013 (UTC)
The logo is just one of many (small) images that could use upscaling. But with bug 35337 pending, I see no problem adding this as a temporary measure. — Edokter (talk) — 16:54, 12 November 2013 (UTC)
plus Added — Martin (MSGJ · talk) 12:38, 18 November 2013 (UTC)
Thanks! – Minh Nguyễn (talk, contribs) 06:10, 19 November 2013 (UTC)

TOC and vertical margin increase?

See also: Template talk:TOC top#Vertical margin increase?

On the majority of articles, table of contents box is positioned too close to the lead section, making that specific part of articles layout looking not so nice. How about having a bit more spacing there, something like adding #toc { margin-top: 0.9em; } to the outer <div> element? It would make positioning of the TOC box much, much better... I've been running that through my User:Dsimic/common.css for about a week, and it looks and works great. Thoughts? -- Dsimic (talk) 21:06, 19 November 2013 (UTC)

Any thoughts, please? — Dsimic (talk) 17:41, 1 December 2013 (UTC)
I don't think it's too close. The space between the lead paragraph and the TOC is 0.5em by way of the bottom margin of the <p>. There is also already considerable whitespace right next to the TOC, and adding space to the top would increase the 'emptyness' around the TOC. — Edokter (talk) — 18:06, 1 December 2013 (UTC)
But then why is there so much spacing after the TOC box, between it and the first section heading? Why is there so much spacing between the article title and the lead section? Why is there so much spacing before and after sections titles – and they also have a lot of empty space to their right? It's all by far disproportional to the space between the lead section and the TOC box, making it look ugly, IMHO. — Dsimic (talk) 18:39, 1 December 2013 (UTC)
That is in the eye of the beholder. Headers have more margin, so there is more space around them. Boxes usually have less margin because they act as containers. — Edokter (talk) — 19:58, 1 December 2013 (UTC)
You're right, but in this case we can take a ruler and measure the disproportion. :) — Dsimic (talk) 20:04, 1 December 2013 (UTC)
The spacing inherent to the TOC box is zero. The visible gap actually comes from the elements which precede and follow the TOC box - the sequence is:
  • last paragraph of the lead, contained in a <p>...</p> element, which has margin-bottom: 6px; border: none; padding: none;
  • an empty <p>...</p> element of zero height plus margin-top: 5px; margin-bottom: 6px; border: none; padding: none;
  • the TOC box, which outside the border has margin: 0;
  • an empty <p>...</p> element of zero height plus margin-top: 5px; margin-bottom: 6px; border: none; padding: none;
  • the first section heading, enclosed in a <h2>...</h2> element, which has margin-top: 0; border-top: none; padding-top: 9px;
All figures are for MonoBook skin, viewed using Firefox 25.0.1 under Windows XP SP3. --Redrose64 (talk) 20:20, 1 December 2013 (UTC)
In Vector, the margin-bottom for <p> is 0.5em and the margin-bottom for the TOC box is 6px (with the line-height for the <h2> providing some extra space). — Edokter (talk) — 21:15, 1 December 2013 (UTC)
@Redrose64: Thank you very much for a detailed overview! Based on the way spacing is currently applied, adding margin-top: 9px; to the TOC box (<div> element) would bring spacing inline with the way it is applied between the article title and first section title in case there's no TOC box on the page. Hope you agree... Thoughts? — Dsimic (talk) 21:23, 1 December 2013 (UTC)
Making such a change upon a single request is not going to happen soon. Trivial changes to the standard interface are unlikely unless there is a pressing need or large consensus to do so, which is ususally followed up by a change in the software itself (using Bugzilla to make the request). — Edokter (talk) — 21:46, 1 December 2013 (UTC)
Totally understood. However, changes in my custom CSS file are making it work for me, and I just wanted to see whether that's something other people might benefit from. — Dsimic (talk) 21:52, 1 December 2013 (UTC)

I see there are recent edits to the Common.css, and I'm wondering where are the discussions that resulted in consensuses prior to those edits? Please don't get me wrong, I'd just like to know how (and where) are made the decisions leading to those edits. — Dsimic (talk) 16:12, 3 December 2013 (UTC)

Most of the code in Common.css aplies to templates or custom CSS (ie. for hlist), which are maintained by several people locally. Minor fixes/edits for templates and such usually do not require consensus, as they do not touch the standard interface of MediaWiki. Any changes to the standard interface do require discussion (for example changes made to the appearence of the watchlist). — Edokter (talk) — 17:25, 3 December 2013 (UTC)
I rather think that Dsimic is referring to these two edits. --Redrose64 (talk) 20:08, 3 December 2013 (UTC)
That was just an honest blunder which he quickly rectified. :) — Edokter (talk) — 21:15, 3 December 2013 (UTC)
Thank you both for detailed insights! Once again, please don't get me wrong, I didn't mean to challenge anything, or do anything else — I was just a bit curious about the associated processes behind those edits/changes to the Common.css. Everything makes sense... A good example of an "intrusive" change requiring previous consensus is this edit, what was discussed in detail before applying any changes. — Dsimic (talk) 22:27, 3 December 2013 (UTC)

Use "mediawiki.hlist" module?

Can we replcae the local hlist code by the one provided by MediaWiki? English Wikipedia is already running MW 1.23wmf5, which includes gerrit:96071 (see bugzilla:40062). Helder 11:07, 9 December 2013 (UTC)

It is already deployed? Anyway, the bug has not been marked resolved yet, so I would wait for that. Also, how should the code be loaded (preferably without js)? — Edokter (talk) — 20:34, 9 December 2013 (UTC)
Yeah, I share the same concerns as Edokter. The bug is still open, questions are still unresolved in the comments (LTR vs RTL...), and the code is (currently?) being loaded with Javascript. I think that last one is a blocker if true.... --Izno (talk) 23:41, 9 December 2013 (UTC)
It's not loaded; only available. Until it is loaded by default, I don't see much profit in replacing the local code. — Edokter (talk) — 18:06, 10 December 2013 (UTC)
Well, yes, but the way I read the bug was that the CSS was loaded via Javascript, which is what I was referencing. --Izno (talk) 18:25, 10 December 2013 (UTC)
It can be loaded without JS, if ResourceLoader is insctructed to load the module by default. — Edokter (talk) — 18:29, 10 December 2013 (UTC)
Have a blank default gadget that has it as a dependency? Seems hacky. Legoktm (talk) 23:04, 10 December 2013 (UTC)

ordered list start with hlist

any idea why this 

<div class="hlist"><ol start=5><li>five</li><li>six</li></ol></div>
  1. five
  2. six

doesn't work in Firefox? the start parameter is ignored, but works without the hlist class. Frietjes (talk) 17:32, 6 January 2014 (UTC)

The start parameter is indeed ignored in hlist because the numbers are generated using CSS. — Edokter (talk) — 18:10, 6 January 2014 (UTC)
Testing an alternative method:
<div class="hlist"><ol start=5 style="counter-reset: listitem 4;"><li>five</li><li>six</li></ol></div>
  1. five
  2. six
That seems to work; you have to substract 1 from the start value as the first value is value+1. But I never anticipated such use as it is impossible with wikimarkup (only possible in raw HTML). Though a small template for use of such HTML is easily made. — Edokter (talk) — 18:30, 6 January 2014 (UTC)
Does not work in IE8... Even though MSDN says it should work, it completely ignores the initial value, both inline and in CSS. — Edokter (talk) — 19:05, 6 January 2014 (UTC)
interesting, this came up with Template:Governors of California. if there is a robust solution, we can roll it into template:ordered list, otherwise, the current method used there seems to be acceptable. Frietjes (talk) 19:09, 6 January 2014 (UTC)
Posted at Module talk:List. — Edokter (talk) — 19:37, 6 January 2014 (UTC)
It is possible to use Wiki markup for the bulk of an ordered list that doesn't start at 1, you just need to convince the first list item that it has a different value, by using the markup #<li value=5>
  2. Five
  3. Six
  4. Seven
Unfortunately even that is broken by hlist:
  2. Five
  3. Six
  4. Seven
--Redrose64 (talk) 20:36, 6 January 2014 (UTC)
Still a bit cheating. But like I said above, hlist uses CSS so it ignores the HTML attributes completely. — Edokter (talk) — 21:16, 6 January 2014 (UTC)
You know what's really f*cked up? That start=5 and value=5 do have the intended effect on hlist in IE8! Anyway, I know why my counter-reset solution doesn't work in IE8; it doesn't like the dash in the counter name. — Edokter (talk) — 23:49, 6 January 2014 (UTC)
And now that I fixed the IE8 issue, start= and value= no longer work :) I initially called my counter list-item (now listitem), which IE probably mistook as a CSS display property. Ah well, all's well now. — Edokter (talk) — 23:57, 6 January 2014 (UTC)
Incidentally, the counter-reset trick also works inside li. — Edokter (talk) — 00:10, 7 January 2014 (UTC)
  2. Five
  3. Six
  4. Seven
— Edokter (talk) — 00:10, 7 January 2014 (UTC)
Made a little template: {{hlist-reset}}.
  2. Five
  3. Six
  4. Seven
— Edokter (talk) — 00:23, 7 January 2014 (UTC)
In Firefox 26, the example of 00:23, 7 January 2014 doesn't work, but that of 00:10, 7 January 2014 does. --Redrose64 (talk) 00:29, 7 January 2014 (UTC)
Oh, it's working now. --Redrose64 (talk) 00:30, 7 January 2014 (UTC)
Yeah, not all browsers handle inline CSS calculations. {#expr: to the resque (see template). — Edokter (talk) — 00:32, 7 January 2014 (UTC)

#babel

All Babel templates in all languages are using the same outer margins except for the new #babel syntax here in the English Wikipedia. Compare to commons:MediaWiki:Common.css and meta:MediaWiki:Common.css, for example. Strangely the original CSS provided by the extension sets all margins to zero. Please add at least the following line. The rest of the design is already very similar and can be made equal but doesn't have to in my opinion. --TMg 15:06, 18 January 2014 (UTC) 

/* Same style for Babel extension and Babel template */
table.mw-babel-wrapper {
	margin: 0 0 0.5em 1em;
}
 Not done for now. This will create a problem for embedded babelboxes, mostly in {{infobox user}}. So a bit more impact analysis needs to be done. — Edokter (talk) — 15:24, 18 January 2014 (UTC)

An expert in mobile.css would be appreciated at Template talk:Redirect#Template not working on iphone. --Redrose64 (talk) 13:34, 18 February 2014 (UTC)

Edit notices and VisualEditor

Due to bug 43013, any red links from Template:Editnotice load/core appear in a distracting "1 notice" popup as soon as you open VisualEditor. Edit notices can't be edited in VisualEditor anyways, so I don't think the links are all that useful. This issue primarily affects sysops and template editors, since normal users currently can't see red links for their own user pages. The following CSS should hide the popup in VisualEditor: 

.ve-activated .editnotice-redlink {
	display: none !important;
}

The Vietnamese Wikipedia uses the same edit notice system as this wiki. It seems to work well there. (We matched against a novisualeditor class that would be helpful to have here as well.)

Assuming the issue for normal users gets resolved, I think this rule should go here rather than at MediaWiki:Group-sysop.css or MediaWiki:Group-templateeditor.css.

 – Minh Nguyễn (talk, contribs) 22:10, 19 January 2014 (UTC)

We already added something like that (see edit 562641575), however that CSS class was accidentally removed by a change in VisualEditor. I recommend against using .ve-activated as it is too generic and will likely lead to unintended side effects. It might work for you, but it will not be supported by VisualEditor if it breaks. Please use the API provided by VisualEditor. This used to be . ve-init-mw-viewPageTarget-toolbar-editNotices-notice but was accidentally removed without a replacement. I'll be adding a new interface to replace this. For now I'd recommend using .ve-ui-mwNoticesPopupTool-item as a stop-gap replacement. Krinkle (talk) 21:56, 12 March 2014 (UTC)
@Krinkle: what is the purpose of the space in . ve-init-mw-viewPageTarget-toolbar-editNotices-notice? I notice that you also did it in this edit. --Redrose64 (talk) 22:31, 12 March 2014 (UTC)
@Redrose64: There is none, that is a typo. I blame OSX for inserting spaces when pasting words in a text field, and myself for not noticing. Thanks, Fixed. Krinkle (talk) 23:55, 12 March 2014 (UTC)
Ah, looks like we copied that rule over to vi:MediaWiki:Common.css at some point, too. – Minh Nguyễn (talk, contribs) 05:56, 13 March 2014 (UTC)

Help with a userscript

So I wrote this userscript a while ago, and now it seems that it has been broken by some Mediawiki CSS update.

Since I have next to no clue about CSS, could someone more knowledgeable please help me out with this.

Playing around with the script, I've managed to get it to take the table of content and move it to a fixed-position box on the left (I replaced "table.toc" with simply ".toc" to achieve this). But the attributes I'm trying to set for the table body don't respond (mainly setting the box to a fixed height with hidden overflow), so I'm guessing I'll have to adjust the second instance of "table.toc" with something else as well, but ".toc" won't work there.

Any help or pointers would be highly appreciated. --85.197.16.74 (talk) 18:22, 16 March 2014 (UTC)

The table of contents is not implemented as a table anymore. It is a div block now. So, you should use div.toc instead of table.toc. And there is no rows and cells inside the div box. The full code is as follows:
var styleEl = document.createElement('style');
styleEl.type = 'text/css';
styleEl.innerHTML = 'td.mbox-image { display: none;} div.toc { position: fixed; top: 160px; left: 160px; border: 0px;  width: 220px; border-bottom: 1px SOLID #CCC; border-left: 1px SOLID #CCC;} div.toc ul {overflow: auto;  max-height: 500px;} body {overflow-x: hidden;}';
document.documentElement.appendChild(styleEl);
Ruslik_Zero 19:07, 16 March 2014 (UTC)
Works like a charm, thank you! --85.197.16.74 (talk) 20:22, 16 March 2014 (UTC)
Instead of using JavaScript, why not simply add the CSS directly to your custom CSS?
td.mbox-image {
    display: none;
}
div.toc {
    position: fixed;
    top: 160px;
    left: 160px;
    border: 0px;
    width: 220px;
    border-bottom: 1px SOLID #CCC;
    border-left: 1px SOLID #CCC;
}
div.toc ul {
    overflow: auto;
    max-height: 500px;
}
body {
    overflow-x: hidden;
}
— Edokter (talk) — 19:31, 16 March 2014 (UTC)
Thanks for the help! I don't have an account, but even if I did I wouldn't want to have to log in when I'm reading Wikipedia just to apply a tiny bit of script. --85.197.16.74 (talk) 20:15, 16 March 2014 (UTC)

GeSHi tab size revisited

@Edokter: Any chance you could take another look at setting the GeSHi tab size at 4 columns rather than 8? Looking at the previous discussions here and here I don't see any objections to the change, other than your point that it should be done here rather than at MediaWiki:Geshi.css. I think it should be as simple as changing this: 

/* Fix so <syntaxhighlight> tags and .css and .js pages get normal text size.
   [[Bugzilla:26204]]. See also [[Wikipedia:Typography#The monospace 'bug']] */
div.mw-geshi div,
div.mw-geshi div pre,
span.mw-geshi,
pre.source-css,
pre.source-javascript,
pre.source-lua {
    font-family: monospace, Courier !important;
}

to this: 

/* Fix so <syntaxhighlight> tags and .css and .js pages get normal text size.
   [[Bugzilla:26204]]. See also [[Wikipedia:Typography#The monospace 'bug']] */
div.mw-geshi div,
div.mw-geshi div pre,
span.mw-geshi,
pre.source-css,
pre.source-javascript,
pre.source-lua {
    font-family: monospace, Courier !important;
    -moz-tab-size: 4; -o-tab-size: 4; tab-size: 4;
}

However, I'd appreciate you looking over that in case I'm about to do something stupid. — Mr. Stradivarius ♪ talk ♪ 03:02, 26 March 2014 (UTC)

I guess it can't hurt to try, even though IE does not support it. But seeing that code editor (which totally barfs in IE8 btw) uses 4-space tabs, then this makes sense. However, since tabs have historically been associated with 8 spaces, you'd think 8 would be the accepted standard across the board. — Edokter (talk) — 11:44, 26 March 2014 (UTC)
Thanks for adding it. It certainly makes it easier on the eye for modules that have unwittingly used both tabs and spaces for indentation. — Mr. Stradivarius ♪ talk ♪ 12:54, 26 March 2014 (UTC)
I think most code editors (BBEdit, etc.) use four-space tabs. Probably because they're all monospaced output, and spaces in mono fonts are full-width, making eight-space tabs very wide.  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  00:06, 27 March 2014 (UTC)

Set default quotes property

With the Typography Refresh, the blockquote element is styled with big quotation marks around it.

This is a blockquote. If you have enabled the Typography Refresh in Beta, you will see the big quotation marks to the left and right.

On my desktop, these are attractive typographic quotation marks. But on an older iPad (limited to iOS 5) these come out as horrendous-looking neutral typewriter quotes – I did a double-take before figuring out what they were supposed to be, and they continue to be very distracting when reading articles with block quotations.

A fix for this is to set the default quotes CSS property for the blockquote element. This matches the English-language default in most browsers: 

blockquote { quotes: '“' '”' '‘' '’'; }

It would probably be better and more consistent to set this for the root element: 

html { quotes: '“' '”' '‘' '’'; }

Or for all English-language elements. The modern method does work in Safari/iOS 5, but may not be supported in all browsers. 

:lang(en) { quotes: '“' '”' '‘' '’'; } /* modern method */
*[lang|=en] { quotes: '“' '”' '‘' '’'; } /* more backward-compatible */

Reference:

 —Michael Z. 2014-02-27 18:11 z

I have commented at mw:Talk:Typography refresh/Archive 2#Setting default quotes property, which is where a permanent fix belongs. Can’t hurt to apply a temporary fix here until that is implemented. —Michael Z. 2014-02-27 18:32 z
I was about to redirect you there. With the Typography Refresh being changed all the time, it would't be appropriate to override it locally; it makes testing harder and has the potential of hiding future errors. — Edokter (talk) — 18:35, 27 February 2014 (UTC)
This seems slighty 'dangerous'. Please be on the lookout for pages that might be broken due to this. Assuming that you can always put two quotes around this makes assumptions about the content and presentation of ALL our uses of the blockquote element, and I doubt that will work everywhere out of the box. (otherwise we would have added them in Common.css long ago, instead of using {{bq}}, {{cquote}}, {{Talkquote}}. I already see one bad assumption, this technique assumes that a quote is always full pagewidth.

Cry "Havoc" and let slip the dogs of war.

— William Shakespeare, Julius Caesar, act III, scene I
Really, they should stop messing about. If they add Template specific stylesheets, then all of this can work, but currently, it's just impossible. You can't make assumptions about the usage of semantic tags like these, we have existing differing uses all over the place. —TheDJ (talk • contribs) 18:52, 27 February 2014 (UTC)

I agree with all of you. However, the quotes property is a separate, broader issue from the specific styling of the blockquote element. If it is not set in some browsers, then it is best to set it explicitly, for consistent rendering in different browsers.

And the setting of quotes isn’t a MediaWiki software issue, but an issue for en.Wikipedia. British and North American English have two different conventions. This wiki’s house style corresponds to the North American, so we should set it locally. —Michael Z. 2014-02-27 20:33 z

Those awful changes to blockquote are being reverted this week, according to posts at mw:Talk:Typography refresh#Giant quotation marks around blockquote. I agree that some code to make browsers do consistent things is a good change, as long as they don't change what most browsers do, only help minority browsers not do stupid things.  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  00:16, 27 March 2014 (UTC)

Drop "dpi" specification from "HiDPI" block and just use "dppx"?

Currently, in advance of bug 35337 getting fixed, we manually specify a couple of "high DPI" image over-rides for the logo: 

/* [[MediaZilla:35337]] */
@media (-webkit-min-device-pixel-ratio: 1.5), (min--moz-device-pixel-ratio: 1.5), (min-resolution: 1.5dppx), (min-resolution: 144dpi) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/204px-Wikipedia-logo-v2-en.svg.png") !important;
                background-size: 136px auto;
        }
}
@media (-webkit-min-device-pixel-ratio: 2), (min--moz-device-pixel-ratio: 2), (min-resolution: 2dppx), (min-resolution: 192dpi) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/270px-Wikipedia-logo-v2-en.svg.png") !important;
                background-size: 135px auto;
        }
}

This is an evolving 'standard' (yay, WHATWG) which explains why there's a couple of manufacturer-specific specifications in there, but it would be really great to drop the ", (min-resolution: 192dpi)" specifications to avoid the deprecation warnings in e.g. Chrome (the new standard is that it should be specified in dppx, as indeed we do). Note that per MDN the devices that will be effected are Firefox > 16 (of whom there are exceptionally few in HiDPI environments), IE > 9 (even fewer), 12 > Opera > 9 (approximately none). The warnings are very irritating when debugging, and will affect very few actual users with a cosmetic issue that is being addressed more appropriately in bug 52019.

Jdforrester (WMF) (talk) 00:52, 27 March 2014 (UTC)

I have one slight reservation. These media queries do not only apply to HiDPI screens, but also to zoom levels on non-HiDPI screens; zooming a page on any device to 150% or 200% triggers the high-res images. By removing dpi, those devices using the older (mobile) browser will no longer be able to see any detail when zooming. (Edit:) But considering this only applies to the logo, I think there is no problem removing the dpi. I shall remove them shortly. — Edokter (talk) — 01:24, 28 March 2014 (UTC)
Thank you! Jdforrester (WMF) (talk) 19:58, 28 March 2014 (UTC)

Moving reference-column-count definition into skin itself

@User:Edokter We have a hacks.less [1] file that goes out to all Wikimedia wikis and is designed to target shared templates across wikis. Would your reference-column-count class in Mobile.css [2] be better there? I'm sure this effects other wikis other than wikipedia and I worry about the cargo cult programming effect...

[1] http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend/f73209dc946d306357ed6dff90c0a9ad1de0c263/less%2Fcommon%2Fhacks.less#L91 [2] https://wiki.riteme.site/w/index.php?title=MediaWiki:Mobile.css&curid=37191945&diff=601499881&oldid=596037685 Jdlrobson (talk) 00:31, 28 March 2014 (UTC)

Jdlrobson - Oh dear... The current hack you have now is ineffective; it tries to apply colum-width on reflists where column-count is already declared inline. And you cannot, and should not use column-count and column-width at the same time unless you reset one of them; otherwise results are unpredictable. Our reflist template makes sure only to use either -count-or -width, never both. On short term, the column-count may be removed from reflist alltogether. In that regard, my code is temporary.
But I can imagine this could benefit other projects as well. The question is, what is your desired result? Do you simply want one column where a fixed number of columns is used (column-count)? In that case, simply copy the code from Mobile.css. This will make sure that adaptive columns (using column-width) are not affected.
If you want to transform an instance of column-count to use adaptive columns instead, you would have to use:
.references-column-count {
    -moz-column-count: auto !important;
    -moz-column-width: 30em;
    -webkit-column-count: auto !important;
    -webkit-column-width: 30em;
    column-count: auto !important;
    column-width: 30em;
}
Personally, this behaviour change seems risky, because you never know what the intended effect was. So I would opt for my code in Mobile.css that simply filters the use of column-count in reflist. But that is up to you. — Edokter (talk) — 01:09, 28 March 2014 (UTC)
It looks like User:TheDJ introduced this in Ie543e56998079afee6307dab8c0f8be692ef9ed3. I think the new ones you have proposed make more sense, Would it make more sense to have them in the software themselves so they can be shared across Wikimedia projects or in here so only English Wikipedia benefits from them? User:Edokter would you be willing to submitting a patch to MobileFrontend either changing the rule or removing it? Jdlrobson (talk) 17:16, 31 March 2014 (UTC)
Perhaps TheDJ can also share some insight. I would advice simply to reset to 1 column. — Edokter (talk) — 17:26, 31 March 2014 (UTC)
My change is from a while ago already. We were trying to get rid of the usage column count altogether back then, but I failed a bit in following that up on wiki (we still have a gazillion column templates that really need consolidating into simpler more sane templates. I'm in favor of Edokters change —TheDJ (talk • contribs) 18:43, 31 March 2014 (UTC)
Just so we are on the same page, my change would be:
/* Disabling column-count for {{reflist}} and {{refbegin}} */
.references-column-count {
    -moz-column-count: 1 !important;
    -webkit-column-count: 1 !important;
    column-count: 1 !important;
}
which is now in Mobile.css. — Edokter (talk) — 19:02, 31 March 2014 (UTC)
No, i meant your other snippet, remember we also have tablet sized screens that use the mobile interface. —TheDJ (talk • contribs) 19:05, 31 March 2014 (UTC)
I think that's risky because you introduce formatting that is unintentional and perhaps unexpected, because you never know how many columns were specified to begin with. you will have editor thinking "where the ... is my third column?" But if you must preserve colums, then 30em (changed) is a good default, as it is the most used column-width here. — Edokter (talk) — 19:16, 31 March 2014 (UTC)
Hmm, good point, that's why we were trying to add columns-# classes for template that used fixed count.... I think we should just convert everything to classes and remove the inline styling. But to be honest, my motivation to work on columns has just been put down the drain due to certain comments that I have been reading..... —TheDJ (talk • contribs) 19:22, 31 March 2014 (UTC)
Do not read the reflist talk page...
Since column widths are somewhat dynamic, putting them all in classes is not possible. But I want to get rid of the column-count feature anyway, so it should not even be a problem anymore (and hope ohter projects follow suit).
Having read the specs a bit more carefull, combining column-count and column-width should result in the count being interpreted as the maximum number of columns. If that is true, then forget what I said above about mixing them; the code in hacks.less may actually be working after all, but I would reduce the width to 30em:
.references-column-count {
   -moz-column-width: 30em;
   -webkit-column-width: 30em;
   column-width: 30em;
}
— Edokter (talk) — 19:28, 31 March 2014 (UTC)
Ah yes. This is why this was so difficult. Precedence is weekly defined here and should not be confused with CSS precedence/specificity. So yes now I remember, in the presence of column-width, column-count does work as a type of 'max columns' and not as a fixed amount of columns, and column-width is the smallest width of a column before a column is 'removed'. And that is why I made the change that Jon is referring to just above. The question is... why isn't it working ?? it seems to me that hacks.less is not actually being include into the mobile site, I can't find it in the inspector.. —TheDJ (talk • contribs) 20:04, 31 March 2014 (UTC)
You should ask Jdlrobson. — Edokter (talk) — 20:18, 31 March 2014 (UTC)
Whoops. I'm restoring the hacks file. https://gerrit.wikimedia.org/r/122869 Jdlrobson (talk) 18:39, 1 April 2014 (UTC)

Horizontal TOC

it would be great if we could get rid of the excess padding before the parenthesis in the horizontal TOC in List of Greek place names. thank you. Frietjes (talk) 21:29, 11 April 2014 (UTC)

That is caused by:
.nonumtoc #toc ul ul,
.nonumtoc .toc ul ul {
    /* @noflip */
    margin: 0 0 0 2em;
}
Is this used anywhere else (some TOC template)? If not, I could simply remove this part; problem solved. — Edokter (talk) — 21:46, 11 April 2014 (UTC)
Actually, that code seems completely redundant with styles from core anyway. I'll have to override, but that's easy enough. — Edokter (talk) — 21:55, 11 April 2014 (UTC)
great. thank you. Frietjes (talk) 14:16, 12 April 2014 (UTC)

Quote

{{Quote}} is no longer styling the font at 85% per the class templatequote:

Now is the time to set the font size.

--  Gadget850 talk 17:01, 6 April 2014 (UTC)

The font size appears to be set in div#content blockquote at 93.75% (reduces normal 12.8px to 12px). Looks small enough to me as the |source= already breaks our guidance at 78%:

Now is the time to set the font size.

— Gadget850, MediaWiki talk:Common.css
--RexxS (talk) 19:32, 6 April 2014 (UTC)
The blockquote font-size has never been set to 85%, but embedded cites are. — Edokter (talk) — 20:11, 6 April 2014 (UTC)
Having requested a tweak to the Quote template to avoid the source displaying at 78%, I've now discovered that it only happens in Monobook. In Vector the quote is rendered at the same font size as the page font size; in Monobook the quote is rendered smaller (94%). Is there any reason for this different behaviour? --RexxS (talk) 08:21, 11 April 2014 (UTC)
Perhaps an oversight... who knows. Does teh quote need to be smaller? I did remove the offending 85% for the embedded source cite. — Edokter (talk) — 12:24, 11 April 2014 (UTC)
thanks. I was looking at this wrong. --  Gadget850 talk 14:21, 12 April 2014 (UTC)

Font size, line spacing

I have the impression that recent changes have made the fonts bigger and line spacing larger. It is especially noticeable in the watch list and article history pages. They look unpleasant now. −Woodstone (talk) 09:29, 14 April 2014 (UTC)

You are correct, the fontzise has increased. See this page on MediaWiki: Typography refresh. — Edokter (talk) — 10:23, 14 April 2014 (UTC)

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 bugzilla:63725. Regards, Nemo 09:45, 10 April 2014 (UTC)

Perhaps a good time to discuss if we want to keep or remove the PDF icons. I am inclined to remove them. — Edokter (talk) — 11:49, 10 April 2014 (UTC)
Looks like this only applies to Vector? Help:External link icons will need an update. And there is a related bug about the icons not having alt tags, so T47891 would be obsolete. We get the occasional edit heated discussion over the PDF icon showing in citation templates and why editors add the seemingly redundant |format=PDF. --  Gadget850 talk 12:36, 10 April 2014 (UTC)
According to Help:External link icons #Skins, the PDF icon is defined in MediaWiki:Common.css, unlike the others. I'd also be inclined to remove the PDF icons. They really don't add much to a url - I suppose a possible warning that it might be a big file for those who have low bandwidths and didn't spot the .pdf extension? --RexxS (talk) 20:59, 10 April 2014 (UTC)
BTW, there would be no problem in keeping the PDFlink class etc. if we wanted to. If we look into the original bug, it's mostly that we simply had too many expensive and not often used selectors. But PDFlink is a very explicit rule, so there is little against that. Such a thing could easily be moved into it's template, if and when we ever do get template stylesheets. —TheDJ (talk • contribs) 13:55, 14 April 2014 (UTC)

Serif headings

Resolved
 – Wrong venue.

What's up with the serif font showing up for h1 and h2 all of a sudden? It's very jarring. I had to override this with:

h1,h2 {
font-family: inherit !important;
}

in Special:Mypage/common.css, and even the !important was required to make that work.  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  17:30, 24 March 2014 (UTC)

Do you have the Typography Refresh beta enabled? Then that's where it's coming from. It probably just updated to a newer incarnation. — Edokter (talk) — 17:36, 24 March 2014 (UTC)
Good catch; that was it. I took the matter (and others, like the huge quotation mark glyphs around blockquote) up at mw:Talk:Typography refresh.  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  00:04, 27 March 2014 (UTC)
Absolutely terrible when I saw the headings H1, H2 come up Serif. Great fix! Brudder Andrusha (talk) 01:47, 4 April 2014 (UTC)
At WP:VPTECH were posted some alternatives that were more specific, but I'm not sure where we'd see an h2 on here that we wouldn't want in the same font as the rest of the page, so my brute-force version should be serviceable.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:32, 16 April 2014 (UTC)

Editors here may be interested in Wikipedia:Templates for discussion/Log/2014 April 24#Template:Rellink, as it has been proposed there that the "rellink" class in MediaWiki:Common.css be merged with the "dablink" class. — Mr. Stradivarius ♪ talk ♪ 06:47, 25 April 2014 (UTC)

plainlist + hlist indentation

@Edokter: FYI, the hlists in Template:History of literature by era are now skewed to the right after this change. perhaps something is needed to restrict this to plainlist within plainlist, and not hlist within plainlist? Frietjes (talk) 16:44, 1 May 2014 (UTC)

Hmm, perhaps:
.plainlist ul > li > ul {
    margin-left: 1.6em;
}
—TheDJ (talk • contribs) 18:46, 1 May 2014 (UTC)
Oh my... nesting hlist inside plainlist. I've tightened the selector and also fixed Module:Unbulleted list which actually managed to put both classes in the same div. That should fix it. — Edokter (talk) — 19:18, 1 May 2014 (UTC)
thanks, I have no idea why Template:History of literature by era can't use a single hlist per section, but there is a certain editor who hates hanging dots and insists on making nested lists, even when the subjects aren't logically nested. Frietjes (talk) 22:03, 1 May 2014 (UTC)
I managed to fix this one, but I don't think I can take another level of template abuse like this... Perhaps you should force one type of list in History of literature by era, as the current setup with nested lists is not semantically correct. — Edokter (talk) — 22:19, 1 May 2014 (UTC)
@Edokter: I think this change broke Wikipedia:Village_pump_(technical)#Where_are_the_HTML_paragraph_tags_coming_from.3F again. —TheDJ (talk • contribs) 21:09, 3 May 2014 (UTC)
Indeed... And that is what started it all. There is no way to untangle plainlist and hlist; eihter we forgo on indenting sublists in plainlist, or we ban nesting hlist inside plainlist. — Edokter (talk) — 22:20, 3 May 2014 (UTC)
Thanks for fixing Module:Unbulleted list. The original template used both classes, but not inside the same div. I should have twigged that they couldn't be used together when I converted it. — Mr. Stradivarius ♪ talk ♪ 03:54, 4 May 2014 (UTC)

Making logo much better

Hi how can I create a css code that does the same for mobiles and tablets but on the laptop like for microsoft windows or Mac OS X. The code is on the bottom on the main Mediawiki:common.css page. It makes the logo clearer and much better but I only see the change on my iPad and iPhone which use webkit. I want to do the same to allow it be used on internet explorer or other web kit browsers on microsoft windows. 94.2.131.205 (talk) 20:18, 2 May 2014 (UTC)

A browser has to support Media queries to display nicer images on higher-resolution displays. Check out the various links provided in that article. — Edokter (talk) — 20:28, 2 May 2014 (UTC)
ok so what code do I use to get it to show on a desktop or laptop because the logo looks really nice on the iPad. 86.173.55.194 (talk) 19:19, 6 May 2014 (UTC)
ok how do I let laptops use it like Microsoft windows and the browser internet explorer supports it I think and google chrome and firefox. please could I have some help because it looks nice on the iPad and iPhone but as it is not linked to the logo for the laptop as for the ios it looks horrible. — Preceding unsigned comment added by 86.173.55.194 (talk) 18:06, 8 May 2014 (UTC)
There is not much you can do; either your browser supports it or it doesn't. I use Chrome on a desktop, and whenever I zoom to 1.5x or 2x, the CSS will automatically use the higher-resolution image. — Edokter (talk) — 19:02, 8 May 2014 (UTC)

Can we add a "hatnote" class that is functionally identical to the existing "dabnote" and "rellink" classes? The {{rellink}} template is going to be merged with the {{hatnote}} template now that its TfD discussion has been closed, and some editors there suggested that we merge the classes in Common.css as well. The name "hatnote" was also suggested as being better than "dablink" or "rellink", as there are plenty of hatnotes that are not disambiguation links or links to related articles or pages. However, at first it would be a good idea to have a transition period where all three classes are usable, so that we don't break any existing uses of the old classes. — Mr. Stradivarius ♪ talk ♪ 03:37, 3 May 2014 (UTC)

That's quite a simple change; we don't need to add any rules, just add another selector to the existing groups of selectors in two existing rules. That is, where we presently have 
/* Hatnotes and disambiguation notices */
.rellink,
.dablink {
    ...
}
.rellink i,
.dablink i {
    ...
alter this to 
/* Hatnotes and disambiguation notices */
.rellink,
.dablink,
.hatnote {
    ...
}
.rellink i,
.dablink i,
.hatnote i {
    ...
This will not affect current usage of the rellink and dablink classes. --Redrose64 (talk) 08:38, 3 May 2014 (UTC)
All done. — Edokter (talk) — 10:57, 3 May 2014 (UTC)
Thanks! — Mr. Stradivarius ♪ talk ♪ 14:40, 3 May 2014 (UTC)

Please alter this slightly, from: 

/* Hatnotes and disambiguation notices */
.rellink,
.dablink,
.hatnote {
    font-style: italic;
    /* @noflip */
    padding-left: 1.6em;
    margin-bottom: 0.5em;
}

to: 

/* Hatnotes and disambiguation notices */
.rellink,
.dablink {
    font-style: italic;
    /* @noflip */
    padding-left: 1.6em;
    margin-bottom: 0.5em;
}
.hatnote {
    font-style: italic;
}
div.hatnote {
    /* @noflip */
    padding-left: 1.6em;
    margin-bottom: 0.5em;
}

or something to this effect.

This would obviate much of the code mess I'm working on at Module:Hatnote/sandbox-inline for {{Hatnote-inline}} and any need for a hatnote-inline class. Instead, I can just modify the existing Module:Hatnote to use a span instead of a div when fed a span=yes or whatever. On the assumption that there may be cases of .rellink and .dablink that aren't divs and need to be in the css as bare .rellink and .dablink not div.rellink and div.dablink, until they're eliminated, a shorter way to do this is the following, but it's less clean in that it has one redundant declaration: 

/* Hatnotes and disambiguation notices */
.rellink,
.dablink,
div.hatnote {
    font-style: italic;
    /* @noflip */
    padding-left: 1.6em;
    margin-bottom: 0.5em;
}
.hatnote {
    font-style: italic;
}

If they are always divs, then this will work: 

/* Hatnotes and disambiguation notices */
.rellink,
.dablink,
.hatnote {
    font-style: italic;
}
div.rellink,
div.dablink,
div.hatnote {
    /* @noflip */
    padding-left: 1.6em;
    margin-bottom: 0.5em;
}

 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  15:38, 18 May 2014 (UTC)

Done. Opted for the last option to eliminate duplicate declarations. — Edokter (talk) — 16:39, 18 May 2014 (UTC)
BTW, someone might wanna update the configuration variable of WMF Mediawiki installations of the extracts extension, with all this renaming etc. That only refers to dablink currently in its list of to be ignored elements. Similarly for Mobile frontend styling perhaps... —TheDJ (talk • contribs) 18:22, 18 May 2014 (UTC)
P'r'aps add a CSS comment in there to remind about future such changes?  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:25, 19 May 2014 (UTC)
Found another case. We also had dab link in MediaWiki:Print.css —TheDJ (talk • contribs) 09:17, 21 May 2014 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=MediaWiki_talk:Common.css/Archive_15&oldid=1166788031"