MediaWiki talk:Common.css

From ArchWiki
Jump to: navigation, search

Templates' CSS

Reminder: for tidiness, the inline CSS used in existing templates should be moved to classes in this page. -- Kynikos (talk) 08:28, 27 December 2014 (UTC)

Perhaps we should make sure that the templates don't look broken on page such as [1]? -- Lahwaacz (talk) 17:49, 3 March 2016 (UTC)
Eheh if you disable the style sheets, you can't expect to see a lot of style left ;) Of course we can't float or hide anything without CSS or JavaScript, if we really wanted to fix that, probably our best bet would be to show the icons as background images through the CSS (with untracked direct urls instead of MW links!), so that they wouldn't appear in action=render documents. — Kynikos (talk) 08:15, 4 March 2016 (UTC)
OK, I will ask a different question to solve a practical problem. Do you know how force the load.php entry point to include this stylesheet? Currently I'm downloading only [2], which apparently does not include it. Firebug reports that all the resources leading to load.php include also skin=archlinux and common.css obviously works in the browser, so I have no idea...
I'd prefer to use load.php instead of getting the raw content of this page, because that way it will be validated, minified etc. But of course if you have a better idea, I'm all ears.
-- Lahwaacz (talk) 12:44, 4 March 2016 (UTC)
Uh, I see why you asked now, the module name should be simply "site" [3] ^^ (found with Firebug, not through MW docs, if they even exist)
Anyway, to add another answer to your original question, it would be possible to restructure the Message templates to look like this without CSS:

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: demo (Discuss in MediaWiki talk:Common.css#)


Then it would be possible, through CSS, to make that look like Message templates are looking now (in theory we could also include the <hr> elements themselves, and then hide them still through CSS).
Kynikos (talk) 14:04, 4 March 2016 (UTC)
Thanks, I've added the "site" module to the URL in arch-wiki-docs so that issue should be solved. But still, making the templates not depend on CSS will probably help a lot when reading the wiki in a console browser. Including the <hr> tags would probably break the flow of text in an unintended way, because even the lines below section headings are CSS. -- Lahwaacz (talk) 14:50, 4 March 2016 (UTC)
Ok, this should be implemented.[4][5]
I haven't put the hr tags for the moment, but my opinion is that it's the unstyled status templates that break the flow in action=render documents, and using hr tags does look better to me (section headings are not underlined there).
— Kynikos (talk) 04:02, 5 March 2016 (UTC)

List of templates with CSS

Free editing, no signatures required.

List of template pages with "style=" entries

I've queried content of all templates (https://wiki.archlinux.org/api.php?action=query&prop=revisions&generator=allpages&gapnamespace=10&gapfilterredir=nonredirects&gaplimit=500&rvprop=content) and simply searched for "style=" attribute in text. Dependent templates like Template:R are not listed here.

Hope this will be helpful to someone :D — blackx (talk|contribs) 06:54, 5 February 2015 (UTC)

Well done! Sooner or later we'll get to do this job too ;) — Kynikos (talk) 08:54, 5 February 2015 (UTC)

Responsive "Related" templates

Regarding the responsive style for the Main page, I'm wondering whether we should do something similar for Template:Related articles start etc? For example I find this to look much better in narrow window. -- Lahwaacz (talk) 16:10, 13 September 2017 (UTC)

True, I guess any solution is better than the current state. I was thinking about something more similar to the categories box, see User:Kynikos/common.css, there's also a style for status templates. -- Kynikos (talk) 11:35, 16 September 2017 (UTC)

Note, Tip and Warning template CSS

Currently users can't style Note, Tip and Warning templates since they use Template:META Box which uses inline CSS instead of CSS classes. –Larivact (talk) 12:45, 19 December 2017 (UTC)

Thanks Larivact, I've added some classes[6], but only the English templates are using them at the moment. Let's leave this talk as a reminder. Once all the translations are updated, the then unused META templates will need to be deleted. -- Kynikos (talk) 15:33, 20 December 2017 (UTC)

Move categories under h1

MediaWiki displays the page categories in the footer by default. Categories provide a great way to find related articles, which is why I think they deserve a prominent placement. I implemented the change for me using a flex box hack in my common.css, perhaps this could be added to the official CSS? If we implement this change we could also remove the superfluous links in Related articles boxes to articles in the same category. --Larivact (talk) 14:58, 3 April 2018 (UTC)

I agree that showing categories at the top is more useful; it's also more consistent with our convention to keep cats at the top of the source text.
I think this was already discussed at some stage, but don't remember when, where, or why nothing was done about it...
The best way would probably be to make it configurable directly in the skin, e.g. https://github.com/wikimedia/mediawiki-skins-Vector
If however people like the hacky CSS way, the following would be enough for me:
#bodyContent {
    display: flex;
    flex-direction: column;
}
#catlinks {
    order: -1;
}
(perhaps fix the margin between categories and the super-page link in subpages? also, except the Main page altogether?)
-- Kynikos (talk) 17:42, 4 April 2018 (UTC)
Fixed the margin between categories and the super-page link, excepted the Main page. Last three rules are only minor style tweaks but I think they improve the looks.
/* Move categories to the top except on Main page */
body:not(.page-Main_page) #bodyContent{
    display: flex;
    flex-direction: column; 
}
body:not(.page-Main_page) #catlinks {
    order: -1;
    
    margin-bottom: 0.25em;
    margin-top: 0;
    align-self: flex-start;
}
body:not(.page-Main_page) #contentSub {
    margin-bottom: 1em;
}
--Larivact (talk) 05:40, 5 April 2018 (UTC)
Nice, thanks, indeed it's a matter of personal taste, but I do prefer if the box is allowed to stretch to full width, as it is by default; also I actually like your original idea to leave the super-page link between the first heading and the categories, it allows to solve the margin problem more simply. This is my new proposal:
body:not(.page-Main_page) #bodyContent{
    display: flex;
    flex-direction: column; 
}
body:not(.page-Main_page) #contentSub {
    order: -2;
    margin-bottom: 0;
}
body:not(.page-Main_page) #catlinks {
    order: -1;
    /* The margin-bottom is consistent with div.archwiki-template-message */
    margin: 0.5em 0 1em;
}
-- Kynikos (talk) 16:25, 5 April 2018 (UTC)
I am alright with that, though leaving the super-page link in between wasn't my idea. --Larivact (talk) 17:50, 5 April 2018 (UTC)
That's a nice idea, previously I had a javascript solution but plain CSS would be much better.
Visually, the 1em bottom margin is not consistent because the space between the category links box and the first paragraph is actually 1.5em. I guess the margins of the catlinks box and the paragraph don't overlap because they are not syblings in the DOM. To make consistency worse, e.g. List of applications looks nice because the navigation box at the top does not have a top margin.
Also, the Wiki Monkey interface on category pages looks bad with this trick, but that's not a blocker.
-- Lahwaacz (talk) 19:22, 5 April 2018 (UTC)
Good observation. Indeed there is no margin collapsing in a flex. Does adding the following solve the inconsistencies? --Larivact (talk) 04:38, 6 April 2018 (UTC)
body:not(.page-Main_page) p:first-child, .archwiki-template-meta-related-articles-start + p{
    margin-top: 0;
}
Looks like so, but there are more inconsistencies, e.g. Laptop/Lenovo, Lenovo_ThinkPad_X1_Carbon_(Gen_6)... -- Lahwaacz (talk) 06:49, 6 April 2018 (UTC)
The problem is that the two ways to move catlinks to the top with CSS - absolute and flex positioning - both don't work with margin collapsing. I think we're better off patching MediaWiki, I am not familiar with the MediaWiki codebase but I managed to come up with this, which seems to do the trick. --Larivact (talk) 08:47, 6 April 2018 (UTC)
I think the problem is the style of our templates then, their vertical margins aren't consistent, we should fix that; the default margin for p is 0.5em, maybe we can just stick to that.
My preference is [patching the upstream skin with a new configuration option] > [CSS hack (whether kept in this page or in our wiki repo)] > [maintaining a skin patch in our repo].
-- Kynikos (talk) 10:07, 8 April 2018 (UTC)
@Larivact, lately I've seen you "rm related articles in the same category" from several articles, e.g. [7]. 1) I think that kind of systematic editing should be at least announced first, and 2) I think it would make sense only after we find a good way to move the category box to the top. -- Kynikos (talk) 17:12, 14 April 2018 (UTC)
I'm sorry about that, I'll announce "that kind of systematic editing" in the future. Regarding your previous reply, I think that maintaining a 6 line patch is less work than making a pull request that upstream accepts.--Larivact (talk) 18:07, 14 April 2018 (UTC)
I've opened T192223, let's see if there's any interest first. -- Kynikos (talk) 05:52, 15 April 2018 (UTC)
There doesn't seem to be. --Larivact (talk) 07:01, 16 May 2018 (UTC)
It's been worth a try. As I said, the CSS hack works for me, but do try to submit your patch to our repo, I support it, after all I'm not the one who has to fit into the wiki upgrade procedure :) -- Kynikos (talk) 15:22, 20 May 2018 (UTC)
Opened a pull request. --Larivact (talk) 12:51, 14 August 2018 (UTC)