MediaWiki talk:Common.css: Difference between revisions

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Extended confirmed users, IP block exemptions, Pending changes reviewers, Rollbackers
20,473 edits
Line 160: Line 160:
: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. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 03:29, 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. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 03:29, 8 December 2016 (UTC)
:(see related campaign here: [[100_Women_(BBC)#2016]]) — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 03:33, 8 December 2016 (UTC)
:(see related campaign here: [[100_Women_(BBC)#2016]]) — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 03:33, 8 December 2016 (UTC)

== Request for editing Mediawiki:common.css ==

{{edit fully-protected}}
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. <code style="background:yellow">:)</code>[[user:Ladsgroup|Ladsgroup]]<sup>[[User talk:Ladsgroup|overleg]]</sup> 02:59, 14 December 2016 (UTC)

Revision as of 02:59, 14 December 2016

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

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)[reply]
[9] 82.73.181.57 (talk) 13:05, 13 August 2016 (UTC)[reply]
moved the bullets inside the parser function, so probably fixed in that case? Frietjes (talk) 14:00, 13 August 2016 (UTC)[reply]
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)[reply]

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

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

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

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

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

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

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

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

RfC to regularise spacing between paragraphs on talk pages

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

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

Support

  1. Support as proposer
  2. 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). Pppery 23:02, 16 November 2016 (UTC)[reply]
  3. 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)[reply]
  4. Support, per excellent reasoning by the proposer and my previous support of this idea. Enterprisey (talk!) 04:43, 17 November 2016 (UTC)[reply]
  5. Support. A good idea can often justify itself. Best regards, Codename Lisa (talk) 07:05, 17 November 2016 (UTC)[reply]
  6. Support Seems like a good idea —TheDJ (talk • contribs) 09:19, 17 November 2016 (UTC)[reply]
  7. 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)[reply]
  8. 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)[reply]
  9. Support: I like this idea to make the spacing regularized. —MRD2014 (talk • contribs) 16:18, 20 November 2016 (UTC)[reply]
  10. 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)[reply]
  11. Support per above. --TerraCodes (talk to me) 09:00, 27 November 2016 (UTC)[reply]

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

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

@
WP:INDENTGAP. What RexxS is proposing will help to discourage multiple line breaks. --Redrose64 (talk) 13:48, 17 November 2016 (UTC)[reply
]
@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)[reply]
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
definition list. Is the proposed wider spacing also appropriate for that meaning? —David Eppstein (talk) 05:27, 26 November 2016 (UTC)[reply
]

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

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 :)Ladsgroupoverleg 10:03, 26 November 2016 (UTC)[reply

]

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)[reply]
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) :)Ladsgroupoverleg 18:13, 26 November 2016 (UTC)[reply]
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)[reply]
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)[reply]
@Ladsgroup: Can you be more specific about which elements you want to change ? —TheDJ (talk • contribs) 11:12, 30 November 2016 (UTC)[reply]

@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 :)Ladsgroupoverleg 16:16, 30 November 2016 (UTC)[reply]

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

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)[reply
]
Hey @
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)[reply
]
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)[reply]
(see related campaign here: 100_Women_(BBC)#2016) — xaosflux Talk 03:33, 8 December 2016 (UTC)[reply]

Request for editing Mediawiki:common.css

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. :)Ladsgroupoverleg 02:59, 14 December 2016 (UTC)[reply]

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