MediaWiki talk:Common.css

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by George Orwell III (talk | contribs) at 07:50, 20 January 2016 (→‎Inline nested hatnotes: ce). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

That is LESS syntax, shich is not supported in site CSS (yet). -- [[User:Edokter]] {{talk}} 13:26, 27 September 2015 (UTC)[reply]
I used the old syntax. -- [[User:Edokter]] {{talk}} 13:39, 27 September 2015 (UTC)[reply]
@Paladox2017: What does e(...) do?
@Edokter: In this edit, what does the \9 do? --Redrose64 (talk) 18:10, 27 September 2015 (UTC)[reply]
@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)[reply]
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)[reply]

Class Unicode having side-effect

Update/preface: The problem below manifests (identically) in Chrome, Chromium, Opera, and Safari, and does not happen at all in Firefox (all on Mac; have not tested further)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  03:35, 19 October 2015 (UTC)[reply]

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

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 Supercalifragilistic​expialidocious Antidisestablishmentarianism
  • But not inside {{unicode}}: Pneumonoultramicroscopicsilicovolcanoconiosis

​Supercalifragilisticexpialidocious

​Antidisestablishmentarianism

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)[reply]

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 <span class="unicode">&thinsp;</span> to <span>&thinsp;</span>, still results in Chromium treating the thinsp as non-breaking. Matt Fitzpatrick (talk) 10:35, 20 October 2015 (UTC)[reply]
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)[reply]
Interesting. This will bear some deeper testing, as it may have some implications for various templates.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:15, 25 October 2015 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

Anyone ? Or shall I just flip the edit request button ? —TheDJ (talk • contribs) 14:21, 4 December 2015 (UTC)[reply]
Let me test it for a bit. -- [[User:Edokter]] {{talk}} 18:25, 4 December 2015 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
Made some adjustments and targeted only thumbs. Can you test this? -- [[User:Edokter]] {{talk}} 18:43, 5 December 2015 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

I think that is controlled by the printer driver or browser, not our print stylesheet. -- [[User:Edokter]] {{talk}} 15:37, 2 January 2016 (UTC)[reply]
Yes you can, I do it at meta:User:Redrose64/monobook.css --Redrose64 (talk) 21:11, 2 January 2016 (UTC)[reply]
I'm afraid that does not affect the header and footer as outlined by Mahmudmasri. -- [[User:Edokter]] {{talk}} 21:14, 2 January 2016 (UTC)[reply]
Thanks Edokter. You are right. --Mahmudmasri (talk) 13:08, 3 January 2016 (UTC)[reply]

.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)[reply]

Cell borders are basically required for accessibility. --Izno (talk) 12:24, 7 January 2016 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]

@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)[reply]
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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.css&oldid=700731007"