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 Xaosflux (talk | contribs) at 12:17, 14 February 2022 (→‎Interface-protected edit request on 14 February 2022: re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Orange bar of doom now peach bar of doom

Looks like a few months ago the new message alert for (desktop) IP editors was changed from this:

You have a new message from another user (last change).

to this:

You have a new message from another user (last change).

Should we restore the old behavior on enwiki? All it should take is: 

div.usermessage {
    background-color: #ffce7b;
    border: 1px solid #ffa500;
}

IMO the new color scheme blends in too much, at least on my screen (ancient ThinkPad). I'm not sure if this change needs a widely-attended discussion since we're just restoring old behavior that was changed without discussion, but I'll raise this on WP:VPT if needed. Suffusion of Yellow (talk) 23:25, 29 October 2021 (UTC)[reply]

I don't see a need to revert the colors whatsoever (this is bikeshedding), and am 100% not in favor of reverting in Common.css for it. This also matches the style guide so it makes it more consistent with the rest of the UI. Izno (talk) 23:38, 29 October 2021 (UTC)[reply]
Well, I was thinking of this in the context of WP:THEYCANTHEARYOU. For some reason, desktop (not just mobile) users sometimes seem oblivious to their talk pages, though I don't know if the color change has anything to do with it. I wouldn't consider it bikeshedding anymore than the color of a stop sign. "Ignoring" user talk page messages can get you blocked. And since over a year after I reported the issue, the WMF still hasn't implemented any kind of message at all for mobile users, I see an almost 0% chance of success getting that change reverted. Suffusion of Yellow (talk) 00:09, 30 October 2021 (UTC)[reply]
Yes, I personally thought this concern might be coming from a TCHY perspective. I'm just not convinced that this change (basically, background color only) has any effect on whether someone can hear you. The orangepeach banner is still just as disruptive in the general "hey there's something you need to care about, please look at me" perspective. (Unless we consider that no-one sees any banners.)
At the end of the day, you might sell me on the hypothesis "the present color in the WM style guide is not sufficiently disruptive to indicate an issue, non-critical (vice an issue, critical)" (see messages section of the style guide, linked in the patch), but that's a general issue that can/should be A/B tested, which we do not have the onwiki technology to assess anyway. I.e., if there's any reason to change it (to any other color), it should be tested by the WMF UI design team anyway.
All that said, this banner color no longer matches the color that registered users receive (which is much closer to the original orange at #fc3, matching the border of the peach version). So the change has introduced an inconsistency that should be corrected. Izno (talk) 02:16, 30 October 2021 (UTC)[reply]
Now that you say it, the .mw-echo-alert color (#fc3), is even better:
You have a new message from another user (last change).
Anything that's different from the other messages, and at least somewhat ugly, is fine by me. The point is that your beautifully designed mountain community, with everything from the houses to the ski shop signs to, yes, the bikesheds, in tasteful shades of green and brown, can't also have the "RAILROAD CROSSING AHEAD" signs in green and brown also. Suffusion of Yellow (talk) 03:04, 30 October 2021 (UTC)[reply]
" For some reason, desktop (not just mobile) users sometimes seem oblivious to their talk pages" It's because talk pages are a dumb concept that only exists in wikipedia :D —TheDJ (talk • contribs) 11:12, 2 November 2021 (UTC)[reply]
I agree with Izno on this, the new colors seem fine. Legoktm (talk) 00:54, 30 October 2021 (UTC)[reply]
Exactly, they seem fine to developers because they look nice. However, the intention is that users be required to at least view talk page messages. They can delete them or ignore them (possibly at their peril), but they need to see them. The change needs to be reverted even if a tedious RfC is required. Johnuniq (talk) 01:20, 30 October 2021 (UTC)[reply]
And they can still see them. As I said, I think changing the color back is bikeshedding, and there is a reason to have made the change in the first place. Izno (talk) 02:03, 30 October 2021 (UTC)[reply]
I'm not sure if you're referring to me when you mean "developers", but I don't think the new colors look nice, or at least that's not my motivation. Some people really like the orange, some people really don't (see T58845#4535499 and follow-ups). Part of the reason I use Timeless is because it hides the orange bar. I'm sure that even if the text was obnoxiously blinking, people would still not click on it. So you can count me as skeptical that the orange makes that much of a difference. Personally, I think if you really want people to read their talk page messages, use something like nerdalert. Legoktm (talk) 07:21, 30 October 2021 (UTC)[reply]
Johnuniq, could you clarify? You replied to "I agree with Izno on this" (User:Legoktm) saying "Exactly", then you follow up with "The change needs to be reverted" (i.e., use old color). To me, contradicting. -DePiep (talk) 15:51, 30 October 2021 (UTC)[reply]
  • Support using old color, or the "even better" #fc3. Especially per Suffusion of Yellow's "Anything that's different from the other messages, and at least somewhat ugly, is fine by me." The color needs to be vaguely disturbing, like baby vomit, not calming and yummy, like cotton candy. Mathglot (talk) 08:40, 30 October 2021 (UTC)[reply]
  • Support #fc3 per Mathglot. Do <blink> and <marquee> still work? Certes (talk) 17:03, 30 October 2021 (UTC)[reply]
  • Oppose, follow Izno. I am not a UI designer myself, but I can agree with their line. Also, I'm happy to have learned that modern UI is not about flashing around warnings. -DePiep (talk) 17:23, 30 October 2021 (UTC)[reply]
  • Weakly Oppose Changing the colour, as it would be an entirely pointless change that doesn't accomplish anything. The existing notice is extremely obvious when presented to IP editors and I don't see making the colour "ugly" making people more likely to read their talk page. Strongly Oppose making the text blink, scroll or animated, as such elements are difficult/obnoxious to read and have accessibility issues. 192.76.8.77 (talk) 12:25, 31 October 2021 (UTC)[reply]
    I'm fairly sure Certes was joking about the blink/marquee. :-) Suffusion of Yellow (talk) 18:10, 31 October 2021 (UTC)[reply]
  • Oppose the standard UI scheme should be fine here. The main TCHY problem isn't the color - it is that it isn't displayed to people on mobile (yet) - and that is being looked in to elsewhere already. — xaosflux Talk 13:53, 31 October 2021 (UTC)[reply]
  • If a disruptive notice is to be desired, then I think that the new color scheme does not achieve that. To me, the new color scheme is too much similar to the preview notice at the top of a preview page:
    This is only a preview; your changes have not yet been saved! → Go to editing area
  • I routinely ignore that notice so it would seem to me that a different color scheme for the doom message would be a better choice.
  • —Trappist the monk (talk) 15:15, 31 October 2021 (UTC)[reply]
  • Oppose the new colour is visible enough IMO, I don't think it's worth creating inconsistency between wikis and adding more CSS just to change it back. NemesisAT (talk) 15:16, 31 October 2021 (UTC)[reply]
  • Weak oppose - I think paler one is sufficient. Less "loud" on the eyes Cas Liber (talk · contribs) 18:15, 31 October 2021 (UTC)[reply]
  • Weak oppose on changing back the colour. However I think adding an icon might be a good compromise to make it a bit more eye catching, and in fact the design style guide recommends using icons. Probably would need a phab task. the wub "?!" 00:37, 2 November 2021 (UTC)[reply]
  • Comment don't care, it doesn't matter, this is not why people don't understand/read their talk page. —TheDJ (talk • contribs) 11:16, 2 November 2021 (UTC)[reply]

Interface-protected edit request on 2 December 2021

Replace 

table.ambox + table.ambox {      /* Single border between stacked boxes. */
	margin-top: -1px;
}

with 

/* Single border between stacked boxes. */
table.ambox + table.ambox,
table.ambox + .mw-empty-elt + table.ambox {
	margin-top: -1px;
}

This will prevent the borders of the two amboxes from appearing together when they are separated by {{Dated maintenance category}} based template. This is because {{Dated maintenance category}} outputs a nowiki tag (which is needed to prevent blank lines from appearing at the top of articles) in addition to the category link it produces. The combination of a nowiki tag and a category link causes mediawiki to output a .mw-empty-elt element, which breaks the current CSS.

Right now two amboxes separated by a DMC based template look like:

With the proposed changes, they would look the same as two amboxes that are not separated by a DMC based template, which is:

– BrandonXLF (talk) 05:50, 2 December 2021 (UTC)[reply]

 Done @BrandonXLF: I don't love having to have this in common.css, but since it is adding that extra selector is ok. — xaosflux Talk 14:07, 2 December 2021 (UTC)[reply]

Fixing overflowing edit summaries on the watchlist

Tracked in Phabricator
Task T158725

Certain long edit summaries (such as this one to Wikipedia:RedWarn) cause content to overflow off the side of the screen.

The edit summary in contained in a span: 

<span class="comment">(Edit summary content)</span>

of which the class (comment) is: 

span.comment {
	font-style: italic;
	unicode-bidi: -moz-isolate;
	unicode-bidi: isolate;
}

We can use the overflow-wrap property (MDN) to cause a line break if the entire edit summary cannot be placed on its own "line" without overflowing. This CSS property is well supported by web browsers.

I propose we add the following CSS to MediaWiki:Common.css: 

span.comment {
	overflow-wrap: break-word;
}

The break-word value allows for normally unbreakable words to be broken at arbitrary points if there are no otherwise acceptable break points in the line, which given the rarity of edit summaries this long (and the option to view the entire summary unbroken with a single click) I think this to be a good choice of word breaking method -- TNT (talk • she/they) 18:34, 3 December 2021 (UTC)[reply]

? @TheresNoTime: I looked at your example in monobook and vector, and in neither case is it going off my screen or causing horizontal scroll bars. — xaosflux Talk 19:37, 3 December 2021 (UTC)[reply]
@Xaosflux are you looking at the diff view? That one doesn't overflow, but I think TheresNoTime's issue is specifically occurring when viewing such changes on Special:Watchlist. -- Asartea Talk | Contribs 20:36, 3 December 2021 (UTC)[reply]
OK, was able to see it. @TheresNoTime: can you confirm this is the problem identified in phab:T158725? If we are going to hack around a problem, I'd like to be able to reference the bug. — xaosflux Talk 20:54, 3 December 2021 (UTC)[reply]
@Xaosflux: yup that seems to be the same bug.. may be worth seeing if this "fix" can be moved upstream a bit -- TNT (talk • she/they) 21:03, 3 December 2021 (UTC)[reply]
The problem here is actually the fact that RC and watchlist are a table. Tables overflow to fit the content of their cells when needed. In turn wrap (incl overflow-wrap:break-word) gets avoided as long as the parent can expand. Therefore this content can never wrap with this rule. —TheDJ (talk • contribs) 11:43, 4 December 2021 (UTC)[reply]
ah wait, that's only if grouping is enabled of course... hmm, i guess then it can work. —TheDJ (talk • contribs) 12:03, 4 December 2021 (UTC)[reply]
Don't worry, I did test it before proposing it 😝 -- TNT (talk • she/they) 15:38, 4 December 2021 (UTC)[reply]
 Done — xaosflux Talk 23:28, 5 December 2021 (UTC)[reply]
I'm also upstreaming this and some related cases. [1] [2][3] —TheDJ (talk • contribs) 08:48, 6 December 2021 (UTC)[reply]
This can be removed again btw, it's now in core. —TheDJ (talk • contribs) 10:04, 10 January 2022 (UTC)[reply]
@TheDJ: it sure would have been nice if you gave proper credit, but ho hum 🤷‍♀️ -- TNT (talk • she/her) 10:13, 10 January 2022 (UTC)[reply]
Sorry about that. Is your username ok, or do you want a specific name ? —TheDJ (talk • contribs) 10:52, 11 January 2022 (UTC)[reply]
Removed. — xaosflux Talk 11:16, 10 January 2022 (UTC)[reply]
And in TIL, overflow-wrap: break-word; / word-wrap: break-word is the same as word-break: break-word, except it only applies to inline elements and the 'added' 'deleted' parts of our diffs are inline-blocks.... —TheDJ (talk • contribs) 11:26, 11 January 2022 (UTC)[reply]

TemplateStyles for navbox

I am preparing to remove the CSS for navbox out of MediaWiki:Common.css in the near future in lieu of its current TemplateStyles implementation (see MediaWiki talk:Common.css/to do#description for rationale), but it will have one effect that may warrant review. Please take a minute to review or comment at Template talk:Navbox#TemplateStyles followup. Izno (talk) 22:31, 21 December 2021 (UTC)[reply]

It's out of my depth, but do I understand I check my pet navboxes after this change? Moment of change will be notified I understand. -DePiep (talk) 03:41, 22 December 2021 (UTC)[reply]
Yes, you'll see the removal happen in Common.css, plus I'll probably leave a comment at template talk:Navbox when it does occur. Izno (talk) 05:26, 22 December 2021 (UTC)[reply]

Main page heading

CSS to hide the Main Page heading in MediaWiki:Vector.css with .action-view.page-Main_Page .firstHeading is no longer needed per Wikipedia:Tech news#Tech News: 2022-02. For confirmation, https://en.wikipedia.org/wiki/Main_Page?useskin=vector&safemode=1 displays no heading. Some skins still display a heading without CSS to hide it, but phab:T298715 says that will end later this week. vector and minerva show no heading. monobook, modern (at top left), timeless and cologneblue currently show a heading.

The mobile https://en.m.wikipedia.org/wiki/Main_Page displays "Welcome, PrimeHunter!" due to the default MediaWiki:Wikimedia-mobile-mainpage-title-loggedin. That seems social-media like and a little creepy to me, giving a vibe of sites logging lots of user data for possibly nefarious purposes. It also takes up valuable screen space on mobile devices, and we already say "Welcome to Wikipedia" right afterwards. I suggest blanking the message as "unprofessional" for an encyclopedia. PrimeHunter (talk) 11:12, 11 January 2022 (UTC)[reply]

@PrimeHunter: agree in removing that $1 - it is only impacting registered editors, so it's not that bad - but I'd rather it be consistent anyway. — xaosflux Talk 11:14, 11 January 2022 (UTC)[reply]
I have no problem removing after the couple other skins get the change necessary. I don't see a strong reason to touch the individual skin.css pages for just the week or two (Timeless is on wmf.18, likely next week) in this case.
Something Stjn brought up was that we should probably have an H1 somewhere on the page to replace it, which we haven't done a good job of with the CSS version either. Izno (talk) 18:46, 11 January 2022 (UTC)[reply]
unprofessional ? You'll don't have names at your jobs ? It can stay as far as I'm concerned. —TheDJ (talk • contribs) 10:47, 2 February 2022 (UTC)[reply]

Mainpage-title

Now that we have Mainpage-title/Mainpage-title-loggedin, shouldn't line 8 be removed? NguoiDungKhongDinhDanh 12:57, 1 February 2022 (UTC)[reply]

This was a request to remove from vector.css, but this applies to multiple skins and needs more review first. — xaosflux Talk 14:07, 1 February 2022 (UTC)[reply]
I've removed the ones that seemed to exist in Vector, Timeless, and Monobook. Izno (talk) 18:28, 1 February 2022 (UTC)[reply]
As a followup, we now have an H1 on the page, in what I think is a reasonable spot. Izno (talk) 19:04, 1 February 2022 (UTC)[reply]
@Izno The original H1 containing "Main Page" is still there, just now MediaWiki automatically hides it with CSS. I think ideally the heading wouldn't be added to the output at all rather than hidden with CSS, but for now I'm not sure if having two H1s is a good idea. – BrandonXLF (talk) 03:48, 2 February 2022 (UTC)[reply]
As I had to point out in an issue related to this fix, the display: none H1 is not rendered of course, but also not served by accessibility agents. Nobody knows the first one is there, and even web spiders will ignore it these days. Izno (talk) 05:07, 2 February 2022 (UTC)[reply]
Interesting. Well as long as if everyone is ignoring the first H1 properly, then there shouldn't be any issues. – BrandonXLF (talk) 07:31, 2 February 2022 (UTC)[reply]
I bet there are modules and scripts that simply assume the existence of #firstHeading so hiding it is indeed a better idea. Nardog (talk) 11:16, 2 February 2022 (UTC)[reply]

Plainrowheaders background color

In cases where the row headers are apparent, or apparent with a flag image or row number preceeding them, it is more aesthetically pleasing to make the row headers' background color match the rest of its data cells. Otherwise, in the latter case, you would have one dark column of row headers in between light columns. I recommend adding a "plainrowheadersbg" class, which would only set "background-color: inherit;". Inherit for cases where you want a dark background for a row like "sorttop" that can be styled on the row. It was brought up at some point by @Timeshifter:, which I also like the style. I have it styled in Template:COVID-19 pandemic data/styles2.css for tables like Template:2020 monthly cumulative COVID-19 death totals by country and Template:COVID-19 pandemic data/Rhode Island medical cases by municipality. Jroberson108 (talk) 01:52, 14 February 2022 (UTC)[reply]

Using both the "plainrowheaders" and "plainrowheadersbg" classes would make the row headers look the same as the data cells, except it would still be a row header with scope="row" for accessibility purposes. This would help alleviate what I believe is the most popular workaround of not making it a row header just because they don't like the heavy look of it. I assume most sighted people can usually tell if the left column is or isn't describing the data without a background color, especially since the content is read in a order we are use to ("left to right", "top to bottom"). Jroberson108 (talk) 05:04, 14 February 2022 (UTC)[reply]

This is not a change I am interested in implementing. plainrowheaders itself was added as a compromise originally for cases of similar manner and the adder gave something of an opinion on "no more". Secondly, it adds to the global cost of addition to Common.css.
Secondly, this loss of distinguishing factor between the header and cell is a loss for even "sighted" people, who may not know what the most important part of a table is.
Individual templates where this is deemed reasonable may implement something with TemplateStyles. Izno (talk) 06:48, 14 February 2022 (UTC)[reply]
Almost all people know that nearly all tables have their most important info in the cells at the top and left side. I think Mediawiki should work on a way to only download table CSS if the software sees some table markup in the page. Then tables could be greatly improved. White background for data cells via a class instead of a template {{Import-blanktable}}. Lighter gray color for headers instead of the relatively darker gray color now used. Many more options, row numbers, etc.. --Timeshifter (talk) 08:00, 14 February 2022 (UTC)[reply]

Interface-protected edit request on 14 February 2022

Requesting that the following CSS be appended to the /* Show hidden items that have class="sysop-show". */ area of MediaWiki:Group-sysop.css: 

.nonsysop-show {
  display: none !important;
}

See Special:PermanentLink/1071739737 for the desired end result. There are some cases where some text is only relevant to non-administrators and could be hidden from administrators. The template Template:If administrator would require this change to work properly. This would align with the existing templates Template:If extended confirmed and Template:If autoconfirmed. Mz7 (talk) 03:53, 14 February 2022 (UTC)[reply]

I do not think this should be implemented. I would find it extremely concerning if this class were used for abuse and casual administrators were unable to see the text added. Izno (talk) 04:48, 14 February 2022 (UTC)[reply]
 Not done agree with Izno, not just for abuse but in general sysops are editors, if editors are seeing things sysops should see them too so they know what the editor see. — xaosflux Talk 11:33, 14 February 2022 (UTC)[reply]
NB, looks like we did not hide those other ones from sysops, for the same reason. — xaosflux Talk 12:17, 14 February 2022 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.css&oldid=1071803390"