MediaWiki talk:Common.css/Archive 17

This is an archive of past discussions about MediaWiki:Common.css. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 10

←

Archive 15

Solution for minor linking problem

What's the preferred solution for this problem:

If you do something like this: {{!xt|[[Chicken nugget|Chicken McNugget]]}}, you get the undesirable effect of the red color of {{!xt}} being lost: Chicken McNugget
If you do it this way: [[Chicken nugget|{{!xt|Chicken McNugget}}]], you get the undesirable effect of the link being totally invisible until hovered over: Chicken McNugget

It seems to me that some kind of light underline would be desirable for links in cases where a formatting template is overriding the general text styling of such a link, when the template is used within a piped link, perhaps matching the underlining used in other cases, e.g. for <abbr>...</abbr>: WMF. It might even be desirable to having something like this work for multiple links within such a template, as in:

{{!xt|[[Chicken nugget|Chicken McNugget]], [[Cheeseburger|Big Mac]]}}, displaying something like this (I'm faking it here by misapplying the <abbr>...</abbr> element and individually marking up the two items): Chicken McNugget, Big Mac

To me, the ideal situation would be for all three of these examples to look the same, with red text (in the case of {{!xt}}, and a not-too-obtrusive underline of the link, but no other link styling until hovered/clicked. If you actually hover over my double examples using <abbr> markup as a demo, you'll see that the underlines do not actually align; the one for links is higher.

This would principally be for guideline and template documentation formatting templates, like the {{xt}} template family, used heavily at MoS and various other internal pages. Obviously, I could just go make the templates do something, but I tend to get a lot of blow-back from certain people when I do that, leading to two-month-long debates on this talk page that tend to stall out without fixing anything. So I'm trying the "ask the Mediwedia_talk:Commons.css crowd to come up with their preferred solution" approach, and seeing if that's more practical.

— SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 02:07, 23 August 2015 (UTC)

Worked out a solution for this on my own, given the deafening silence. Can demo it here if anyone cares to see it. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:30, 9 September 2015 (UTC)

Has been discussed before. You're trying to mix two styles, which cannot be resolved without introducing a third style that will confuse the hell out of everybody. -- [[User:Edokter]] {{talk}} 10:56, 9 September 2015 (UTC)

And your better solution for the problems is ... ? To reiterate the problems, so no one has to go looking for them:

If you do it this way: [[Chicken nugget|{{!xt|Chicken McNugget}}]], you get the undesirable effect of the link being totally invisible until hovered over: Chicken McNugget (both an accessibility and basic usability problem)
If you do something like this: {{!xt|[[Chicken nugget|Chicken McNugget]]}}, you get the undesirable effect of the red color of {{!xt}} being lost: Chicken McNugget (defeats purpose of template)

It seems exceedingly unlikely to me that a faint underline (perhaps more subtle than what I demoed here) will confuse anyone, since this exact style is used on literally millions of websites, and is built into various blogging, webforum, and other web-app platforms, as an indication of a link in a not-terribly-prominent way (usage varies, indicating there's popup, a tag in the metadata sense for searching, a tag in the blog sense of "show me this article's category and its other members", allegedly relevant ads, link to the user profile of the poster, etc., etc.) There's probably fairly close to zero Web users who are not immediately familiar with the use, and with the fact that it means "you probably don't need to click here for vital information, as our usual links style suggests, but a link is here if you need it".

An alternative might be a slight different link coloration, closer to non-linked text, but I'm skeptical that this wouldn't raise accessibility issues due to contrast problems. Then again, with the links just being invisible until you accidentally hover over them, even than would be an improvement. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:19, 10 September 2015 (UTC)

Ah, so you want to change the link style in general to always show a faint underline? Or just in those cases where different text styling is present? The latter may be confusing... and I doubt those "millions of websites" make that distinction, and they actually use the underline for links in general (prove me wrong). -- [[User:Edokter]] {{talk}} 15:22, 10 September 2015 (UTC)

Just when the text styling is different and our standard link behavior conflicts or is undesirable, as in these particular templates. Certainly not proposing to change the behavior of all links. Anyway, the point is, everyone knows a dotted underline links to something on the web, and we don't seem to have another way to indicate this in this particular case, other than by doing something even less recognizable. It doesn't matter how many site use a different link style for regular links and tag links; I'm just pointing out that a dotted or dashed underline is one of the most frequent link styles, so everyone knows what it means. Right now, we're doing linking site-wide with color by default, which was probably never a good idea to begin with, but it's also a style everyone recognizes. No one's head asplode. Give people some credit. If we're going to continue doing this color-based link differentiation as our usual thing, there needs to be a workaround when color is being used for something else. This is a pretty standard principle around here in general. E.g., when using italics frequently in an article for something specific, like lots of non-English text, don't also use it for words as words, but use quotation marks (and conversely, on a page with lots of quoted material, use italics for words as words so they're not mistaken for quotations). If there's an string of bold text (heading, etc.), don't use ... to emphasize something it, since it'll being the same boldface effect in most browsers. And so on. People shouldn't have to manually try to do something special each time they need to link in one of these templates to make it even possible to notice there's a link in it. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:50, 10 September 2015 (UTC)

Isn't the snag that we don't actually have a simple way of making a faint underline for links anyway? The text-decoration property, which is universally used to apply such styling to links doesn't provide a means of making the underline faint. The text-decoration-color property, which ought to be the way to do it, isn't supported by any major browser at present, with the exception of Firefox as a -moz- variant. These templates are bad enough for visually-impaired users as it is – all the information is conveyed by colour – and cobbling in an <abbr>...</abbr> would confuse the hell out of a screen-reader user. --RexxS (talk) 16:49, 10 September 2015 (UTC)

They don't convey all their info by color at all, though; there's a font change as well, as explained in the documentation. There's also a luminosity difference between the the colors, but most of us who use these templates do so with clear wording, e.g. "This is not advised: foo; this is better: bar", not something like "The difference is shown in these two examples: bazz vs. quux", in which it's not immediately obvious which is the good example. Any time I see them poorly used as in the latter case, I fix it. These do not usually contain links, but when they do it's generally because they're contextually important, so we do want them noticeable, even if not prominent. I didn't have any trouble coloring an underline effect to be subtle, using border-bottom properties instead of text-decoration (given that it's purely presentational, not semantic, the difference is immaterial; the former works, the latter does not). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:50, 10 September 2015 (UTC)

@RexxS: The text-decoration-color: property has been recognised by Firefox from version 36 on; you don't need to prefix it with -moz-. --Redrose64 (talk) 20:20, 10 September 2015 (UTC)

I tried that approach first, and it failed in something-or-other. One site is saying 'works in the current versions of Firefox and Safari. It will also work in Chrome with the "experimental Web Platform features" flag enabled.' [1] W3Schools shows very low support [2], but I don't know when it was last updated. Same at Mozilla.org (last updated Sep 7, 2015, though that doesn't necessarily mean "last date we checked all of this") [3]. Internet Explorer, Chrome without tweaking, and Opera don't seem to support it yet. Maybe in 2025, LOL. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 20:51, 10 September 2015 (UTC)

I am certain that it was FF 36 because sometime in 2014 I set up a personal web page to use this and other properties described in CSS Text Decoration Module Level 3 that were not in CSS 2 - I was not surprised that they didn't work, since it wasn't a full W3C Recommendation. After my Firefox updated itself from version 35 to v 36, I noticed that the personal web page was displaying those styles, when previously it hadn't. I then posted Wikipedia:Village pump (technical)/Archive 134#New CSS in Firefox. --Redrose64 (talk) 21:39, 10 September 2015 (UTC)

Thanks, Redrose64, it was FF36. I was originally going by what it said at http://www.w3schools.com/cssref/css3_pr_text-decoration-color.asp - which can be out-of-date. Checking at http://caniuse.com/#feat=text-decoration shows more support than I expected, but still only around a third of browsers for prefixed and less than 10% for the unprefixed version. That's really not usable for our purposes yet. --RexxS (talk) 23:37, 10 September 2015 (UTC)

I never believe w3schools. --Redrose64 (talk) 00:06, 11 September 2015 (UTC)

Yeah. I always check multiple such sites for this kind of info. And I tend to ignore prefixed usage, since it's not stable, and a pain in the nether regions to deal with. "Only when absolutely necessary", in my book. Meanwhile, for this particular thing, the border-bottom-style approach has worked since the '90s, in everything. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:02, 12 September 2015 (UTC)

Bullets not growing with lists

As an aside to the thread above, about block quotations and floated images: I don't think we care about image sizes being pixel-measured (by default only), because people can click on them to get the full-size image. However, if people want to relatively size them, they actually can do so, with |upright=X, and its probably a good idea. This could be fixed at the MW level by having a default |upgright=1 used by default, I think, though it's not something I've tested yet, and isn't directly relevant to fixing the blockquote problem. It's also not urgent, because mobile devices will usually forcibly scale down large images (and other elements). Thus, the actual use case for proportional images is people with enormous, high-resolution monitors, for whom normal-sized images in WP articles may look increasingly like tiny icons (I've noticed this effect myself), and who might well prefer the images to grow a bit with page size (I would, but it's much, much less important that block quotations working correctly when next to images, so I have no interest in testing solutions for image scaling right now).

PS: The above tests show we have another minor problem here: The unnumbered list bullets are not growing with font size, the way the numbered list numerals are; I'd have to look around to see why that's the case, but it's obviously something to fix. Anyone who needs a font size that large will probably not be able to reliably notice see the bullets when they are stuck at 100% font size but the text they need is 250% in order to make out the glyphs. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 23:13, 24 August 2015 (UTC)

Unordered list bullets are graphical images - the CSS rule for MonoBook skin is

ul {
  list-style-type: square;
  list-style-image: url("data:image/gif;base64,R0lGODlhBQANAIAAAGOMnP///yH5BAEAAAEALAAAAAAFAA0AAAIJjI+pu+APo4SpADs=");
}

and that for Vector skin is

ul {
  list-style-type: disc;
  list-style-image: url("data:image/svg+xml,%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%3F%3E%0A%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20version%3D%221.1%22%20width%3D%225%22%20height%3D%2213%22%3E%0A%3Ccircle%20cx%3D%222.5%22%20cy%3D%229.5%22%20r%3D%222.5%22%20fill%3D%22%2300528c%22%2F%3E%0A%3C%2Fsvg%3E%0A");
}

which is a percent-encoding of the SVG graphic

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="5" height="13">
<circle cx="2.5" cy="9.5" r="2.5" fill="#00528c"/>
</svg>

- a circle of radius 2.5 pixels centred at the point 2.5 pixels across and 9.5 pixels down of a 5x13 containing block. Images cannot grow with font size. --Redrose64 (talk) 07:36, 25 August 2015 (UTC)

Images can grow with font size. This is a limitation of list-style. Alakzi (talk) 08:30, 25 August 2015 (UTC)

Images are always static (px); they grow with zoom level, but not with font-size. -- [[User:Edokter]] {{talk}} 16:09, 25 August 2015 (UTC)

Yes, otherwise this

image would be twice as large as this

image. --Redrose64 (talk) 16:26, 25 August 2015 (UTC)

You're confusing images with <img>s, which may, in fact, be specified in ems. Alakzi (talk) 22:58, 25 August 2015 (UTC)

<img> is blocked, so not relevant here. -- [[User:Edokter]] {{talk}} 17:02, 26 August 2015 (UTC)

Point being images are quite obviously resizable with font size. We'd use a background image and either "contain" or a percentage for background-size if we wanted to scale the watchlist bullets with font size. Alakzi (talk) 17:10, 26 August 2015 (UTC)

No, point being that images are not resizable using CSS that is intended for text, such as the font-size: property. If you had some HTML on a web page (not Wikipedia, which doesn't allow <img />) like this:

<span style="font-size: 100%;">Example text <img src="example.svg" width=40em /> Example text</span><br />
<span style="font-size: 400%;">Example text <img src="example.svg" width=40em /> Example text</span>

you would see the two images exactly the same size. --Redrose64 (talk) 23:06, 26 August 2015 (UTC)

Obviously, because the "width" attribute denotes the physical width of the image and can only be specified in pixels. If you were to use

<span style="font-size: 100%;">Example text <img src="example.svg" width=40 style="width:1em;" /> Example text</span><br />
<span style="font-size: 400%;">Example text <img src="example.svg" width=40 style="width:1em;" /> Example text</span>

, the images would scale. But this is all academic; we'd not be hacking around with <img>s to scale the watchlist bullets. Alakzi (talk) 23:18, 26 August 2015 (UTC)

Instead of arguing about why they're not growing it would probably be more practical to fix the fact that they're not. I've sandboxed most of a solution for this problem at User:SMcCandlish/sandbox11, but it needs more testing, and it might be something to implement in MediaWiki rather than at WP in particular, though if it worked at WP, it would obviously be a good testbed for building it into MW. I don't really care which way we arrive at better functionality, as long as we arrive. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:43, 8 September 2015 (UTC)

Oh! Forgot to mention that the tests in that sandbox require some CSS, from the top of my User:SMcCandlish/common.css. I guess ~~I could edit them in, inline.~~ I can't; I now remember that I did them in user CSS because it requires things that can't be done inline. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 17:20, 8 September 2015 (UTC) Corrected: 15:08, 12 September 2015 (UTC)

Merge declarations

Can we merge

/* Highlight data points in the info action if specified in the URL */
body.action-info :target {
    background-color: #DEF;  /* Fallback */
    background-color: rgba(0, 127, 255, 0.133);
}

with

/* Highlight clicked reference in blue to help navigation */
.citation:target {
    background-color: #DEF;  /* Fallback */
    background-color: rgba(0, 127, 255, 0.133);
}

? Helder 17:06, 13 September 2015 (UTC)

Are they related? I'd like to maintain some destinction between certain code blocks. And before we merge, is it even in use? (I didn't add it and like some documentation of how to invoke it.) -- [[User:Edokter]] {{talk}} 18:29, 13 September 2015 (UTC)

(Unrelated, I made a mistake removing the space.) -- [[User:Edokter]] {{talk}} 18:32, 13 September 2015 (UTC)

The `cite` element needs to not auto-italicize any longer

After something of an HTML developer community revolt, the early HTML5 change of the <cite> element to only pertain to the title of the work (away from the broader use in HTML 4) has been abandoned, as of late 2013. The published, non-draft version of HTML5 (28 October 2014) has expanded the scope and usage of the <cite> element, which may now be nested inside the <blockquote> element. [4]. (This was initially expected not to take effect until HTML5.1, but oh well.) All of a quotation citation's details are now wrapped in this element, not just the title of a work. Ergo, it should not be auto-italicized on WP, since this interferes with our own MOS and WP's citation styling. More specific spec links: "The cite element", "The blockquote element". Several code examples show <cite> markup of the author, of URLs, etc. not just work titles (and WP does not italicize all work titles, anyway, only major works as defined at MOS:TITLE). Note that not all of the examples illustrate things WP itself would do, or the styles we would use. As an example, this:

It could probably be shown by facts and figures that there is no distinctly native American criminal class except Congress.
– Mark Twain, "Pudd'nhead Wilson's New Calendar", Following the Equator (1897)

is clearly wrongly styled on WP – the <cite>'s wording should appear as: Mark Twain, "Pudd'nhead Wilson's New Calendar", Following the Equator (1897) – despite being marked up correctly (both as to HTML5 and as to MOS). This post is concurrent with a related thread at Template talk:Quote#Changes to cite and blockquote in HTML specs. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 21:36, 30 July 2015 (UTC)

And... back to where it is in HTML 4. Html 5 (apparently prior to 28 October 2014) only applied to the title. *laugh*.

There should probably be a post over at Help talk:CS1. --Izno (talk) 02:46, 31 July 2015 (UTC)

There is an interesting example of the form:

<p><cite>Universal Declaration of Human Rights</cite>, United Nations,
December 1948. Adopted by General Assembly resolution 217 A (III).</p>

which rather apparently is only applying to the title rather than the full work. I suppose the caveat of "must have either title, author, or URL" makes our current use of cite correct, if not the most correct? --Izno (talk) 02:50, 31 July 2015 (UTC)

Although the etymology of 'cite' lies in summoning a person to court, in the sense where it's used on Wikipedia (and in html) it always refers to a work, which can be referred to by its title. From that viewpoint, the semantics of <cite>...</cite> imply that it should apply to the work itself (via its title), whereas the author, date, etc. are related, but not the object of what is being cited. --RexxS (talk) 13:19, 31 July 2015 (UTC)

Except HTML 5 (the October 2014 W3C Recommendation) allows for use of cite containing author or URL as an acceptable substitute to title; and the way I read it is the same as SMC--that is that the whole citation can or should be wrapped in cite. See e.g. the second example:

  <blockquote class="twitter-tweet">
  <p>♥ Bukowski in <a href="https://twitter.com/search?q=%23HTML5&src=hash">#HTML5</a> spec examples
  <a href="http://t.co/0FIEiYN1pC">http://t.co/0FIEiYN1pC</a></p><cite>— karl dubost (@karlpro) 
  <a href="https://twitter.com/karlpro/statuses/370905307293442048">August 23, 2013</a></cite>
  </blockquote>

--Izno (talk) 13:41, 31 July 2015 (UTC)

Not just me; all the usual suspects like HTML5Doctor, W3Schools, etc. say the same thing. As for "can" vs. "should", from the MW:Common.css perspective, assume "should", since some uses (including in templates) will interpret it the broad way. In particular, Template:Quote will probably go back to that way, because the template has separate parameters for author and work, and neither are required, so the element has to surround both of them to be consistently applied. PS: I have notified Help talk:Citation Style 1 about this discussion and its import for that template (the citations we generate with it should be entirely surrounded by <cite>...</cite> again, after we stop italicizing it here. Sooner would be better for that fix, BTW. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:17, 1 August 2015 (UTC)

The current HTML5 spec (that's the one that says "W3C Recommendation 28 October 2014" near the top) indicates in section 10.3.4 that the cite element should be italicised by default. --Redrose64 (talk) 12:01, 1 August 2015 (UTC)

I think this is being looked at from the wrong perspective. The italic recommendation for <cite>...</cite> is merely a presentational issue: it has no effect on the semantics of the markup. On Wikipedia we have always presented the content of our cite tags as italic. This has meant that it is the title of the cited work that has been italicised, even when only as a proxy for the cite tag. Because HTML5 allows more than the title to be valid content of a cite tag doesn't mean that we have to do the same. I can see no reason why our house presentational style should not remain just as it is - it simply implies that we choose to restrict the meaning of any cite tag to the title of a work and correct it when that guidance isn't followed. --RexxS (talk) 13:22, 1 August 2015 (UTC)

Rexxs: It's never actually worked, though. WP (like most formal publications that pay attention to and have a particular citation style) only italicizes the titles of major works, not minor works (see MOS:TITLE). So this auto-italicization is a big FAIL when it comes to the title of a song, poem, chapter, article, etc., all of which are marked up in quotation marks, not italics. We need to do nothing by default with this style, and let the citation, quotation, and other templates do what they need to with it on the fly. There is no actual use case for a bare HTML Title_here in Wikipedia. As I already explained about the quotation template, if this isn't fixed, then the templates cannot use this tag (unless they forcibly de-italicize it with local CSS on the fly) consistently. This is bad for metadata; e.g., one could build a maintenance tool to trawl WP for block quotations without citations, but this would fail for all of those that use {{quote}}, because tag <cite>...</cite> only wraps the |source= parameter, which is optional and only used for titles of major works (books, journals, etc.) — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:51, 5 August 2015 (UTC)

(edit conflict) Redrose64: Yes, I know it says it should be italicized by default. WP is not the default use case, and all HTML+CSS defaults are expected to be overridden when particular use cases don't work with the default options. The defaults exist to just do something. There are plenty of times when that something doesn't suit a particular publisher's exact needs. This is obviously such a case. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:51, 5 August 2015 (UTC)

OTOH, the WHATWG living standard defines <cite> thusly: "The cite element represents the title of a work ... A person's name is not the title of a work ... and the element must therefore not be used to mark up people's names." Perhaps someone in the know could tell us what the status of WHATWG contra W3C is, presently. Alakzi (talk) 13:46, 1 August 2015 (UTC)

That one also says to italicise the cite element, in Section 14.3.4. --Redrose64 (talk) 14:08, 1 August 2015 (UTC)

OTOH to your OTOH, the WHATWG spec suggests that

<p>My favorite book is <cite>The Reality Dysfunction</cite> by
Peter F. Hamilton. My favorite comic is <cite>Pearls Before
Swine</cite> by Stephan Pastis. My favorite track is <cite>Jive
Samba</cite> by the Cannonball Adderley Sextet.</p>

is a correct use of the cite tag. Which, I honestly can't see where that has ever been "typical".

It does seem that the W3C spec is inconsistent, since italicizing as a default anything but a title is also questionable (I suppose we happen to italicize the work in CS1, but I see that as only a "higher level" title).

Alakzi This article is interesting on that point, from later last year. --Izno (talk) 15:48, 1 August 2015 (UTC)

Though, the W3C (latest HTML 5.1 nightly of March 2015; didn't check the stable) does that also at

<p>Who is your favorite doctor (in <cite>Doctor Who</cite>)?</p>

. Blagh. --Izno (talk) 16:03, 1 August 2015 (UTC)

Never use HTML 5.1 nightly as a source. It can change - well, nightly. --Redrose64 (talk) 22:35, 1 August 2015 (UTC)

Agreed on that. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:51, 5 August 2015 (UTC)

So long as I cite my sources, and no-one deigns to provide a counterexample to suggest that the nightlys are particularly different (or even slightly different) in the case of painful inconsistency, it's actually useful to provide what the actual current thought on the use of a particular HTML element is, rather than what it was nearly a year ago. --Izno (talk) 13:54, 5 August 2015 (UTC)

In this case it's seemingly a moot point, because HTML4, HTML5 (the real, non-draft one) and HTML5.1 all agree that this element is for citation information as construed broadly, not strictly for titles only. The title-only thing was in an early version of HTML5 and abandoned in late 2013. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:31, 7 August 2015 (UTC)

(edit conflict) Izno: Yes, it is inconsistent. W3C's use cases for <cite> encompass any conceivable bibliographic/citation/speaker/sourcing material of any kind, and not just for blockquote (having it mean only title of major work was an early HTML5 experiment that was rejected). We, at common.css, cannot possibly predict every WP uses case for this, so the only rational thing to do is not force a style on it, but let the particular uses (mostly templates) determine this. In some cases it may well only be used for title of major work (in theory; in reality many minor works would also get misstyled that way), while in others it would be all non-author work-related metadata, including volume, etc., while in others (perhaps the majority) it'll end up being the entire citation, including the author, and that's the semantically cleanest way to do it, especially with regard to quotation attributions and source citations. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:51, 5 August 2015 (UTC)

I've searched WHATWG's entire mailing list archives, and there's no discussion of a rationale for italicizing <cite> by default. They're just doing it to do something; there's no specific justification for it. And I'm skeptical WP cares what WHATWG wants to do as a default anyway. This is not My First Website, it's a specific publication with specific presentational and reader needs. The entire reason CSS exists is for customization, away from defaults, for such needs. And the fact that all of WHATWG's examples of use of <cite> are for titles (only) of major works (only) indicates that they have not updated since the rejection of the early version of HTML5's limitation of the scope of the element (and may not have properly understood it even when it was briefly in play). Anyway, I've joined WHATWG again and will recommend that they update this material to reflect current (and projected 5.1) usage. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 06:00, 10 August 2015 (UTC)

Probably it's just a holdover from when <cite> was titles-only. I've been slow-musing on this and am probably at the point where I would agree with cite styled as plain text rather than italicized.

While you're annoying the WHATWG folks, I might suggest you ask them whether they believe it would be correct to wrap an entire citation (as you've suggested at Help talk:CS1) with the tag. They'll probably respond in the affirmative, but that would resolve the other I have of the two concerns regarding the use of cite. --Izno (talk) 00:57, 12 August 2015 (UTC)

I'd forgotten about it because of how slow their subscribe bot is. I'll look into it tonight. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:25, 23 August 2015 (UTC)

Update: WHATWG's wiki indicates at least some people there are aware of the change in HTML5 back to the broader interpretation of the element, and that they're recommending WHATWG's own materials be updated to reflect this. I've send their mailing list a request that they get on with it (not phrased like that, of course!), and included the documentation used in our thread here, among other links I've dug up since then. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:50, 23 August 2015 (UTC)

Update: WHATWG is citing the 2009 W3C "Cheatsheet" as their source, for some reason, and it has the old "titles only" definition. I've filed a W3C bug report here, and sent a shorter e-mail to the maintainer of the Cheatsheet, to get W3C to sync their 2009 Cheatsheet database to the actual current spec (at least on this point), so WHATWG in turn will advise the correct thing instead of what they thought was correct 6 years ago. What a bunch of bureaucracy. In the interim, the obvious thing to do is follow the real, current, non-draft HTML5 spec, at [5], like seemingly the rest of the world is doing. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 06:42, 24 August 2015 (UTC)

Update: The maintainer fixed this within just a couple of hours: "Thanks for the report, I have updated the cheatsheet to use the descriptions from the latest HTML5 Recommendation, and it should now use the proper description for the <cite> element in particular." But I'm not sure when the GitHub changes will propagate to the live version of the W3C Cheatsheet (and thus affect what WHATWG will say). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:11, 24 August 2015 (UTC)

Update: The W3C Cheatsheet's live version has now been updated to match the W3C HTML5 spec: "The cite element represents a reference to a creative work. It must include the title of the work or the name of the author(person, people or organization) or an URL reference, which may be in an abbreviated form as per the conventions used for the addition of citation metadata." I.e., any citation data is valid as long as it contains at least one of author, title, or URL to the work (which means in turn we can use it for entire citations, both in citation templates and in the quotation templates, since the citation templates demand a title or will throw an error, and the quotation templates have parameters for an author, a work, or both, but not for citation data in the absence of both). I've notified WHATWG of this change, too, but have no idea how quickly or slowly their internal wheels turn. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:13, 25 August 2015 (UTC)

Thank you for looking into that  SMcCandlish. I agree that we should probably remove the default italicizing here, but we should do it in coordination with the templates that make use of the element. —TheDJ (talk • contribs) 18:04, 8 September 2015 (UTC)

Is there a list of templates that use <cite>? I imagine a lot of citation templates also use it. We could just make the change and clean up whatever floats up. -- [[User:Edokter]] {{talk}} 18:57, 8 September 2015 (UTC)

Here's the templates and modules. No hits for anything in Mediawiki-space. A search for the phrase "cite" appearing in Mediawiki-space turns up nothing but false positives and a similar search in module-space also yields nothing of interest. --Izno (talk) 22:04, 8 September 2015 (UTC)

In most cases we'll want to expand the use of the element to include the full citation data, not just the work title. For some templates, like {{quote}} this will mean changing it to wrap two parameters, not just one. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:33, 9 September 2015 (UTC)

OK, shall I disable italics for <cite>, so we can work from there? If we wait to fix the templates first, we are bound to miss a few anyway? -- [[User:Edokter]] {{talk}} 15:55, 11 September 2015 (UTC)

Go for it. --Izno (talk) 23:44, 11 September 2015 (UTC)

Done. -- [[User:Edokter]] {{talk}} 09:54, 12 September 2015 (UTC)

Huzzah. I've already implemented it around the entire citation data at {{Quote}}, and reported that it can be implemented this way around the citation templates, at Help talk:CS1 (in place of the span that presently wraps them). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 13:56, 12 September 2015 (UTC)

Update: I've fixed its placement and styling in all the templates using it that are not Template:Cite something, Template:Cite/something, or Template:Citation/something, which I've deferred to Help talk:CS1. This was mostly fixing it in single-source citations and in quotation templates. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 13:40, 14 September 2015 (UTC)

Class `boilerplate`

Are we defining anywhere exactly what this class is for and what should typically be done with it; where it should always be used, never used, and optionally used? It seems difficult to generalize from the uses of it that I'm finding, other than it suggests "not the primary content" or something like that. It's not equivalent to unprintworthy, that being separate. I'm not sure if it's meant to be "also not printworthy as well as [some other constraint or lack of constraint]", or totally independent of that kind of analysis. It seems to be used by some hatnote-type things, but is not a part of their default code from Module:Hatnote. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:00, 10 September 2015 (UTC)

boilerplate is an old class that was used by some messaging templates in the pre mbox times. As far as I'm aware, we have no active defined use for it other than 'legacy' —TheDJ (talk • contribs) 17:10, 12 September 2015 (UTC)

Before anyone goes crazy removing it from templates, though, do note doing so will break some of AnomieBOT's regexes for TFD, FFD, PUI, deletion sorting, and {{old AfD multi}} tagging of new articles. So let me know first what exactly you're planning on changing if you intend to do so. Anomie ⚔ 19:20, 12 September 2015 (UTC)

Yes, as always.. please don't brazenly remove classes, because wether it's intentional or not, there is probably a lot of stuff still depending on something like that. Usually when you remove a class, make damn sure that there is a proper replacement with either a semantic or a style intent. —TheDJ (talk • contribs) 20:19, 14 September 2015 (UTC)

More boxes hidden in mobile

See Template talk:Commons category#Mobile visibility? - the rule is not in MediaWiki:Mobile.css. Where is it, and where should it be discussed? --Redrose64 (talk) 22:59, 13 October 2015 (UTC)

These links seem relevant: [6], [7], phab:T107485, mw:Wikimedia mobile engineering#Get involved. PrimeHunter (talk) 00:15, 14 October 2015 (UTC)

Navbar update

There's a proposal at Template talk:Navbar to make navbars more accessible by using <abbr> tags instead of  tags. This would also involve a change to Common.css. Before we go through with this, could people check the CSS proposed at the edit request to make sure it's ok? — Mr. Stradivarius ^{♪ talk ♪} 14:24, 18 October 2015 (UTC)

Update some css

Hi why not change

list-style-image: url(/w/skins/Vector/images/bullet-icon.png)

to

list-style-image: /* @embed */ url(/w/skins/Vector/images/bullet-icon.svg);
/* Fallback to PNG bullet for IE 8 and below using CSS hack */
list-style-image: /* @embed */ url(/w/skins/Vector/images/bullet-icon.png)\9;

Which allows bullet icon to show svg on supported browsers and png on not supported browsers. Paladox2017 (talk) 11:42, 27 September 2015 (UTC)

That is LESS syntax, shich is not supported in site CSS (yet). -- [[User:Edokter]] {{talk}} 13:26, 27 September 2015 (UTC)

I used the old syntax. -- [[User:Edokter]] {{talk}} 13:39, 27 September 2015 (UTC)

@Paladox2017: What does e(...) do?

@Edokter: In this edit, what does the \9 do? --Redrose64 (talk) 18:10, 27 September 2015 (UTC)

@Redrose64: In LESS, e() means to escape any passed text, or to pass CSS literally that LESS does not recognize (it trips over \9). The \9 is a hack to make the line parse only under IE9 and below, while being ignored by everything else. -- [[User:Edokter]] {{talk}} 18:19, 27 September 2015 (UTC)

Well currently svg with png fallback is not supported in list-style-image so a workaround is to only show the png image in internet explorer 8 or lower since chrome is supported on old windows os and is supported on phones too. I am not sure what e does I copied the syntax from background-image and had help from @Edokter to make the syntax for list-style-image work. Paladox (talk) 18:57, 21 October 2015 (UTC)

Class `Unicode` having side-effect

The Unicode class (not sure where that is in the CSS cascade; I don't see it in w:en:MediaWiki:Common.css itself) is having the probably undesirable effect of forcing line-nonbreakability upon anything spanned by the class, including most spacing characters that are explicitly defined as line-break points. Simple test (resize your window horizontally to test):

Bare   test: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism
{{Unicode|&thinsp}} template test: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

Weirdly, it does not do this with all break-point characters, e.g.   (the normal space character):

{{Unicode| }} template test: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

I haven't the patience to put this through a zillion character tests to see which ones it's misbehaving with.

One consequence of this problem is that anything spanned by {{Thinsp|1=}} will not line-wrap even if this is intended:

Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

except where it contains something else breakable, like a regular space character, a manually added thin-space, or a dash (i.e., most of them are probably quite visible):

Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilistic—expialidocious Antidisestablishmentarianism

Fortunately, the zero-width space () does work for this purpose, when inserted "bare" (in this case, where the dash was):

Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism
But not inside {{unicode}}: PneumonoultramicroscopicsilicovolcanoconiosisSupercalifragilisticexpialidociousAntidisestablishmentarianism

The super-freaky part is that in both the — and  examples that did break intentionally in the middle of Super...cious, the line will not break between Super...cious and Anti...ism, but if you narrow the page enough, suddenly it will break between Pneumo...sis and Super...cious, whereas the example immediately above them, which is identical other than not containing — or  (in a position inside Super...cious, unrelated to the Pneumo...sis and Super...cious boundary) will not break between any of the three words. Maybe that little WTF? is browser-dependent (I was testing this in Chromium as I wrote it, and just got identical results in Safari and Opera after saving it).

The non-breaking effect is sometimes desirable, as when {{thinsp}} is used inside delimiters:

( Pneumonoultramicroscopicsilicovolcanoconiosis )

which would look stupid as

(
Pneumonoultramicroscopicsilicovolcanoconiosis
)

which actually happens at a narrow window width in Firefox!

I was going to add a |nowrap=y parameter to ensure it could be made unwrappable, when I discovered that it is almost always non-wrappable already, seemingly by accident (in Chrom*, Opera, and Safari).

PS: I found mention of this class in some scripts, in a function called mw.util.addCSS, which in turn is used by mw.loader.implement; it reads:

       mw.util.addCSS('.IPA { font-family: "Lucida Sans Unicode", "Arial Unicode MS"; } ' + '.Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; } ');

but this doesn't appear to do anything that would cause this line-break issue.

— SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:20, 19 October 2015 (UTC)

I think I narrowed down the problem. (Using Chromium on Linux but getting the same results as what you report for Chrom* on Mac.) Removing the unicode class from the container spans, i.e. from   to  , still results in Chromium treating the thinsp as non-breaking. Matt Fitzpatrick (talk) 10:35, 20 October 2015 (UTC)

Yeah, this appears to be the spans, not the class. For example:

Bare thin-spaces, with the whole string wrapped in the Unicode class:: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism
Thin-spaces wrapped with unclassed spans:: Pneumonoultramicroscopicsilicovolcanoconiosis Supercalifragilisticexpialidocious Antidisestablishmentarianism

It's the span-wrappers that are causing the behaviour. {{Nihiltres |talk |edits}} 20:43, 21 October 2015 (UTC)

Interesting. This will bear some deeper testing, as it may have some implications for various templates. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:15, 25 October 2015 (UTC)

Yes it's the spans. or rather, it is the fact that adjoining characters can have extra meaning, and by using the spans, you add yet some extra meaning, effecting the linebreaking logic. Short story: Just DONT do this, it cannot work. If your browser is dumb enough not to support thinsp properly, then u should get a better browser or OS, not work around it by wrapping it with something that might force a font, that MIGHT save u, or not. Adding hacks like {{thinsp}} for such crappy old browsers can have side effects and you just found one. That's why I don't favor such kind of hacks. —TheDJ (talk • contribs) 21:18, 21 October 2015 (UTC)

I'm having difficulty following the point of that half-rant. A behavior exhibited by a large number of browsers is not "dumb" behavior by one "crappy old browser". I have no old browsers on any of my systems (except in virtual machines for testing during development). {{Thinsp}} is not some "kind of hack", it's a simple, routine wrapper template like {{nbsp}}, and {{snd}}, providing a wiki-syntax-familiar alternative to raw HTML code for editors who's learned the former but not the latter. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 11:15, 25 October 2015 (UTC)

Double redirect warning

div.redirectMsg a.mw-redirect:after {
  content: ' <double redirect>';
  color: #000;
  font-style: italic;
}

CSS to warn users from creating double redirects. — Dispenser 23:39, 15 November 2015 (UTC)

Print style header and footer

Is there a way to control the style of the printed version in my my custom CSS under the @media print? I'm trying to change the font of the headers and footers, framed in red, in that screen shot. Thanks in advance. --Mahmudmasri (talk) 12:30, 2 January 2016 (UTC)

I think that is controlled by the printer driver or browser, not our print stylesheet. -- [[User:Edokter]] {{talk}} 15:37, 2 January 2016 (UTC)

Yes you can, I do it at meta:User:Redrose64/monobook.css --Redrose64 (talk) 21:11, 2 January 2016 (UTC)

I'm afraid that does not affect the header and footer as outlined by Mahmudmasri. -- [[User:Edokter]] {{talk}} 21:14, 2 January 2016 (UTC)

Thanks Edokter. You are right. --Mahmudmasri (talk) 13:08, 3 January 2016 (UTC)

Plainrowheaders with centered text

I suggest adding another class that works like plainrowheaders but does not left-align the text. This could be useful where centering is desired but bolding is not, as the plainrowheaders style overrides the table's alignment, so you can't just set style="text-align: center" on the table to center the headers, you have to do it on each header individually.

In order to retain backwards-compatibility, this needs to be a separate class – I don't expect anyone to go over thousands of articles to replace class="plainrowheaders" with class="plainrowheaders leftalignrowheaders" or similar. So here's what I'm proposing (better suggestions for the class name are welcome):

.wikitable.plainrowheaders-center th[scope="row"] {
    font-weight: normal;
}

– nyuszika7h (talk) 22:33, 30 December 2015 (UTC)

Before something is added here, it needs to be established that there is a general need for it, as Common.css is loaded unconditionally for everyone. There does not seem to be an actual need here; it just adds a superfluous option class. The goal for the plainrowheaders class is to emulate plain table cells in headers. -- [[User:Edokter]] {{talk}} 15:44, 2 January 2016 (UTC)

Putting the spec aside for argument's sake and accepting the "...goal for the plainrowheaders class is to emulate plain table cells in headers", why wouldn't this work for everybody?

/* Normal font styling for table row headers with scope="row" tag */
.wikitable.plainrowheaders th[scope=row] {
    font-weight: normal;
    /* @noflip */
    text-align: inherit;
}

Unless style="text-align: center" is also set on the table tag, the scope=row TH's still text-align left with a normal font weight for me (or is that 'just me'?). -- George Orwell III (talk) 18:08, 3 January 2016 (UTC)

No, that's 'just your browser'. The spec says nothing about text-alignment in <th>...</th>. Unless we explicitly specify the text alignment on an element, a browser will normally make its own choice. Most browsers will centre text in <th>...</th>, but a lot of Wikipedians have expressed a preference to see row headers left-aligned (and normal-weight) for some tables, which is why the argument was made to introduce the "plainrowheaders" class. Otherwise it was difficult to get the row headers marked up as headers for accessibility, because many editors wanted to keep the cells as <td>...</td> because it fitted how they thought the table should look (without any consideration for screen readers). --RexxS (talk) 20:01, 3 January 2016 (UTC)

Not exactly - you are right that it is the user agent that 'ultimately' determines the text-alignment and you are right about it needing to be set for agents to respond properly but it is also the spec that states what is expected to be defined in a compliant agent's stylesheet...

User agents are expected to have a rule in their user agent stylesheet that matches th elements that have a parent node whose computed value for the 'text-align' property is its initial value, whose declaration block consists of just a single declaration that sets the 'text-align' property to the value 'center'.^{19 sentences below quirks mode table in 10.3.9}

so obviously my browser works as expected by changing the forced text-align:left to 'something' allowing for the matching of text-align: 's initial value (which is LEFT btw [if direction is LTR]) This is needed to replicate the now deprecated align=center property/value for table tag(s).

I used inherit in common.css and it seems to work on test2 in spite of any .css from the MediaWiki code possibly 'interfering' with the example. -- George Orwell III (talk) 22:49, 3 January 2016 (UTC)

Here's a wiki-table:

column header	column header
row header	data cell

I would expect the row header cell to be presented by most browsers as bold and centred.

Here's the same table but with the row header's style set to "text-align: inherit;":

column header	column header
row header	data cell

I would expect the row header cell to be presented by most browsers as bold and centred, just as the first table. If your browser displays it as left-aligned, then either you have an unusual browser or some custom css. --RexxS (talk) 03:09, 4 January 2016 (UTC)

@RexxS: No relevant custom CSS. In Firefox 43.0.3 and Opera 12.17, it's left-aligned. That is what I would expect, since inherit instructs the element to use the styling of the parent element, which is a <tr>...</tr>. In Chrome 47; IE8; Opera 34.0; and Safari 5.1.7, it's centred. --Redrose64 (talk) 18:58, 4 January 2016 (UTC)

Thank you, Redrose64. As text isn't found directly inside any table element other than a cell, I can understand why a browser designer might choose not to respect inheritance of default text alignment. The lack of consistency in the implementation of 'inherit' within tables between major browsers suggests to me that we ought not to attempt to use it in these sort of cases. --RexxS (talk) 18:27, 5 January 2016 (UTC)

I've not seen the same desire expressed for normal-weight, centred text inside a row header. --RexxS (talk) 20:01, 3 January 2016 (UTC)

Nor have I. But that doesn't make using scope for formatting or eye-pleasing purposes right to begin with either. And if you're going to manually add scope=row to the th element in certain cases to trigger in part .plainrowheaders, then I don't see what the difference would have been in defining a class to achieve the same goal(s) and applying that to the parent tr or the th as warranted instead. -- George Orwell III (talk) 22:49, 3 January 2016 (UTC)

If it was just a question of "what is right", I wouldn't have found it necessary to spend many hours trying to convince other editors that they should be marking up row headers as headers for the benefit of the visually-impaired. The class "plainrowheaders" is merely presentational sugar that makes the markup more palatable to those editors. I've yet to see any similar argument to justify creating further classes. --RexxS (talk) 03:09, 4 January 2016 (UTC)

.wikitable.borderless

I would like to add a class for wikitables with no borders on its cells. The table would still have borders, and the header cells only on top and bottom (which perhaps could be disabled with another .borderless on the tr or th), but the data cells would not have any borders.

The application for this would be for some full-width tables that do want the wikitable's background styles, but not its border styles on all cells. To be concrete, I would like this for the player tables on football teams. Those currently all use a template that has a contested format because it does not use existing classes, making them appear bad in dark skins for example. A solution could be to convert them into wikitables, but then I'm sure there will be a revolt because of all the borders inside them, so wikitables without the data-cell-borders seems like a good compromise. –Sygmoral (talk) 05:24, 7 January 2016 (UTC)

Cell borders are basically required for accessibility. --Izno (talk) 12:24, 7 January 2016 (UTC)

Thank you for your answer. But I do not fully follow, as I do not see borders explicitly mentioned on that accessibility page. Could you please give an example of how someone may be disadvantaged due to lack of borders in a wikitable? I can understand it for small tables with small values, but wide tables with wide contents provide a clear enough overview thanks to all their whitespace. Can we consider this for those cases? –Sygmoral (talk) 19:09, 7 January 2016 (UTC)

After all, infoboxes and a few other standard tables don't have borders inside them either, so it must be acceptable in some cases. I can understand that it may be abused for tables where it should not be used, but then again, abuse is always possible with manual code. By the way, I suggested the .borderless classname because it is already used for infoboxes. –Sygmoral (talk) 19:34, 7 January 2016 (UTC)

Inline nested hatnotes

It might be nice if nested hatnotes displayed inline. This would let us use two or more hatnote templates but display them as though they were a single template. CSS, example wikitext, and intended result follow:

CSS:

div.hatnote div.hatnote {
    display: inline;
    padding-left: 0;
}

Example wikitext:

{{hatnote|
{{distinguish|Foo}}{{other uses|Bar}}
}}

Intended resulting look of example wikitext:

A bit of an edge case (most pages only need one hatnote), but a short, simple improvement where applicable. {{Nihiltres |talk |edits}} 04:55, 18 January 2016 (UTC)

Wouldn't the correct improvement be to use the correct hatnote? Your case is covered by {{about3}} IMO. --Izno (talk) 12:13, 18 January 2016 (UTC)

@Izno: There are lots of pages which have multiple hatnotes for one reason or another, and I'd be surprised if all of them are potentially covered by existing templates. That said, this idea would in theory allow us to make hatnotes modular, and thereby eventually deprecate templates that exist purely to compound two or more of the others—like {{distinguish-otheruses}}, which is probably what you meant rather than {{about3}}? That seems like a good thing, but … one proposal at a time. {{Nihiltres |talk |edits}} 05:17, 19 January 2016 (UTC)

I found a decent example on Orphan while standardizing some hatnotes. It uses {{Selfref}}, which is incompatible with all other hatnotes and which requires manual text rather than easy automatic hatnote formatting. Using my proposed system, it'd be trivial to make it nicer:

{{hatnote|
{{selfref|{{For|orphaned articles in Wikipedia|Wikipedia:Orphan}}}}
{{other uses}}
}}

{{Nihiltres |talk |edits}} 07:08, 19 January 2016 (UTC)

If we want a modular hatnote system, it should be build from the ground up. Nesting hatnotes is a hack though, so I'm not starting from that. -- [[User:Edokter]] {{talk}} 11:38, 19 January 2016 (UTC)

@Edokter: In what ways do you object to its hackishness? The obvious alternative would be to have it be not nesting, but some sort of envelope class ("hatnote-group"?) achieving a similar result.

Regardless, the focus here should not be on "modular hatnotes": those are just an obvious improvement that could be made given the possibility of compound hatnotes. In the short term, I'm working on standardizing existing, nonstandard hatnotes, mainly manually-formatted (:'') stuff that doesn't distinguish hatnotes from regular content, leading to practical problems like hatnotes showing up in Hovercards because TextExtracts doesn't distinguish the manually-formatted ones from the rest of the lead.

One of the most consistent problems I've had while making progress is editors resistant to breaking up a single manual hatnote into multiple nicely-templated ones, since individual hatnotes are naturally separated by unwanted linebreaks. It's easy, albeit inelegant, to reproduce the older single-line hatnote by using manual text and {{hatnote}}, but the obvious, elegant solution of concatenating two or more templates on the same line is just out of reach with the current CSS setup. {{Nihiltres |talk |edits}} 16:56, 19 January 2016 (UTC)

I'm a bit confused on few points... isn't the hatnote based equivalent to one of the given "problematic" examples --

{{selfref|For orphaned articles in Wikipedia, see [[Wikipedia:Orphan]].}}

-- replaceable/interchangeable with

{{hatnote|For orphaned articles in Wikipedia, see [[Wikipedia:Orphan]].|selfref=y}}

for starters?

And why do we want two or more hatnotes to render inline anyway? I'm fairly certain the opposite (or current approach) provides better readability/accessibility for mobile/tablet visitors for example. -- George Orwell III (talk) 23:13, 19 January 2016 (UTC)

@George Orwell III: I'm not sure I understand your first point. Each of {{selfref}} and {{hatnote|selfref=true}} accomplish basically the same thing (as long as you don't use {{selfref}}'s |inline option). In the "Orphan" example, the {{for}} produces the text, gets wrapped in {{selfref}} to mark it as such, and the {{other uses}} isn't a selfref. So if an external use stripped selfrefs, they'd get just the {{other uses}} as desired, but it's still one line when not stripped out.

In the second… I'm not entirely sure why people want it that way, but I've had changes reverted to restore that style on multiple occasions with different Wikipedians. I think that having hatnotes uniformly on one line would make things more consistent, because right now certain combinations of hatnotes require two (or more) lines, whereas similar text constructed using other hatnotes only requires one line. For example, compare these:

{{redirect|A|B|C|and|D|other uses|E}}
{{redirect4|A|B|C}}{{other uses|D}}
{{redirect4|A|B|C}}

If we decide that linebreaks are more usable, then we should be consistent with that, too. I mainly just want things to be consistent and clean. {{Nihiltres |talk |edits}} 05:40, 20 January 2016 (UTC)

I still don't get it - mostly because its still not clear to me if your concerned with insuring other entities "recycling" Wikipedia content elsewhere are not peppered with extraneous hatnote linkage useful to WP visitors but at the same time are not relevant (or are broken) in relation to that "recycled" content being viewed from elsewhere or if you're just looking to redesign the rendering behavior of hatnotes locally. You point to Orphan thinking that only the non-selfref other uses portion would be helpful to said "recyclers" somehow but currently neither of those templates would be "shown" to outside recyclers anyway as evidenced by the print version of the Orphan article.

In short, either Orphan is a bad example here or you're operating on assumptions or something rather than actual template behavior. -- George Orwell III (talk) 07:47, 20 January 2016 (UTC)

@George Orwell III: The orphan article is a bad example, if only because it's introducing the tangential issue of selfrefs. Here's my logic:

Hatnotes are currently applied inconsistently, with some pages using manual :'' formatting, which is semantically bad and demonstrably causes bad behaviour in Hovercards via TextExtracts.
I want to fix inconsistent hatnotes with nice templated ones
Some people don't like that multiple hatnote templates display on multiple lines (for whatever reason), and are willing to revert my fixes on those grounds.
It's probably a good idea for hatnotes to be on a single line, if only because it would be more consistent than our current system. See my {{redirect}} & {{redirect4}} example above, where very similar text has inconsistent linebreaks.
Hatnote collections that use two or more templates currently cannot be displayed on a single line without CSS changes.
Templates exist for certain combinations of hatnotes, but not all of them.
The alternative, writing out the compound hatnote as manual wikitext into a {{hatnote}}, is not good for maintenance.
Bonus: Sometime in the future, it might let us create a more modular hatnote system that would be better than our current one.

These lead me to think we should change the CSS to allow multiple hatnotes to display on a single line—the focus of this proposal. {{Nihiltres |talk |edits}} 16:57, 20 January 2016 (UTC)

Sidenote: I don't think we need to embed anything inside {{hatnote}}; div.hatnote + div.hatnote should work, shouldn't it? --Izno (talk) 12:38, 20 January 2016 (UTC)

@Izno: No, it wouldn't work, because that selector would only catch the second of a pair of adjacent hatnotes. Even if it caught both, it wouldn't let the combined hatnotes display as a block, which would disrupt their normal styling. {{Nihiltres |talk |edits}} 16:57, 20 January 2016 (UTC)

@Nihiltres: Let me address the points you listed for starters; Personally, I agree that Point one is a symptom of/and a good rationale for attempting to execute Point two BUT absent any specific guideline(s) currently in place recommending/declaring/suggesting/etc. that the community should use template based hatnotes "over" the use of manually added 'string' (:'') ones -- even if its just to some degree versus the other -- then they are probably justified in reverting your changes on those grounds alone AND without any further needed discussion relating to your Point 3 about reverting based on a change from single line rendering to multiple line rendering taking place at all. I'm not sure any such guideline exists or what it may outline as policy or good practice if it does, but [imho] that justification is the first thing you should ascertain and/or secure here otherwise most of the rest of this proposal is moot & pointless to continue.

That said, your various "claims" in the points that follow about what is better for... or would be more consistent than... or not good for maintenance... and similar are not supported by the basic facts at hand. If at some point during the development of the 'Hat Note' aspect truly wanted inline rendering beyond a specific association of the same type or family to be all inclusive regardless, it simply would not have been originally designed using block level (DIVs) exclusively nor would that intention survived the subsequent consolidation of hatnote templatization with the advent of Module:Hatnote. If you visit the talk page there, you'll see what am driving at here as well as my comments above.

In short, the best thing to do is comply with the current guidelines concerning HatNotes whenever possible first, convert as many similar incarnations of "inconsistent" hatnotes as possible to use the current Hatnote meta-template and supporting hatnote Lua module scheme currently in place 'with nice [compliant] templated ones' afterward.

Only then would I believe it possible to consider the addition of any "option for inline rendering deviation". I think that would provide you with the modular approach you seek and most likely begin by requiring the introduction of 'wrapping' spans within the current DIV based foundation - something fairly easily accomplished en masse if done through the HatNote module (as that is why Module:s were introduced to begin with). Patching the .css to nullify 'original intent' in my view is just not the "right way" to go about any of this regardless. -- George Orwell III (talk) 05:25, 22 January 2016 (UTC)

Wikipedia:Hatnote says it pretty explicitly: In most cases, hatnotes should be created using a standard hatnote template as illustrated below. This permits the form and structure of hatnotes to be changed uniformly across the encyclopedia as needed and the templates to be excluded in print. While it only implicitly favours non-generic hatnotes (i.e. {{about}} or {{redirect}} etc. over {{hatnote}}), it does explicitly favour single-line hatnotes, though without giving a justification. The guideline is pretty nebulous (and probably out-of-date; I just fixed instances of :'' formatting there), so improvements there might be something to start an RfC over or something.

This particular proposal is dead in the water, so I'll abandon it for now, with an eye to approaching the desired fixes from a different direction (e.g. perhaps I can create a unified template to support more edge cases and deprecate many of the current zoo of templates that currently exist) sometime in the future. {{Nihiltres |talk |edits}} 22:29, 30 January 2016 (UTC)

Responsive image positioning

Hi all,

I propose to add the following CSS:

@media only screen and (max-width:768px) {
	div.thumb {
		float: none;
		clear: none;
		margin: .5em auto;
	}
	div.thumbinner {
		margin: 0 auto;
		max-width: 100%;
	}
	div.thumbinner img {
		max-width: 100%;
		height: auto;
	}
}

This will reposition image thumbnails to be centered and to clear other content on narrow pages. This is similar to how the mobile interface positions images in narrow views. If this is successful, I'll upstream this into our central repository. —TheDJ (talk • contribs) 10:04, 2 December 2015 (UTC)

Anyone ? Or shall I just flip the edit request button ? —TheDJ (talk • contribs) 14:21, 4 December 2015 (UTC)

Let me test it for a bit. -- [[User:Edokter]] {{talk}} 18:25, 4 December 2015 (UTC)

The a > img selector needs to be tightened, as non-thumb images in tables resize to 1x1. See List of atheists (surnames A to B) for example. -- [[User:Edokter]] {{talk}} 18:33, 4 December 2015 (UTC)

@Edokter: It seems we can safely remove max-width from that rule and we would be just fine. —TheDJ (talk • contribs) 19:21, 4 December 2015 (UTC)

That would degrade pages with images larger than the viewport though... We could also cancel it out when inside a table. There would still be problems if it were used inside an element with table styling, but those case are probably really minimal.. And it doesn't seem there is actually any other way to do responsive image sizing inside tables... —TheDJ (talk • contribs) 20:08, 4 December 2015 (UTC)

If tables are targeted, then where does it end. Can't we just target thumbs for now? -- [[User:Edokter]] {{talk}} 21:22, 4 December 2015 (UTC)

Made some adjustments and targeted only thumbs. Can you test this? -- [[User:Edokter]] {{talk}} 18:43, 5 December 2015 (UTC)

That works, though we won't have responsive sizing for inline images then. But honestly, that doesn't seem possible at all if we want to keep support for using them inside table layouts. —TheDJ (talk • contribs) 13:02, 7 December 2015 (UTC)

Inline images (like flag icons) should probably be left untouched anyway. I can't think of any other uses, except maybe the ones taking a separate paragraph; but those are hard to taregt as well. And tables are tables; they are always mobile-unfriendly. -- [[User:Edokter]] {{talk}} 16:58, 7 December 2015 (UTC)

Anyone care to deploy this ? —TheDJ (talk • contribs) 16:53, 2 February 2016 (UTC)

Done. -- [[User:Edokter]] {{talk}} 17:13, 3 February 2016 (UTC)

@Edokter: Can this change be undone, there is no consensus for it to be imposed on en-Wiki. It is ruining articles having images centered with no option to force them left or right. See discussion at VPT on en-Wiki. Mjroots (talk) 18:22, 3 February 2016 (UTC)

There was no consensus not to implement it, either. Also, it wasn't "imposed on en-Wiki"; it was done entirely by en-Wiki itself, with zero outside involvement. WhatamIdoing (talk) 19:53, 5 February 2016 (UTC)

I reverted, since at least one user is reporting adverse effects, see Wikipedia:Village pump (technical)#Image display issue. --Redrose64 (talk) 21:10, 3 February 2016 (UTC)

Use grey text for section numbers in Table of Contents boxes

I suggest tweaking the CSS for .tocnumber to use a grey color.

This would make it a lot easier to read the Table of Contents, by more clearly distinguishing the content (Headings) from the metadata (section numbers). Especially if the Headings start with numbers.

The code I use/suggest, is:

/* Tweak Table of Contents boxes, to have grey numbers */
.tocnumber {color:#333 !important;}

Any support/feedback/etc would be appreciated.

I've also suggested that this would be a good change for the default in MediaWiki, and have proposed it at phab:T125317. Trying it here first, was suggested by TheDJ, and seems like a good idea. Thanks. Quiddity (talk) 20:48, 23 February 2016 (UTC)

I like the gray; have you checked contrast to ensure it makes at least AA contrast delta? --Izno (talk) 20:57, 23 February 2016 (UTC)

Just noting: the tocnumber already has #333 as color. -- [[User:Edokter]] {{talk}} 21:04, 23 February 2016 (UTC)

My bad... that is the NewImageThumb gadget. (Give it a try.) -- [[User:Edokter]] {{talk}} 21:10, 23 February 2016 (UTC)

@Izno: According to Snook, it's fully AAA compliant against the #F9F9F9 background that monobook provides for me. In fact, it's fully compliant against any grey background lighter than #D9D9D9 --RexxS (talk) 22:17, 23 February 2016 (UTC)

Can we avoid using !important? That annotation gets overused, in most cases careful choice of selector eliminates any need for !important. Overuse of !important causes its effect to be diluted. Think of it like this: if lots of declarations have !important, what do people do when they want to override one of those? There is nothing in CSS to mean "even more important than !important", but there are many ways to increase a selector's specificity. --Redrose64 (talk) 10:47, 24 February 2016 (UTC)

@Redrose64: Suggestions/improvements welcome! Although in this case, my hope is that it will be a resounding success here at Enwiki, and then will become a global default soon thereafter, at which point it will be done more 'properly' as it were. (I.e. ongoing progress in https://gerrit.wikimedia.org/r/#/c/272708/ ). Quiddity (talk) 19:14, 24 February 2016 (UTC)

Navbox show/hide padding

Current navbox:

Proposal:

Code:

.collapseButton a {
	padding: 0 2px;
}

Anyone else think that the collapse buttons for navboxes needs some work? Adding a bit of padding to the clickable area would be a minor improvement, in my opinion. (I also don't like that they change widths when clicked, but that's for another day.) --Yair rand (talk) 12:58, 22 February 2016 (UTC)

I prefer the unpadded version; why do you think this needs change? What are you looking to improve?

Aside: I'd prefer us to the use the mw-collapsible class, but that has a known regression for en.WP over 4 years since deployment.--Izno (talk) 13:10, 22 February 2016 (UTC)

It would make it more inline with the current section [ edit ] links, which use 0.25em between the brackets. But then I would prefer a wider solution to cover all spacing of brackets containing links. -- [[User:Edokter]] {{talk}} 21:06, 22 February 2016 (UTC)

+1. --Yair rand (talk) 19:22, 24 February 2016 (UTC)

Navbar VTE linebreak

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The current declaration for .navbar ul causes line breaks to appear between the edit link and the closing square bracket (see: Template:Crossrail RDT). To fix this, display:inline should be changed to display: inline-block. Sceptre ^(talk) 17:53, 25 February 2016 (UTC)

I'm not seeing the fault (which browswer?), ~~and technically, the display setting should not affect what's inside the container~~. Also, have you tested inline-block will not break other brosers? -- [[User:Edokter]] {{talk}} 19:19, 25 February 2016 (UTC)

The fault occurs, apparently, in Safari on OS X only. Sceptre ^(talk) 20:56, 26 February 2016 (UTC)

I see that the title of that template is built in an unconventional way (with a left margin of 55px), which is really squeezing it tight for the navbar. It may just be that the navbar is one pixel short if you happen to have a slightly larger font set. Perhaps the better fix is to use a scaling unit in Module:Routemap instead? -- [[User:Edokter]] {{talk}} 09:55, 27 February 2016 (UTC)

Proposal to inline hatnote styles

There is a proposal to move the .hatnote styles from MediaWiki:Common.css and MediaWiki:Mobile.css inline to Module:Hatnote because currently they generate a flash of unstyled content on mobile. Please see the discussion at Template talk:Hatnote#Please apply inline style to .hatnote class. — Mr. Stradivarius ^{♪ talk ♪} 23:50, 24 March 2016 (UTC)

If that is the argument, then everything should be made inline... well, obviously not. Mobile should fix its loading of Mobile.css instead. -- [[User:Edokter]] {{talk}} 12:04, 25 March 2016 (UTC)

Reducing the padding in the WikiEditor's dialog windows

Tracked in Phabricator
Task T114597

I propose reducing the padding in the WikiEditor's dialog windows, which make them too big. This is particularly a problem with the Search & Replace window, because while it is open you need to be able to see the textarea as well, but the window may cover part of it. I have been using this code for a long time, and it works great.

.wikiEditor-toolbar-dialog {border: 1px solid lightgray;}
.wikieditor-toolbar-field-wrapper { padding-bottom: 5px;}
.wikiEditor-toolbar-dialog .ui-dialog-content { padding: 10px 10px 5px !important;}
.ui-dialog-buttonpane button {margin-top: 0; margin-bottom: 0;}
body .ui-dialog .ui-dialog-titlebar {padding-top: 5px !important; padding-bottom: 5px !important;}
body .ui-dialog .ui-dialog-buttonpane { padding: 0.1em 1.3em 0.3em !important }

--V111P (talk) 21:51, 6 May 2016 (UTC)

I don't think the padding is extreme, but if any tweaking is to be done, it should be done in MediaWiki itself, since it usess the OOUI library. You know you can resize the dialog? -- [[User:Edokter]] {{talk}} 07:41, 7 May 2016 (UTC)

The problem is not just with the padding at the edge of the window, but mostly with the padding above and below the elements inside of it. I agree that is should be fixed in MediaWiki, but we can't do much about that. Anyway, I just wanted to share my solution to this problem. --V111P (talk) 22:15, 7 May 2016 (UTC)

Slightly reduce collapsed state reflow

I propose to add the following fragment to Common.css

.client-js .collapsible.collapsed > tbody > tr:not(:first-child) {
	display: none;
}

This should slightly improve the reflows of content caused by collapsing of content, in the few cases where we already know that they should be initially collapsed. —TheDJ (talk • contribs) 20:14, 19 May 2016 (UTC)

Wait, we will also need a change to common.js of course. —TheDJ (talk • contribs) 20:21, 19 May 2016 (UTC)

Accompanying JS change. Testpage —TheDJ (talk • contribs) 20:38, 19 May 2016 (UTC)

Done. -- [[User:Edokter]] {{talk}} 06:39, 20 May 2016 (UTC)

flags in tables on mobile

This edit request to MediaWiki:Mobile.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I propose we add the following fragment to Mobile.css

.flagicon img {
    min-width: 25px;
}

This fixes one specific and often occurring case of phab:T116318. —TheDJ (talk • contribs) 13:54, 17 March 2016 (UTC)

Yeah, took me a moment to understand that bug report, because the table-embedded flags are so small they just look like dots. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:54, 7 April 2016 (UTC)

Done. Made it 25px because of the border flags have. -- [[User:Edokter]] {{talk}} 08:24, 20 May 2016 (UTC)

Mobile version style

How to edit the font style of Wikipedia's mobile version, similarly as we to those of vector.css, common.css or common.js? --Mahmudmasri (talk) 06:11, 21 May 2016 (UTC)

@Mahmudmasri: It's at MediaWiki:Mobile.css (that was a random guess). nyuszika7h (talk) 08:32, 21 May 2016 (UTC)

imagemap-inline class

Regarding the following:

/* Inline divs in ImageMaps (code borrowed from de.wiki) */
.imagemap-inline div {
    display: inline;
}

I think this class can be removed after some cleanup (see search).

The definition has been added with this edit in January 2008 (copied from dewiki) and is quite nonsensical because it never worked properly: it totally breaks the blue "i" icon (see mw:Extension:ImageMap for examples) because it applies display:inline to too many elements.

Actually, the only real use-case of this class were "fake" imagemaps that consist of a single clickable area and have no "i" icon. Such imagemaps have in the past been widely used, but since October 2008 they are no longer necessary because of the "new" [[File:Example.svg|link=...]] syntax.

It has already been removed at dewiki. --Entlinkt (talk) 21:43, 22 May 2016 (UTC)

Found only one article still that stil used it (fixed). The rest is all user space , most of which are copies of Common/Vecotr.css, and one template talk page. I say it is safe to remove, so consider it

Done. -- [[User:Edokter]] {{talk}} 22:12, 22 May 2016 (UTC)

updatedmarker needs important?

See Wikipedia:Village pump (technical)#Highlight of "updated since my last visit". PrimeHunter (talk) 22:47, 26 May 2016 (UTC)

The !important annotation is a cop-out. In the majority of cases, it's better to increase the specificity of the selectors. --Redrose64 (talk) 23:40, 26 May 2016 (UTC)

Sounds fine. I have limited CSS knowledge but have added span. in span.updatedmarker.[8] PrimeHunter (talk) 10:28, 27 May 2016 (UTC)

Protected edit request on 10 June 2016

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

To ensure uniform appearance across different browsers and platforms and compliance with MOS:FONTSIZE (Firefox 46 on Windows 10 renders  much smaller than 85% for me), the following code should be added:

small {
    font-size: 85%;
}

(Suggested by Izno on my edit request at Template talk:Unsigned.)

nyuszika7h (talk) 13:58, 10 June 2016 (UTC)

It does seem a little strange that we allow browsers latitude to interpret ... themselves. In many cases, of course, it's best to give flexibility to the user agent, but when there are clear accessibility implications - as in tiny text size - I agree that we should be specifying how the tag should render. --RexxS (talk) 15:14, 10 June 2016 (UTC)

Both Chrome and Firefox translate it to use font-size:smaller. It is there that the discrepancy occurs. This might fix , but not any style using font-size:smaller directly (see here). But it's a start. -- [[User:Edokter]] {{talk}} 15:54, 10 June 2016 (UTC)

Firefox 3.0 and MSIE 5.5. :D --Izno (talk) 16:26, 10 June 2016 (UTC)

Agreed, let's start somewhere. It would be good to see if we have any instances of font-size out and about in the wiki-world (template or otherwise). --Izno (talk) 16:27, 10 June 2016 (UTC)

There's plenty, but most use relative values (like 85%) instead of keywords (such as 'x-large' or 'smaller'). It's those keywords that need attention. Unfortunately, most of them are emitted from MediaWiki itself. -- [[User:Edokter]] {{talk}} 19:43, 10 June 2016 (UTC)

I think either is undesirable from the point of view of a gadget which works on certain assumptions, and which obviously can't deal with inline CSS. --Izno (talk) 21:11, 11 June 2016 (UTC)

Highlighting free to read external links in scholarly references

I bring to your attention the project of adding a special marker for some free-to-read external links in scholarly citations. We think the best way to do this would be to add a CSS marker, just like for PDF links, like this. I have added a thread on WP:VPR to gather discussion around it (not on WP:VPT because it is not just a technical change, but something that would affect the visual appearance of many references). Adding it in common.css would not directly impact any article, because the `free-to-read` class is not used yet, but would enable us to integrate it cleanly in Module:Citation/CS1. Do you think such a change would be feasible? Do you have any comments about the appearance of the logo, or the way I propose to add it? It would be great if you could comment at Help talk:Citation Style 1. I will then submit a formal request here. Thanks! − Pintoch (talk) 15:56, 20 June 2016 (UTC)

table.mbox-small edit request

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Old revision of MediaWiki:Common.css to Old revision of User:Matt Fitzpatrick/common.css (diff)

Will allow a tableless layout update to Template:Sister project links (sandbox) (testcases). Incorporates feedback from Wikipedia:Village pump (technical)#CSS support for tableless layouts.

Matt Fitzpatrick (talk) 22:30, 5 July 2016 (UTC)

Quick question. Which other templates might this change affect? — Martin (MSGJ · talk) 10:58, 6 July 2016 (UTC)

@MSGJ: Module:Message box also puts class="mbox-small" or class="mbox-small-left" on anything using the metatemplates {{ambox|small=left}} {{tmbox|small=yes}} {{ombox|small=yes}}. I didn't see any differences in Template:Ambox/testcases, Template:Tmbox/testcases, Template:Ombox/testcases with or without my user CSS. These metatemplates would have to remain <table>s for now, since there are other joined table.*mbox selectors further up in Common.css that I'm not messing with (yet). Matt Fitzpatrick (talk) 22:41, 6 July 2016 (UTC)

Happy to make the change later today unless there are any comments from others — Martin (MSGJ · talk) 12:22, 7 July 2016 (UTC)

Done — Martin (MSGJ · talk) 10:33, 8 July 2016 (UTC)

Protected edit request on 13 July 2016

This edit request to MediaWiki:Group-templateeditor.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The shading on the text box is pretty dark, relative to its normal color, and should be changed from #FFDBDB to #FFE0E0 for readability. (This suggestion comes after too much time spent getting annoyed over the color instead of being warned, as I presume the original intention was.) Enterprisey (talk!) _{(formerly APerson)} 01:13, 13 July 2016 (UTC)

Done — xaosflux ^Talk 02:02, 13 July 2016 (UTC)

table.navbox to just .navbox

Sorry, didn't think I'd be back so soon.

We had to revert a change at Module:Portal bar, taking it from a div-ul back to the old nested table-table-div-ul. It was using the navbox class to overlap borders, as in Template:Portal bar/testcases#Adjacent navboxes, and the margin declarations to do that are under specific table.navbox selectors in MediaWiki:Common.css.

I can get Portal bar back to a div-ul, with a change to those selectors. Something along the lines of Old revision of User:Matt Fitzpatrick/common.css. I've looked through the CSS of the desktop skins, and couldn't find any margin declarations that would require the extra specificity of table.navbox. On Template:Navbox/testcases, if I turn off the site table.navbox rules, my user .navbox rules achieve the same appearance for all the Template:Navbox/testcases and desktop skins. Does this change seem safe and sane? I'll put up an edit request if it seems okay. Matt Fitzpatrick (talk) 21:33, 13 July 2016 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Edit requested: copy Old revision of User:Matt Fitzpatrick/common.css to MediaWiki:Common.css (compare)
Changes: lowers specificity of table.navbox selectors to .navbox so any element can match; box-sizing: border-box; so a non-table .navbox still uses the table box model

Left notices at Template talk:Portal bar, at Template talk:Navbox just in case, and for User:Dinoguy1000 who was working on something potentially related at Module:Navbox/sandbox. Matt Fitzpatrick (talk) 23:57, 14 July 2016 (UTC)

Done by MSGJ. — xaosflux ^Talk 12:00, 15 July 2016 (UTC)

Tables in route diagram templates

(Pinging Sameboat and Useddenim.) For a while, I've been trying to fix the multiple issues with the display of {{Routemap}} in Minerva / mobile view. However, there are a few remaining problems which can't be solved simply by editing the module (test in Template:Routemap/testcases):

On narrow pages in Minerva, due to usage of nested tables each row of icons appears to be stuck to the left, due to a rule for .content table which applies width: 100% !important.^[a] Could this be overridden by adding a CSS class or custom attribute to each row's table cancelling that rule?
Collapsible rows (1, 2) do not work in mobile view, as the JavaScript for collapsibility isn't actually loaded. For link 2, since currently all the rows (collapsible and replaced) are shown, could a new CSS class (perhaps routemap-replaced with rule display:none) be added to eliminate the display problem?^[b]

Thanks, Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 10:56, 29 July 2016 (UTC)

Notes

^ {{BS-map}} (mentioned code is in {{BSrow}}), Routemap's older and non-module-dependent sibling, seems to have had this solved by using width: 0px on each row. (The code seems to have not been updated along with the CSS rules.) However, this doesn't work for Module:Routemap/sandbox, since in replicating the {{BStext}} series of templates (not in production version yet) the width of each row can't be hard-coded to the minimum, as all the text becomes squashed.
^ A better solution to this would be, of course, to enable collapsibility, but that was probably a decision made for the benefit of mobile view in general to make it easier to use.

Horizontal list templates that use commas?

I was directed here from this discussion regarding the use of bulleted flatlists/h-lists, where I'm favoring commas rather than bullets; commas are more commonly understood by readers as a separator of items in a list, but for accessibility reasons, bulleted lists have gained more widespread use in article infoboxes and other templated tables. Has anyone requested a similar template using commas instead? Commas are used elsewhere in articles (prose, for instance), so for internal consistency, it would make sense for templated lists to use commas instead. Dan56 (talk) 00:53, 3 August 2016 (UTC)

What we would do here is not create a template per se, but create a class that could be used by a template, much like the hlist class is used by the {{hlist}} template. This new class might be as simple as taking the various rules matching existing hlist class, copying them and altering where appropriate. The rule which presently adds the dots is:

.hlist dd:after,
.hlist li:after {
    content: " · ";
    font-weight: bold;
}

we would begin by removing the second declaration and altering the first to content: ", "; --Redrose64 (talk) 08:45, 3 August 2016 (UTC)

We don't actually need to copy anything except for the rule specifying the list item separator--we can simply add a .hlist-comma class to each of the CSS declarations. --Izno (talk) 13:18, 3 August 2016 (UTC)

Why do you need an HTML list for a comma separated list ? What does it add ? The original hlist was designed very much specifically for dealing with a practice inside navboxes that created an accessibility problem. But I see no such problem here. It's possibly of course, but all this complexity has a price as well. —TheDJ (talk • contribs) 13:39, 3 August 2016 (UTC)

We often get requests from editors/readers who object to the middot as a visual separator in an infobox (as opposed to a navbox), and prefer commas as being more consistent with normal prose. That loses the benefits of semantic markup and the ability of a screen reader to navigate back and forth through a long list. The lastest example is at Template talk:Infobox album #Harmonization with other music templates as the OP indicated. Having a horizontal list class that used a comma separator might satisfy all points of view. There's been a demo of a 'cslist' class in my User:RexxS/common.css for a couple of years now. I'm not able to judge whether the extra complexity is too big a price to pay for the extra functionality. --RexxS (talk) 14:54, 3 August 2016 (UTC)

Is there an expectation that we need to accommodate large lists in infoboxes? That seems to defeat the purpose of an infobox. Regarding semantic value, we don't ask for users, in prose, to provide that semantic value (though clearly HTML + CSS support that), so that removes another large need (and would seem to indicate we also do not need such in infoboxes). The place I have seen hlists where a comma separated list might be valuable would be in {{sidebar}}, but even there, I think hlist alone is Good Enough. --Izno (talk) 15:08, 3 August 2016 (UTC)

Template:Infobox album which kicked off this debate has examples of larger than normal lists - genre and producer commonly attract multiple items. Count the number of "associated acts" in many examples of Template:Infobox musical artist, and so on. I'm not promoting having long lists in infoboxes, merely commenting that they exist and we ought to cater for them as best we can. As for semantics, can you tell me whether |producer=Tom Hamilton, Aerosmith means that the producer was Tom Hamilton (musician) (the bass guitarist in Aerosmith) or that perhaps Tom Hamilton Jr. and Aerosmith were both credited as producers? Why shouldn't we mark up a long prose list as a HTML list if it provided benefit to screen readers and content re-users, anyway? What's to stop us if the css existed? --RexxS (talk) 16:15, 3 August 2016 (UTC)

A quick re while I consider the rest of your questions: I understand your problem case ("Tom Hamilton, Aerosmith") but I don't think it makes your point for you. It is a problem case regardless of the HTML underlying, for visual users, since most will not be bothered to check the HTML or the wikitext, for the vast majority of persons are readers and not editors. (Aside: My inclination is to interpret such as two separate producers.) --Izno (talk) 19:37, 3 August 2016 (UTC)

Don't forget all the readers who receive the information from our articles via third-parties, whose automated tools can extract the intended meaning if we use semantic markup. Do we know how many of those there are? In any case, surely all the readers who don't bother to check are no worse off if the HTML provides the correct meaning, while everyone else benefits. There's no downside in that equation. --RexxS (talk) 20:07, 3 August 2016 (UTC)

Hide FlaggedRevs notice when stable version is synced

On pages with pending changes protection, there is currently both the pending changes notice added by mediawiki and the protection template. The template is useful since it categorizes and such, but having also the notice is redundant. It is now possible to hide the notice without also hiding it when the page actually has pending changes, in which case it's useful. So I suggest to hide them when there are no pending changes using:

.flaggedrevs_draft_synced,
.flaggedrevs_stable_synced {
    display: none;
}

Cenarium (talk) 18:46, 23 September 2016 (UTC)

I would think this would best be upstream, since I agree that we should not see a synced notice, with or without a secondary template to indicate flagged revs protection. --Izno (talk) 18:59, 23 September 2016 (UTC)

This already took a while to get this change in, I don't think we could have anything more done in the code on this subject in a reasonable amount of time (it would need a configuration switch since other wikis may want to keep it in, etc). Cenarium (talk) 15:39, 24 September 2016 (UTC)

IPA class

.IPA {
	font-family: Gentium, GentiumAlt, DejaVu Sans, Segoe UI, Lucida Grande, Charis SIL, Doulos SIL, TITUS Cyberbit Basic, Code2000, Lucida Sans Unicode, sans-serif;
	font-size: 110%;
}

.IPA, .IPA * {
	font-style: normal;
}

I am puzzled that there are no CSS properties assigned to languages (lang="") and the IPA class, as there are on Wiktionary. Is there perhaps another CSS file that has these? It's certainly possible that the idea has never been implemented, since languages are not consistently tagged on Wikipedia.

If not, I propose that the following code be added. It is essentially a copy of the CSS on Wiktionary. These are fonts that support the characters in the International Phonetic Alphabet, which uses the IPA class on Wikipedia. IPA transcriptions are never supposed to be italicized, hence font-style: normal;. — Eru·tuon 19:35, 5 November 2016 (UTC)

I believe this text was here but was removed. Either way, I think {{IPA}} already has the CSS in-line. Try searching the archives above to verify or the template talk page of the IPA family templates. --Izno (talk) 04:30, 8 November 2016 (UTC)

It was removed since basically only Windows XP required it, and XP is no longer supported. In other situations, these declaration broke as much as they fixed. —TheDJ (talk • contribs) 09:40, 8 November 2016 (UTC)

@Izno: No, {{IPA}} doesn't include any inline CSS. Neither does {{IPAlink}} or {{IPAc-en}} or any of the other IPA templates that I am aware of. @TheDJ: What do you mean about this CSS breaking things? I don't understand; it's valid and should work. — Eru·tuon 14:10, 8 November 2016 (UTC)

If you mess with the order of the rendering engine you will get about as many breakages as you are fixing. We saw cases, where the defaults were giving just fine results on some platform, and with changes in the font order were suddenly selecting very old and incomplete fonts that had been installed by old versions of Microsoft office for instance that degraded the experience. There was always something, and no definitive solution. In the end, we just opted to get rid of it, because most modern browsers just do proper font selection and glyph fallback and don't have an actual problem that has to be dealt with. —TheDJ (talk • contribs) 14:29, 8 November 2016 (UTC)

Change CSS depending on Category

I don't suppose any knows of a reasonable way to use a different CSS per category? I know you can use namespace codes to change it by namespace, but changing CSS by way of the [[Category:]] on the page is not an ability I can find anywhere. I'm really looking for a solution to add a graphic banner, or a template, or somethin', based on Category. --146.200.233.235 (talk) 21:49, 9 November 2016 (UTC)

Not possible through CSS alone, but you could use some JS to make it work, using mw.config.get( 'wgCategories' );. --Yair rand (talk) 21:55, 9 November 2016 (UTC)

Every page has two classes that (I think) are unique to that page, they are named in the class= attribute of the <body>...</body> element. For instance, this page belongs to the classes page-MediaWiki_talk_Common_css and rootpage-MediaWiki_talk_Common_css. This page is in two categories, which themselves have two unique classes each: Category:MediaWiki messages with interface explanation has the classes page-Category_MediaWiki_messages_with_interface_explanation and rootpage-Category_MediaWiki_messages_with_interface_explanation, and Category:Wikipedia pages with to-do lists has the classes page-Category_Wikipedia_pages_with_to-do_lists and rootpage-Category_Wikipedia_pages_with_to-do_lists. Notice how colons, spaces and full stops are both replaced by underscores. --Redrose64 (talk) 00:21, 10 November 2016 (UTC)

These are both very helpful comments, thank you! I'll look into this <3 --146.200.233.235 (talk) 12:38, 12 November 2016 (UTC)

Empty list items aren't empty anymore

See Template:UK Wikipedia meetups. The London row begins with a whole series of dots before the first actual entry is reached (14 Aug 2011). These dots are from the hlist class, they used to be suppressed because something recognised that the <li>...</li> element was empty (it's empty because Template:UK Wikipedia meetups/date has a date test). Now the dots are displaying, even though the li is still empty. Any idea why the dots are no longer suppressed? --Redrose64 (talk) 19:57, 6 August 2016 (UTC)

There's some stuff going on with wikitext -> HTML conversion related to removing Tidy, which may (or not!) be related. --Izno (talk) 12:42, 8 August 2016 (UTC)

[9] 82.73.181.57 (talk) 13:05, 13 August 2016 (UTC)

moved the bullets inside the parser function, so probably fixed in that case? Frietjes (talk) 14:00, 13 August 2016 (UTC)

Maybe someone could help with the implementation of hlist on yiwiki. It does not function properly for nested lists. See yi:מוסטער:מעטראפאליטאן ליניע סטאנציעס Any idea how to get this to work? --Redaktor (talk) 17:52, 16 November 2016 (UTC)

Regularise spacing between paragraphs on talk pages

I've made a proposal at Wikipedia:Village pump (proposals) #Regularise spacing between paragraphs on talk pages to regularise the spacing between "paragraphs", both indented and unindented, on talk pages. As this will arrive here if it gains support, I wanted to give a courtesy notification to those watching this page who may have some useful input. Cheers --RexxS (talk) 18:58, 1 September 2016 (UTC)

As there were four positive comments (Izno, Johnuniq, Enterprisey, SMcCandlish) made at VPP before it was archived, I'll make the request here for implementation as an RfC. --RexxS (talk) 22:45, 16 November 2016 (UTC)

Recent WMF Change

Hello @Seddon (WMF): - can you please explain this edit you just rolled live without so much as an edit summary? — xaosflux ^Talk 02:50, 8 December 2016 (UTC)

When replying, please identify if this is an official OFFICE action intended to override the community consensus process on the English Wikipedia. — xaosflux ^Talk 03:12, 8 December 2016 (UTC)

Hey @Xoasflux:. In short this is not an OFFICE action, it's not been done although I was asked to do this as part of my role at the WMF (which is why I used my staff account rather than my volunteer admin account). Basically there is a partnership going on between a number of community groups including Women in Red, Wikimedia UK, Wikimujeres and other affiliates relating to [10]. The was WMF asked late into the process if we could take our fundraising banners during the partnership due to a potential conflict of interest due to the BBC being a public service broadcaster. Given the scale of the project, and the extent and scale of what was being asked when the fundraiser was already in progress, we were trying to find the best alternative to support the volunteers as best we could to make sure this project could go ahead and not have hours of volunteer time wasted. The only way we could think of what to physically suppress fundraising banners on a list of pages involved. Doing that via the site common.css was the only viable alternative. It will only need to be in place for around 24 hours and after that the change can be rolled back. Apologies for not going through the proper channels. Seddon (WMF) (talk) 03:27, 8 December 2016 (UTC)

Thank you for the update - hopefully we can find a better solution for next time. Please follow up on the removal after the conflicting event. — xaosflux ^Talk 03:29, 8 December 2016 (UTC)

(see related campaign here: 100_Women_(BBC)#2016) — xaosflux ^Talk 03:33, 8 December 2016 (UTC)

RfC for changing colors to align with Wikimedia UI

Hey, Wikimedia now have a brand-new color palette that passes WCAG standard for accessibility (for color-blind people). These colors are being used all across the interface. For example wikipedia.org now uses these colors or OOjs UI colors are now align with these colors. I hereby suggest to change interface colors too to give readers a standard UI instead of super colorful one making the whole website ugly. For example see what I've done in in Persian Wikipedia :)Ladsgroup^overleg 10:03, 26 November 2016 (UTC)

I cannot see YELLOW90 #fef6e7 or BASE90 #f8f9fa from the white background on my display. Additionally, ACCENT90 #eaf3ff and RED90 #fee7e6 are difficult to see. — Dispenser 17:58, 26 November 2016 (UTC)

1- The Yellow90 is incorrect. The correct one is YELLOW90 #fef6e7. 2- I think these colors should be background for mbox-es to make it easier to read inside them. For borders, I think using the primary colors such as Yellow #fc3 or Blue #36c is the sane option here (See my changes in fawiki common.css) :)Ladsgroup^overleg 18:13, 26 November 2016 (UTC)

Fixed the color. Displays can vary significantly in color reproduction and most designers are unaware of this. I just wanted to point out it as colors from #f0f0f0 to #ffffff risks turning to white on crappy displays. — Dispenser 04:57, 30 November 2016 (UTC)

A color in itself says nothing. It only matters how the colors of various elements are combined. —TheDJ (talk • contribs) 11:12, 30 November 2016 (UTC)

@Ladsgroup: Can you be more specific about which elements you want to change ? —TheDJ (talk • contribs) 11:12, 30 November 2016 (UTC)

@TheDJ:. Thanks. Let me explain in details:

.infobox: border: #aaa to #a2a9b1 background: #f9f9f9 to #f8f9fa (same for .infobox.bordered and other similar ones)
table.ambox: #aaa to #a2a9b1, #1e90ff to #36c (important IMO), #fbfbfb to #f8f9fa
table.ambox-speedy: #b22222 to #d33 and #fee to #fee7e6 (Same for table.ambox-delete)
table.ambox-content: #f28500 to #ac6600
table.ambox-style: #f4c430 to #fc3
table.ambox-protection: #bba to #a2a9b1

Everything about ambox can be applied to imbox, fmbox, cmbox, ombox, etc. See this :)Ladsgroup^overleg 16:16, 30 November 2016 (UTC)

Request for editing Mediawiki:common.css

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Per Special:PermaLink/753600253#RfC for changing colors to align with Wikimedia UI and Special:PermaLink/754556867#Reopening discussion about aligning colors with Wikimedia color palette and no objection after the given time, please change content of Mediawiki:Common.css with content User:Ladsgroup/common.css. This change is barely noticeable. Thanks. :)Ladsgroup^overleg 02:59, 14 December 2016 (UTC)

Done Legoktm (talk) 07:57, 14 December 2016 (UTC)

RfC to regularise spacing between paragraphs on talk pages

There is a clear consensus for the proposal, which was implemented here. Cunard (talk) 05:09, 19 December 2016 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I propose we modify Common.css to make the spacing between paragraphs on talk pages the same for indented posts as it is between unindented posts. --RexxS (talk) 22:49, 16 November 2016 (UTC)

Background

Rather than wait for a solution that might never materialise, I'd like to see us do something about a perennial problem on talk pages.

It is obvious at present that the spacing between paragraphs in an unindented post is different from that between "paragraphs" in an indented post.

You only have to look here.

And here to see what I mean.

Editors get into the bad habit of leaving a space between successive indented posts to improve the readbility of the thread.

Unfortunately, as anyone who reads WP:LISTGAP knows, that causes problems for screen readers.

Many of them will tell the listener that a nested set of description lists has been closed and a new nested set of description lists has been opened.

That's not ideal, so we need the ability to let pseudo-paragraphs in indented posts stand out a little more, while not closing the nested lists for a screen reader. Let's say we want them to stand out to the same extent as normal unindented paragraphs do. I tried the following in Special:MyPage/common.css:

.ns-talk .mw-body-content dd {margin-top:0.4em; margin-bottom:0.4em;}

Now I see each paragraph on talk pages with the same spacing whether it's indented or not. That works well to my eyes - after just a couple of minutes the talk pages now look "natural" - so much so that I didn't feel the need to tinker further by adding extra space between each person's post (just increase the margin-top for .ns-talk .mw-body-content dl).

What do others feel? Would this be a sensible improvement for both regular readers and those using screen readers?

May I suggest that threaded discussion takes place in the Discussion section, not the !votes sections, please? --RexxS (talk) 22:52, 16 November 2016 (UTC)

Support

Support as proposer
Strong Support per nom. I was originally fixing these LISTGAP issues myself, but stopped after people complained on my talk page that I was editing others' posts. (However, this will do nothing to stop the * -> :: issue that was more common). Ppp ery 23:02, 16 November 2016 (UTC)
Support We need experience from trying this to determine whether there would be any unwanted side-effects, but there is a problem as others have "fixed" my correct indentation because of the lack of vertical spacing. Johnuniq (talk) 02:47, 17 November 2016 (UTC)
Support, per excellent reasoning by the proposer and my previous support of this idea. Enterprisey (talk!) 04:43, 17 November 2016 (UTC)
Support. A good idea can often justify itself. Best regards, Codename Lisa (talk) 07:05, 17 November 2016 (UTC)
Support Seems like a good idea —TheDJ (talk • contribs) 09:19, 17 November 2016 (UTC)
Support Oh man, that spacing has always annoyed the heck out of me. Please make it happen! --SubSeven (talk) 19:13, 17 November 2016 (UTC)
Support There are various other spacing issues to fix, too, such as ordered and unordered lists having uneven indentation. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 20:02, 18 November 2016 (UTC)
Support: I like this idea to make the spacing regularized. —MRD2014 (talk • contribs) 16:18, 20 November 2016 (UTC)
Support: I was worried there'd be some negative side-effects, but I tested the code and the result looks fine to my eyes. This is a problem that should have been fixed years ago. — Eru·tuon 17:28, 20 November 2016 (UTC)
Support per above. --TerraCodes ^{(talk to me)} 09:00, 27 November 2016 (UTC)

Oppose

Discussion

Text in one paragraph.

Text in the next paragraph, with two line breaks above it.

versus

Text in one paragraph.

Text in the next paragraph, with only one line break above it.

I like the goal of the proposed code; it's a problem that I've noticed. But before supporting it, I have to ask: does this CSS code cause bad display for paragraphs indented with : that have two newlines between them? I mean, would it make the two examples in the box above be separated by different amounts of vertical space, with the example with two line breaks having more vertical space between the two lines than the one with one line break? I think ideally it should make them look the same. That way existing talk pages won't be messed up too much. Then again, maybe this is impossible. — Eru·tuon 03:11, 17 November 2016 (UTC)

Or, perhaps the goal should not be to have them look the same, but just that the one with two line breaks not have so much vertical space that it's ugly (though that's an aesthetic judgement and it may be difficult to define). — Eru·tuon 03:16, 17 November 2016 (UTC)

@Erutuon: You shouldn't be using two line breaks, that flies against WP:INDENTGAP. What RexxS is proposing will help to discourage multiple line breaks. --Redrose64 (talk) 13:48, 17 November 2016 (UTC)

@Redrose64: Very well, I shouldn't and other people shouldn't be using two line breaks, but I'm sure they do sometimes. Should the CSS account for that or not? — Eru·tuon 15:28, 17 November 2016 (UTC)

One other possibility would be to also add something like:

.ns-talk .mw-body-content dl {margin-top:0.6em;}

which would increase the vertical spacing between different editors' comments, not the paragraphs. You can try it out in your own Special:MyPage/common.css and tweak it to see the effect (or just keep it if you like it enough). --RexxS (talk) 18:29, 17 November 2016 (UTC)

If someone turns this into a gadget, before trying to add it to Common.css, then it would be a lot easier for people to test out the effects and judge it the proposal —TheDJ (talk • contribs) 09:16, 17 November 2016 (UTC)

I added the CSS code to my user style, and the vertical space difference isn't noticeable in my browser at least. — Eru·tuon 17:27, 20 November 2016 (UTC)

You all know that the official semantics of :-indented text and of the html that it generates is not actually "indented paragraph", right? It is the value / definition data part of a definition list. Is the proposed wider spacing also appropriate for that meaning? —David Eppstein (talk) 05:27, 26 November 2016 (UTC)

I assume you know, then, that the mechanism of using <dd>...</dd> to create visual indenting dates back well before the 2001 suggestion of a "semantic web"? This particular bad idea was adopted by the MediaWiki software as a convenient means of visualising threaded discussions, and will require a large effort to bring into line with W3C recommendations. However, this suggestion does not seek to redress that problem: its more modest intent is to help sighted readers see indented "paragraphs" in the same way as they see unindented paragraphs, in an effort to reduce the temptation for editors to leave extra blank lines between posts (which causes an accessibility issue described at WP:LISTGAP). --RexxS (talk) 17:17, 26 November 2016 (UTC)

Edit request

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Following the above discussion, I think consensus is clear that making the spacing between indented talk page "paragraphs" (i.e. <dd>...</dd>) and unindented paragraphs (i.e. ...) is visually desirable, and may help reduce the temptation for editors to artificially inflate the spacing of indented paragraphs by leaving blank lines which causes inconvenience for users employing assistive technology. Please add the following:

.ns-talk .mw-body-content dd {margin-top:0.4em; margin-bottom:0.4em;}

This will specifically affect only the spacing between indented paragraphs on talk pages. --RexxS (talk) 23:21, 16 December 2016 (UTC)

Done — Martin (MSGJ · talk) 22:00, 17 December 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What? No one is here to complain? In fact no one seems to have even noticed so I judge this to be resounding success. If only all proposals went through so smoothly ... — Martin (MSGJ · talk) 11:25, 22 December 2016 (UTC)

Remove PDFlink CSS

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The PDFlink class is no longer added anywhere by any templates or modules, nor was it ever added by the default implementation of Mediawiki. As such, we should delete the below CSS block.

 /* Change the external link icon to an Adobe icon anywhere the PDFlink class
    is used (notably Template:PDFlink). This works in IE, unlike the above. */
 div#content span.PDFlink a,
 div#mw_content span.PDFlink a {
     background: url("//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif") no-repeat right;
     /* @noflip */
     padding-right: 18px;
 }

--Izno (talk) 03:04, 1 January 2017 (UTC)

Done — Mr. Stradivarius ^{♪ talk ♪} 14:39, 1 January 2017 (UTC)

Add background color when editing old revisions and match warning

As previously noted, users sometimes edit an old revision thinking it's the current revision. The mediawiki:editingold warning can be missed, especially on protected pages where there is another warning (see e.g. here). I suggest adding a background color, in a light shade of yellow. This is to differentiate it from the pink background of fully/TE protected pages. And to make the editingold warning match, it would be displayed in yellow. So this would add:

#editingold {
 border: 1px solid #665600;  /* Dark gold */
 background-color: #FFD700; /* Gold */
}
.mw-textarea-oldrev,
.mw-textarea-oldrev + .ui-resizable .ace_content {
  background-color: #FFEF99; /* Light gold */
}

Cenarium (talk) 12:15, 14 January 2017 (UTC)

I'm not entirely certain that we should need to have a different color from a fully/TE protected page. --Izno (talk) 17:11, 14 January 2017 (UTC)

Then admins/TE editors wouldn't be alerted when editing old revisions of a fully/TE protected page. And they may think when editing an old revision of a non-protected page that it just is protected, rather than an old revision. Cenarium (talk) 01:33, 23 January 2017 (UTC)

We have a secondary indicator, which is the bar at the top of the page that says "you're editing old stuff". I don't see how missing it requires us to provide a different color for the edit box. "red" would be sufficient to indicate "hey, are you sure you're editing the page you need to?" --Izno (talk) 11:46, 23 January 2017 (UTC)

I seriously doubt your average Joe who missed the notification among the edit notices, will be able to infer that 'gold background' has any meaning whatsoever. I would suggest making less use of edit notices with 'helpful' advice that people don't read instead. It's a wiki, it's editable and people make mistakes and other people have to correct them. I don't get people's obsession with trying to perfect the behaviour of humans along rigid lines in an open system. That's not the wiki idea. Let's all do a little bit less of cat herding and a little bit more article writing. :) —TheDJ (talk • contribs) 14:54, 23 January 2017 (UTC)

Hi TheDJ. I somewhat agree with what you're saying generally, but in this specific case, I think it's more "why are local CSS hacks needed if there's a real problem in MediaWiki core with users editing old revisions?" I think with most of the local styling in MediaWiki:Common.css, we need to be asking ourselves: is this something that every wiki would experience? If so, the fix likely belongs elsewhere, in my opinion.

I filed phabricator:T160216 about potentially making the user interface clearer when looking at old revisions. Any suggestions from you or Cenarium or Izno or anyone else would be welcome, of course. While I agree with you that we should not expect perfect behavior from users, I think if we see a trend of users making mistaken edits, we need to examine our workflows and try to mitigate against it if possible and reasonable to do so. --MZMcBride (talk) 00:16, 11 March 2017 (UTC)

"Markup" is a noun

The top comment in the code uses "markup" wrongly as a verb (which would imply "markupped" and "markupping"!). It should have a space. Equinox ◑ 19:51, 22 February 2017 (UTC)

This is not a hill to die on. :) --Izno (talk) 20:22, 23 February 2017 (UTC)

Hi Equinox. I'm not sure what you're referring to. The top code comment of the current version of MediaWiki:Common.css that I see is "/* Reset italic styling set by user agent */". Where are you seeing the text "markup"? --MZMcBride (talk) 00:21, 11 March 2017 (UTC)

Seven css talk pages redirect here. Based on a search I guess it's about MediaWiki:Mobile.css. PrimeHunter (talk) 00:41, 11 March 2017 (UTC)

Protected edit request on 13 March 2017

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please remove lines 345, 360–364 and 372–374. {{Navbox}} automatically adds its own header padding now, so the CSS is not required. Thanks, Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:23, 13 March 2017 (UTC)

Question: To save me counting the lines by hand, which specific rules should be removed? Also, I see no recent changes to {{navbox}}, so where has this been discussed, tested and agreed? --Redrose64 🌹 (talk) 14:30, 13 March 2017 (UTC)

@Redrose64: Module:Navbox has been updated per talk page discussion. I used the line numbers for convenience for those using the newer code editor, but the code to be removed is highlighted below. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:00, 13 March 2017 (UTC)

Code snippets

.navbox-title .navbar {
    /* @noflip */
    float: left;
    /* @noflip */
    text-align: left;
    /* @noflip */
    margin-right: 0.5em;
    width: 6em;
}

/* In navboxes, the show/hide button balances the v·d·e links
   from [[Template:Navbar]], so they need to be the same width. */
.navbox .collapseButton {
    width: 6em;
}

.navbox .mw-collapsible-toggle {
    width: 6em;
}

One declaration and two rules each containing one declaration; OK,

Done with this edit. --Redrose64 🌹 (talk) 16:58, 13 March 2017 (UTC)

Protected edit request on 11 April 2017

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

In light of https://phabricator.wikimedia.org/T155863, the instances of .mw-body here should be .mw-body-content

.mw-body-content sub,
.mw-body-content sup,
span.reference /* for Parsoid */ {
    font-size: 80%;
}

Arlolra (talk) 19:29, 11 April 2017 (UTC)

Done Go Sharks! Legoktm (talk) 22:30, 13 April 2017 (UTC)

Edit Request March 25, 2016

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could MediaWiki:Gadget-WatchlistBase.css please be merged into the site CSS because the gadget says "This loads the base style for the watchlist. Please do not disable this option." If people shouldn't disable it then why make it a gadget that can be disabled? --TerraCodes ^{(talk to me)} 08:43, 25 March 2017 (UTC)

Have you discussed this anywhere? If not, suggest running it past WP:VPT first — Martin (MSGJ · talk) 10:06, 25 March 2017 (UTC)

Why not just mark it as a hidden gadget. That's an option now :) —TheDJ (talk • contribs) 12:13, 25 March 2017 (UTC)

I was recently surprised by this gadget preferences line too, it really adds clutter and confusion. See notably Wikipedia:Village pump (technical)/Archive 139#Watchlist button "Mark all as visited" missing.

I thought about using default|hidden, but if for any reason the user had disabled it, I suppose they wouldn't have any way to re-enable it? (apart from preferences full-reset)

Also I would be interested in knowing more about the supposedly unsupported "site" dependency. I just found phab:T147755, but it's about mobile version.

Od1n (talk) 06:28, 11 April 2017 (UTC)

I have disabled this because there doesn't seem to be a specific consensus-backed request yet. — Martin (MSGJ · talk) 07:32, 20 April 2017 (UTC)

Harvard references in mobile.css

I've noticed that the mobile CSS appears to lack the following code:

/* Highlight linked elements (such as clicked references) in blue */
body.action-info .mw-body-content :target,
.citation:target {
    background-color: #DEF;  /* Fallback */
    background-color: rgba(0, 127, 255, 0.133);
}

This prevents Harvard and other references from being highlighted when the respective author–date citation is clicked (desktop, mobile). Is this deliberate or could the references also be highlighted when clicked on the mobile website? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:02, 27 April 2017 (UTC)

References with hanging indentation

Even though this is a relative uncommon usecase to add to the sitewide styling, I'm proposing to do so, because the current implementation is causing an accessibility problem as well. Feedback welcome —TheDJ (talk • contribs) 12:10, 4 May 2017 (UTC)

Protected edit request on 4 May 2017

Tracked in Phabricator
Task T164493

This edit request to MediaWiki:Mobile.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could the below code be added to the Mobile CSS between lines 51 and 52?

/* Highlight linked elements (such as clicked references) in blue */
body.action-info .mw-body-content :target,
.citation:target {
    background-color: #DEF;  /* Fallback */
    background-color: rgba(0, 127, 255, 0.133);
}

This allows Harvard references to be highlighted in pale blue when their corresponding citation links are clicked or pressed. It seems to be missing for no apparent reason. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:40, 4 May 2017 (UTC)

@Jc86035: that's not the style that Mobile uses for this. On mobile, clicking/tapping a reference should bring up a 'toast'/pop-up notification at the bottom of the screen encapsulating the reference. If that doesn't work for harvard references, than we should investigate that and see if we can improve this I think. —TheDJ (talk • contribs) 14:00, 4 May 2017 (UTC)

@TheDJ: Harvard references are currently just section links (example source: [[#CITEREFSmith2005|Smith 2005]], p. 25). I suppose it might have something to do with phab:T154861 but there's no pop-up; they just act like normal anchors. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:11, 4 May 2017 (UTC)

Yes, and this is my concern. Sure, we can add this highlight, but it will create a disjunct in the experience. If we do do this, then I think that we should pick a color from the minerva color palette, and then maybe do a CSS animation where the target is just temporarily highlighted or something, that seems like it would be more in line with the expectations of the mobile platform. —TheDJ (talk • contribs) 14:23, 4 May 2017 (UTC)

A rule that can be simplified a bit

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Since this change in the Cite extension: « Don't allow a reference that includes a group name to break in the end of the line »,

Rule #4 in this block can be removed:

/* Prevent line breaks in silly places:
   1) Where desired
   2) Links when we don't want them to
   3) Bold "links" to the page itself
   4) Ref tags with group names <ref group="Note"> --> "[Note 1]" */
.nowrap,
.nowraplinks a,
.nowraplinks .selflink,
sup.reference a {
    white-space: nowrap;
}

So it would become:

/* Prevent line breaks in silly places:
   1) Where desired
   2) Links when we don't want them to
   3) Bold "links" to the page itself */
.nowrap,
.nowraplinks a,
.nowraplinks .selflink {
    white-space: nowrap;
}

Could a sysop apply this change?

Od1n (talk) 22:25, 5 June 2017 (UTC)

@Od1n: You use strange terminology. What you refer to as a "block" is properly termed a rule, and what you refer to as a "rule" is properly termed a selector. See the CSS 2.1 spec, section 4.1.7 and section 5.2.1. --Redrose64 🌹 (talk) 08:44, 6 June 2017 (UTC)

Actually I had read this article on MDN a bit before. I guess I just fell back into some deep-rooted bad habits. Od1n (talk) 11:01, 6 June 2017 (UTC)

Done. If you find more of these, please do report them, it's hard to keep track of them and sometimes we miss some of these. —TheDJ (talk • contribs) 09:47, 6 June 2017 (UTC)

Mw-collapsible change

@TheDJ: Your mw-collapsible change had a unanticipated (and IMO negative) impact on enhanced recent changes/watchlist. Could you please make the appropriate fix? I believe you may have been targeting the general case. --Izno (talk) 12:32, 13 June 2017 (UTC)

Can you be more specific than "unanticipated impact" ? —TheDJ (talk • contribs) 13:28, 13 June 2017 (UTC)

Adding the padding caused any page with multiple changes to get padding as well on enhanced RC/WL on the line of the page. It causes the entire line to be indented, creating a non-uniform look in the watchlist. --Izno (talk) 13:30, 13 June 2017 (UTC)

K, lemme figure out something more sustainable. —TheDJ (talk • contribs) 07:30, 14 June 2017 (UTC)

@Izno: dealt with. —TheDJ (talk • contribs) 07:53, 14 June 2017 (UTC)

previewonly class

English Wiktionary has a previewonly class to make content display only in preview mode. It is used, for instance, for messages regarding missing template parameters. (For an example, see wikt:Template:grc-IPA.) This would probably be useful on Wikipedia too. Here's the code that it uses.

.previewonly { display: none; }

#wikiPreview .previewonly { display: inline; }

There is a workaround for making content display only in preview mode: checking to see if the magic word {{REVISIONID}} generates any text. But it would be much easier to simply use a class. Are there any objections? (Has this been considered before?) — Eru·tuon 21:25, 19 June 2017 (UTC)

It has not been considered before as far as I know. I have no objections, and I think that it could solve some problems that have been identified before with the REVISIONID workaround. —TheDJ (talk • contribs) 23:20, 19 June 2017 (UTC)

The evil !important shouldn't be needed, as the more specific selector should always take precedence. Murph9000 (talk) 23:28, 19 June 2017 (UTC)

The style rule was added by Msh210, if he wants to comment. I agree, it should work without !important. — Eru·tuon 05:42, 20 June 2017 (UTC)

The biggest reason we so far have used REVISIONID, is because it does not end up in the actual final HTML when saved, unlike classes like these. While visually hidden, these blobs tend to show up in search engines etc. But REVISIONID trick is not compatible with parsoid, and this can at least be made compatible with parsoid.. I guess both approaches have their problems... —TheDJ (talk • contribs) 14:09, 20 June 2017 (UTC)

Thanks for the ping, Eru·tuon.

I don't recall why I used !important. Likely it's because I wasn't well enough versed in CSS's precedence rules.

I believe that hiding things from a page using display:none is rarely the way to go, since it doesn't (AFAIK) hide things from screenreaders, search engines, and even still a few visual browsers. I seem to think I have maintained that view for a very long time, so am mildly surprised that I added that code in in 2010. Perhaps I had some good reason; I don't know; I don't see anything about in the revision history of my talk page or the archives of Grease pit from that time.

I won't be looking for replies here, so ping me again as needed, please.—msh210℠ 20:03, 24 June 2017 (UTC)

Personally, I don't much like "only in preview mode" things in general. As long as this is limited to actual errors in the page as saved (versus random instructions for editors), though, I don't oppose it. I note that as proposed it won't work in VE, which people should be aware of before making this decision. Anomie ⚔ 12:11, 20 June 2017 (UTC)

Hlists

If anyone cares to do something about it, I've filed two bugs related to the hlist and hlist-separated classes in mobile view. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:32, 2 July 2017 (UTC)

CSS border instead of gutter rows on navboxes

I've proposed at Template talk:Navbox#Border-spacing instead of gutter rows removing the gutter rows from Module:Navbox (sandbox diff), and adding CSS borders in their place at MediaWiki:Common.css (user CSS diff). Looks okay in Firefox, Chrome, IE7 and 8, but if anyone spots a problem please let me know! Matt Fitzpatrick (talk) 06:43, 27 May 2017 (UTC)

How does this play with subgroups, images, columns, groupless rows, and a mix of the above? --Izno (talk) 18:35, 27 May 2017 (UTC)

Good thing I double checked! I thought the CSS worked with all of the Template:Navbox/testcases — but there was one difference I missed. I added more selectors to cover the "border = none" case (new CSS diff). That case renders a .navbox-subgroup without a containing .navbox. All the testcases look okay now. Matt Fitzpatrick (talk) 04:04, 28 May 2017 (UTC)

And good thing I asked. ;) --Izno (talk) 21:17, 29 May 2017 (UTC)

No objection from me (encouragement even). However these two changes will have to be deployed at the exact same time... and even then caching of the pages and jobqueue will likely keep those extra tr's in anonymous content for a while. I suggest prefixing the new css rules with a temporary classname before adding to common.css. Then adding the new classname to the navbox module, wait for everything to settle, then removing the classname from common.css and finally removing the classname from the html again. —TheDJ (talk • contribs) 21:45, 29 May 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please sync from this user CSS (diff). Per TheDJ's caching trick, added a temporary navbox-spacing-temp class, so changes won't be immediately visible. Matt Fitzpatrick (talk) 15:14, 1 June 2017 (UTC)

done —TheDJ (talk • contribs) 15:20, 1 June 2017 (UTC)

Hi Matt Fitzpatrick. How long is the .navbox-spacing-temp hack intended to be deployed? I just discovered this new CSS class while investigating a thin white bar that started to appear in the infobox used in articles such as Kingsland v. Dorsey (the "Court membership" infobox section somewhat weirdly uses class="navbox"). This -temp CSS class appears to be responsible for the extra white bar. --MZMcBride (talk) 02:42, 5 June 2017 (UTC)

@MZMcBride: Wow, navboxes turn up in the most unexpected places! I tried editing Template:Infobox SCOTUS case/courts to not be a navbox (diff). Will that work? Matt Fitzpatrick (talk) 03:24, 5 June 2017 (UTC)

Works for me, thanks! --MZMcBride (talk) 04:51, 5 June 2017 (UTC)

@Matt Fitzpatrick: Will templates using the navbox class but not {{Navbox}} be affected by this? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:44, 5 June 2017 (UTC)

@Jc86035: Hm, I didn't think of that. If it's a table with two or more rows, yes. I'll start a list of templates using navbox class in ~~my sandbox~~. Looks like there's a lot of them. Matt Fitzpatrick (talk) 11:50, 5 June 2017 (UTC)

I finished that list of templates using navbox class. (Edited above reply to unlink my sandbox, it's no longer there). Matt Fitzpatrick (talk) 05:14, 7 June 2017 (UTC)

This change is causing problems with succession boxes that are wrapped in {{navboxes}}, see Template talk:Navboxes#Succession boxes: incorrect border. --Redrose64 🌹 (talk) 08:32, 6 June 2017 (UTC)

Why is that even a use case ? Is this abusing the collapsibility of navbox just to hide succession boxes ? That's just... yuck... —TheDJ (talk • contribs) 09:56, 6 June 2017 (UTC)

I don't know, I never do it. I posted here because I was sent there by this note. --Redrose64 🌹 (talk) 10:19, 6 June 2017 (UTC)

The gutterless navbox is still working its way through the cache, but different selectors might work better. When it's time to remove .navbox-spacing-temp, maybe replace the rule with this one? Should be a bit faster for browsers, and not apply to nested tables. Matt Fitzpatrick (talk) 04:00, 7 June 2017 (UTC)

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The above problems are a result of the selectors I wrote hitting tables nested inside navboxes. I went back to the drawing board and think I have a fix. Syncing from this user CSS (diff) keeps the .navbox-spacing-temp mask for now, should fix the problem of borders on nested tables, and should improve browser performance too. Matt Fitzpatrick (talk) 23:30, 7 June 2017 (UTC)

@Matt Fitzpatrick: Not sure if related to the above, but the testcases is displaying all wonky again with irregular row heights. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:37, 15 June 2017 (UTC)

Template:Navbox/testcases? It looks okay to me in Chrome logged in and Firefox logged out. Should I be looking at another browser or testcases page? Matt Fitzpatrick (talk) 20:26, 15 June 2017 (UTC)

@Matt Fitzpatrick: See "Subgroup without all Groups Test" (some of the rows are narrower than the others). I don't have any user CSS enabled. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:28, 16 June 2017 (UTC)

@Jc86035: OK, took a look at it. Group cells have top and bottom padding that list cells do not. So a list cell by itself gets less height than a list cell in the same row as a (padded) group cell. This might be intentional. In the sandbox, I added top and bottom padding to all list cells to match group cells, and that broke other things. Matt Fitzpatrick (talk) 05:46, 16 June 2017 (UTC)

@Matt Fitzpatrick: I think they're supposed to have the same minimum height (see the eswiki version, which uses an older fork of the module). Would fixing this require more CSS? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 05:57, 16 June 2017 (UTC)

@Jc86035: On eswiki, the list cell has line-height increased to 1.8, so it's only 2 pixels shorter without a padded group cell. I put the same thing in the sandbox here, and it looks OK, though it visibly increases height at "Simple List Only Test" and on any list that wraps to multiple lines. Matt Fitzpatrick (talk) 06:47, 16 June 2017 (UTC)

@Matt Fitzpatrick: Never mind. It looks like there's a CSS rule which adds padding for hlists (line 318, "Adjust hlist padding in navboxes"), so most navboxes shouldn't be affected. On the other hand, some of the navboxes in the testcases don't have the hlist class or list items, so the padding isn't added. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:59, 16 June 2017 (UTC)

Done. —TheDJ (talk • contribs) 08:28, 16 June 2017 (UTC)

It's been 30 days (maximum cache time) since this change was implemented at Module:Navbox. It should now be safe to remove the ".navbox-spacing-temp" masks from the selectors. Matt Fitzpatrick (talk) 04:58, 8 July 2017 (UTC)

done —TheDJ (talk • contribs) 08:02, 8 July 2017 (UTC)

tr + tr > .navbox-abovebelow,
tr + tr > .navbox-group,
tr + tr > .navbox-image,
tr + tr > .navbox-list {    /* Borders above 2nd, 3rd, etc. rows */
    border-top: 2px solid #fdfdfd; /* Must match background color */
}

If you get a chance, could you edit the four selectors as above (deleting the .navbox parents)? With border = none, the module omits the navbox class as a trick to go borderless, for instance Template:Navbox/testcases#Additional tests. In the borderless, no navbox class case, there were still gutter rows to be replaced with this CSS. Matt Fitzpatrick (talk) 07:53, 12 July 2017 (UTC)

Matt Fitzpatrick, done —TheDJ (talk • contribs) 08:19, 12 July 2017 (UTC)

Protected edit request on 8 August 2017

This edit request to MediaWiki:Print.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please remove !important from the padding: 2px 5px !important; declaration for .infobox td and .infobox th (on line 74 of MediaWiki:Print.css). This is causing rendering problems in {{Routemap}} and {{BS-map}} in printable mode. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:19, 8 August 2017 (UTC)

Question: Why was it put there and could removing it have any other consequences? — Martin (MSGJ · talk) 14:01, 8 August 2017 (UTC)

@MSGJ: It was added by Jon (WMF) at the end of July, along with other infobox rules, probably as part of this. I don't think it would have other consequences, since !important isn't used in the normal stylesheet for infobox formatting, so this would just mimic the regular formatting better. I think some of the other !importants could be removed as well, as they're seldom used in Common.css so they shouldn't be necessary. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:35, 8 August 2017 (UTC)

The !important annotation is a cop-out: it's basically saying, "I can't get this rule to stick, so I'll knock down all the other rules". In most cases, it's better (although probably not as easy) to increase the specificity of the selector. --Redrose64 🌹 (talk) 21:01, 8 August 2017 (UTC)

Done although it was line 81 not 74 I think — Martin (MSGJ · talk) 08:06, 9 August 2017 (UTC)

This seems dangerous to begin with. I made sure it only affects direct children, seems more sustainable. —TheDJ (talk • contribs) 15:09, 9 August 2017 (UTC)

Protected edit request on 13 August 2017

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

For some reason, small amboxes don't have a border, making them seem to blend into the article. Please fix this. Thank you. jd22292 (Jalen D. Folf) (talk) 20:58, 13 August 2017 (UTC)

@Jd22292: They show for me, in both Chrome, Firefox and Opera, on pages like 0s BC#5 BC; Florida State Road A1A#Palm Beach County; 2nd Brigade Combat Team, 1st Armored Division (United States)#See also and others in Category:Articles using small message boxes. Which browser are you using, which pages do you see the problem on? --Redrose64 🌹 (talk) 08:21, 14 August 2017 (UTC)

@Redrose64: Hi. I checked the same links you provided me, and only the top border shows for me. Only the right and bottom border don't show (I could care less about the left border for the obvious reason.) I am currently running Google Chrome. jd22292 (Jalen D. Folf) (talk) 18:11, 14 August 2017 (UTC)

Is your browser zoom level set to 100%? Use Ctrl+0 to return to 100% from whatever setting you currently have. Sometimes, zooming out can cause a thin line to become narrower than one screen pixel, hence it doesn't show. As for the left border, that should always be visible - it's 10px wide and this colour. --Redrose64 🌹 (talk) 23:07, 14 August 2017 (UTC)

Thanks. It might just be my PC then. Sorry for the trouble. jd22292 (Jalen D. Folf) (talk) 23:14, 14 August 2017 (UTC)

support for IE

We can make  work in IE11 and other non-HTML5 compliant browsers by adding this:

wbr:after { content: "\00200B"; }

It adds a zero-width space ( / ) after every , which effectively achieves the same thing as the .

Right now there's only 203 cases of  in the mainspace.

However this would mean  could replace all of the following:

The issue I want to address is that those 203 cases of  aren't doing what they're intended to on IE11, which is still widely used. In the template {{wbr}}, the  is redundant to the zero-width space which works in all browsers since it hasn't been deprecated. So, unless I'm missing some difference in their behaviour, {{wbr}} and {{zwsp}} do the exact same thing and should be merged. While  and  are unreadable to most editors.

 is the nicest solution which is why I think adding a style rule to make it backwards compatible would be favourable to replacing all instances of it with a template or non-comprehensible unicode.

Rob984 (talk) 14:36, 17 August 2017 (UTC)

@Rob984: do we have any available documentation that shows that this will not negatively effect other browsers ? —TheDJ (talk • contribs) 02:07, 19 August 2017 (UTC)

Math-tags formatting

I have noticed that the common.css contains contains the lines

.mwe-math-mathml-display math {
    display: inline;
}

I would be very happy if someone could explain to me what this actually means. My first interpretation was that it sets the "default" math tags to display="inline" for MathML-capable browsers, but this does not seem to be the case for me. I am asking because I am currently preparing a survey in the German Wikipedia regarding the math formatting and it would be interesting to know what this is good for. Also any relevant discussions about this or future plans here would be very interesting.--Debenben (talk) 08:11, 28 August 2017 (UTC)

The rule was added almost two years ago by Salix alba (talk · contribs), following their suggestion at WikiProject Mathematics. --Redrose64 🌹 (talk) 12:08, 28 August 2017 (UTC)

That is strange. I had a look at Wikipedia:VisualEditor/Feedback/Archive_2015_3#Indentation_for_mathematical_equations where it was first discussed, but those lines are missing. In phab:T111712 they are not explicitly discussed and for me they do not seem to have any effect.--Debenben (talk) 12:55, 28 August 2017 (UTC)

<-- Here's the left margin. Display in-line as default ${\frac {v_{o}}{a_{e}*l_{o}}}$ comments added.

<-- Here's the left margin. Display block ${\frac {v_{o}}{a_{e}*l_{o}}}$ comments added.

If you inspect those two examples, you'll see the difference between the intended block and inline displays. However, in the second case, you'll also see that the class "mwe-math-mathml-display" applies to a div which does not display and carries the "MathML" for the formula. The div "lives" inside the left-margin of the fallback image. That div has to be inline as does the <math>...</math> that is inside it: hence the "display:inline;" which applies to the 'math' element that you're wondering about. If you are seeing the fallback image, then the div containing the MathML is no more than 1px x 1 px, so having it display block would make virtually no visible difference on your screen. That's probably why you feel it has no effect. I suspect it would have a more noticeable effect if your browser were natively dealing with the MathML, but I could be wrong on that. --RexxS (talk) 16:16, 28 August 2017 (UTC)

Lets see If I can remember what happens.

The default method most editors on most wikis use to produce display maths is to have colon followed by a maths tag.

:<math>a x^2 + b x + c</math>

This is bad markup as it abuses the list indent syntax. There is an option on the math tag to have a display="block" option.

<math display="block">a x^2 + b x + c</math>

This is how VE produces display maths. Ideally, both versions should appear the same as pages are likely to mix the two syntaxes. If the rendering happens with the fallback SVG images then all is good However if MathML is enabled you get something like

Diference in appearance of two display maths methods

Now the reason you don't see anything even in firefox is due to a change discussed at Help talk:Displaying a formula#MathML broken again?. Essentially the MathML display is turned off for firefox, and maybe other clients which can handle the mathml. You can turn the MathML display back on with some CSS. If you do that and remove the .mwe-math-mathml-display math { display: inline; } rule then the VE produced display equations appear center aligned, clashing badly with indented left aligned formula produced by :<math> .

Having the rule in place is not ideal either as it renders the maths as if it was inline producing rather cramped formula which do not match the size of other display math formula on the page. But it is all as bit moot as its hard to actually make the MathML display at all.--Salix alba (talk): 17:06, 28 August 2017 (UTC)

Thank you both for the detailed explaination. The part above the cited code that sets the margins for <math display="block"> displaying it like :<math> I understood. That part is already included in the survey as a suggestion. The .mwe-math-mathml-display math { display: inline; } part I still don't get. If I inspect the elements above I can see the div with the "mwe-math-mathml-display" class living inside the left-margin of the fallback image - that far I can follow. "The diff has to be inline..." why and what does this mean? The way I tried to see an effect was by writing block instead of inline into my custom css and then using the MathML-plugin for firefox to try and spot any difference in behaviour.

And while we are at it: Since using display="inline" for every inline equation can make the source code hard to read, one suggestion in the survey is to make <math> without parameters to be inline and use \textstyle by default. Could something like this be done by changing the CSS in the German Wikipedia?--Debenben (talk) 20:38, 28 August 2017 (UTC)

I just tried the same on my home computer now and got the block equation with MathML being center aligned - I guess that answers the question. Very strange, I must have done something wrong before. I can let you know if I can reproduce it on the other computer next week.--Debenben (talk) 20:58, 28 August 2017 (UTC)

toptextcells

This edit request to MediaWiki:Common.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add:

.toptextcells td,
.toptextcells th {
    vertical-align: top;
}

WP:HTML5 states deprecated HTML valign="top" should be replaced with class="toptextcells", but it's not defined anywhere. Note that you can't just put style="vertical-align:top" to <table> because that would only modify the alignment of the table as a whole and doesn't apply to the content of each cell. Nardog (talk) 15:31, 8 August 2017 (UTC)

Woops. I might have replaced some valign="top" with the CSS style in the table rather than a particular cell. Does adding style="vertical-align: top;" to a table row also not apply it to the content of individual cells? — Eru·tuon 18:47, 8 August 2017 (UTC)

Let's try it:

One	Two Two	Three Three Three	Four Four Four Four	Five Five Five Five Five	Six Six Six Six Six Six	Seven Seven Seven Seven Seven Seven Seven
One	Two Two	Three Three Three	Four Four Four Four	Five Five Five Five Five	Six Six Six Six Six Six	Seven Seven Seven Seven Seven Seven Seven

This works in my browser (Opera 36). --Redrose64 🌹 (talk) 21:51, 8 August 2017 (UTC)

Yes, so .toptextcells tr { vertical-align: top; } would also work.

For the record, .toptextcells is probably an invention at German Wikipedia. Here's the first discussion on this very talk back from 2012. Dozens of articles already use it, sadly to no effect. Nardog (talk) 22:19, 8 August 2017 (UTC)

Neat. It works in my browser (Chrome) too. I could have done the same test.

I like the idea of having a class for this, but toptextcells seems an odd name: it doesn't immediately suggest to me what it does. But since it is already in use, it would be a bit of trouble to go around and change it. — Eru·tuon 01:55, 9 August 2017 (UTC)

Let's not add it here just because it's used in the wild with that name. --Izno (talk) 10:53, 9 August 2017 (UTC)

I was only talking about the question of name, not whether the class should exist. — Eru·tuon 17:33, 9 August 2017 (UTC)

I don't see a whole lot of value here. Where a row needs top-alignment, it's trivial to add it to each row. On top of which, the class isn't really semantic--all it is used for is the styling, rather than telling us something about the row. Why would I need or want top-alignment? I think we should remove the bad guidance at WP:HTML5 instead. --Izno (talk) 10:53, 9 August 2017 (UTC)

We will have TemplateStyles soon, so that we can just fix this for every template that wants it. I therefor don't think there is a good reason to add this to the Common.css right now. —TheDJ (talk • contribs) 14:54, 9 August 2017 (UTC)

I sort of see your point, but this isn't any different from .nowrap in terms of how little it does, is it? Nardog (talk) 14:55, 9 August 2017 (UTC)

Nowrap does carry a bit of semantic intent because we expect nowrap in a certain set of scenarios (namely, a number and a unit name, at the minimum). As a result, it's also got more application. --Izno (talk) 16:43, 9 August 2017 (UTC)

Not done: request disabled due to lack of consensus at this time — Martin (MSGJ · talk) 19:33, 30 August 2017 (UTC)

Protected edit request on 16 October 2017

This edit request to MediaWiki:Print.css has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Line 9 of Print.css appears to have an error. I believe it should have a comma on the end so that ".ns--1 .ambox" becomes ".ns--1 .ambox," --Prh47bridge (talk) 11:15, 16 October 2017 (UTC) Prh47bridge (talk) 11:15, 16 October 2017 (UTC)

Done Thank you. Alex Shih ^Talk 11:27, 16 October 2017 (UTC)

[1] {{BS-map}} (mentioned code is in {{BSrow}}), Routemap's older and non-module-dependent sibling, seems to have had this solved by using width: 0px on each row. (The code seems to have not been updated along with the CSS rules.) However, this doesn't work for Module:Routemap/sandbox, since in replicating the {{BStext}} series of templates (not in production version yet) the width of each row can't be hard-coded to the minimum, as all the text becomes squashed.

[2] A better solution to this would be, of course, to enable collapsibility, but that was probably a decision made for the benefit of mobile view in general to make it easier to use.

[a]

[b]

Solution for minor linking problem

Bullets not growing with lists

Merge declarations

The cite element needs to not auto-italicize any longer

Class boilerplate

More boxes hidden in mobile

Navbar update

Update some css

Class Unicode having side-effect

Double redirect warning

Print style header and footer

Plainrowheaders with centered text

.wikitable.borderless

Inline nested hatnotes

Responsive image positioning

Use grey text for section numbers in Table of Contents boxes

Navbox show/hide padding

Navbar VTE linebreak

Proposal to inline hatnote styles

Reducing the padding in the WikiEditor's dialog windows

Slightly reduce collapsed state reflow

flags in tables on mobile

Mobile version style

imagemap-inline class

updatedmarker needs important?

Protected edit request on 10 June 2016

Highlighting free to read external links in scholarly references

table.mbox-small edit request

Protected edit request on 13 July 2016

table.navbox to just .navbox

Tables in route diagram templates

Horizontal list templates that use commas?

Hide FlaggedRevs notice when stable version is synced

IPA class

Change CSS depending on Category

Empty list items aren't empty anymore

Regularise spacing between paragraphs on talk pages

Recent WMF Change

RfC for changing colors to align with Wikimedia UI

Request for editing Mediawiki:common.css

RfC to regularise spacing between paragraphs on talk pages

Background

Support

Oppose

Discussion

Edit request

Remove PDFlink CSS

Add background color when editing old revisions and match warning

"Markup" is a noun

Protected edit request on 13 March 2017

Protected edit request on 11 April 2017

Edit Request March 25, 2016

Harvard references in mobile.css

References with hanging indentation

Protected edit request on 4 May 2017

A rule that can be simplified a bit

Mw-collapsible change

previewonly class

Hlists

CSS border instead of gutter rows on navboxes

Protected edit request on 8 August 2017

Protected edit request on 13 August 2017

<wbr/> support for IE

Math-tags formatting

toptextcells

Protected edit request on 16 October 2017

The `cite` element needs to not auto-italicize any longer

Class `boilerplate`

Class `Unicode` having side-effect