MediaWiki talk:Common.css: Difference between revisions

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

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)

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)

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)

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)

.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:

Not to be confused with Foo. For other uses, see Bar.

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:

1. {{redirect|A|B|C|and|D|other uses|E}}
   "A" redirects here. For B, see C and D. For other uses, see E.
2. {{redirect4|A|B|C}}{{other uses|D}}
   Template:Redirect4

   For other uses, see D.

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:

1. Hatnotes are currently applied inconsistently, with some pages using manual :'' formatting, which is semantically bad and demonstrably causes bad behaviour in Hovercards via TextExtracts.
2. I want to fix inconsistent hatnotes with nice templated ones
3. 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.
4. 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.
5. Hatnote collections that use two or more templates currently cannot be displayed on a single line without CSS changes.
6. Templates exist for certain combinations of hatnotes, but not all of them.
7. The alternative, writing out the compound hatnote as manual wikitext into a {{hatnote}}, is not good for maintenance.
8. 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)

just realized that I am on wikipedia.org as opposed to mediawiki.org. Sorry!