MediaWiki talk:Gadget-responsiveContentBase.css

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Because gadgets behave slightly differently from user scripts etc, I had to make some corrections to some specificity rules in order to get things working properly. Please copy the contents of https://test2.wikipedia.org/w/index.php?title=MediaWiki:Gadget-responsiveContentBase.css&oldid=311184 to the .css page.

Upon saving, you will get an error from the editor, because the editor does not recognize the @supports rule. This is however valid CSS, do not worry about it. —TheDJ (talk • contribs) 12:22, 4 March 2017 (UTC)

Done, didn't see any error message. Jo-Jo Eumerus (talk, contributions) 13:33, 4 March 2017 (UTC)

Wang Leehom looks very strange on wide (≥1500px) screen: the infobox is floated to the right, while the message box just below it is on the right of the text. I don’t know how to solve this problem, but it certainly needs to be fixed somehow. --Tacsipacsi (talk) 11:08, 6 July 2017 (UTC)

IIUC, this is because there isn't an associated CSS class name, either added in Template:Contains special characters nor contained in MediaWiki:Gadget-responsiveContentBase.css. (I.e. other templates that utilize the {{side box}} meta-template, e.g. {{sister project}}, seem to work correctly due to paired CSS rules). I think the solution is to either add a new class name in both locations, or to add an existing class name to this CSS page (perhaps mbox-small would work?). Ping @TheDJ: for correction or confirmation. Quiddity (talk) 19:04, 3 October 2017 (UTC)

As a user of this gadget, who loves everything about it except for the 1900px+ changes, is it possible for me (us) to easily override just that section via our personal common/global.css?

E.g. I added this 1 rule to override just the fontsize, but I don't have the skill to do that manually for each of the rules (plus that might lead to unique bugs, etc). I'm hoping it is possible to have a personal 1-line override for that section. My current setup is 1920x1080, so it bugs me everytime I go fullscreen! Thanks. Quiddity (talk) 19:12, 3 October 2017 (UTC)

@Quiddity: No, you'll have to duplicate it completely for that. Can you be more specific about what you like and don't like ? The larger fontsize, the left column, the centering and limiting of the content ? —TheDJ (talk • contribs) 20:05, 3 October 2017 (UTC)

@TheDJ: Ah, foo. I'm afraid I want to disable all 3 of those aspects, though primarily the left-column/centering. I love the 1500px+ tweaks (and the 600px- tweaks!), and want to keep that 1500px+ configuration at all wider window sizes. Quiddity (talk) 20:19, 3 October 2017 (UTC)

@TheDJ: I've tried a bit more, and I think the problem I was hitting is cascade-order, because I'm importing the gadget into my global.js which makes it the highest priority of cascade (higher than my global.css). Am I correct that this makes it almost impossible to override the !important within .ns-0 .mw-body-content .mw-parser-output > * {margin-left: 350px !important;} within the gadget's code?

However! I have got it working, by using the browser extension Stylish, and this userstyles.org CSS. (Strangely it didn't work in greasemonkey, which seemed to be another cascade-order issue).

No questions, I'm just noting all of this here in case it's useful info. :-) Thanks again! Quiddity (talk) 19:02, 7 October 2017 (UTC)

I've taken the liberty of removing a table { display: block; } rule, as it was making table contents not even visible at all.

Report:

I can't see this: https://en.wikipedia.orghttps://wiki386.com/en/Talk:Hope_Downs
I can see the box, but not any of the content inside of it (like This article has been rated as Stub-Class on the project's quality scale.)

Removing that rule made the content at least appear, though it's somewhat ugly.

-— Isarra ༆ 08:36, 20 July 2018 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Using this gadget makes the mainpage top banner wider than it should be on wide screens. I think this is due to the main page not having a level 1 header messing with the bodycontent class. I've made a simple fix by adding .mp-topbanner to the following two blocks.

    .ns-0 .mw-body-content .mw-parser-output > table,
	.ns-0 .mw-body-content .mw-parser-output > .center,
	.ns-0 .mw-body-content .mw-parser-output > .navbox {
        max-width: -webkit-calc(100% - 350px);
    	max-width: -moz-calc(100% - 350px);
    	max-width: calc(100% - 350px);
	}

and

    .ns-0 .mw-body-content .mw-parser-output > table,
	.ns-0 .mw-body-content .mw-parser-output > .center,
	.ns-0 .mw-body-content .mw-parser-output > .navbox {
	max-width: -webkit-calc(100% - 700px);
    	max-width: -moz-calc(100% - 700px);
    	max-width: calc(100% - 700px);
	}

giving

    .ns-0 .mw-body-content .mw-parser-output > table,
	.ns-0 .mw-body-content .mw-parser-output > .center,
	.ns-0 .mw-body-content .mw-parser-output > .navbox,
        .mp-topbanner {
        max-width: -webkit-calc(100% - 350px);
    	max-width: -moz-calc(100% - 350px);
    	max-width: calc(100% - 350px);
	}

and

    .ns-0 .mw-body-content .mw-parser-output > table,
	.ns-0 .mw-body-content .mw-parser-output > .center,
	.ns-0 .mw-body-content .mw-parser-output > .navbox,
        .mp-topbanner {
	max-width: -webkit-calc(100% - 700px);
    	max-width: -moz-calc(100% - 700px);
    	max-width: calc(100% - 700px);
	}

I've been using this in my common.css and it hasn't caused any problems. I've discussed this at User talk:TheDJ#responsiveContent_bug. --Trialpears (talk) 08:05, 4 September 2019 (UTC)

 On hold @Trialpears: I've made a sandbox of this for you at User:Trialpears/Gadget-responsiveContentBase.css. Can you please make your exact edits in that sandbox and verify the code. Please note, the CSS checker is also reporting 3 critical errors in the existing code, please review while you are in there for possible improvements. Once ready, reactivate the edit request above. — xaosflux ^Talk 01:25, 10 September 2019 (UTC)

Xaosflux, I've implemented the exact changes at User:Trialpears/Gadget-responsiveContentBase.css, but I'm sadly not qualified to fix more complex errors with this tiny change being about the most complex thing I can do with css. A quick consultation with google reveals that @supports, which is the reason for the problems, is a poorly supported identifier, but I have no idea about possible solutions. --Trialpears (talk) 06:19, 12 September 2019 (UTC)

 Done @Trialpears: please test and let me know if any issues. — xaosflux ^Talk 13:12, 12 September 2019 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can someone make this edit in preparation of enabling the changes to media rendering? https://en.wikipedia.orghttps://wiki386.com/en/Special:ComparePages?page1=MediaWiki%3AGadget-responsiveContentBase.css&rev1=1104943208&page2=User%3AArlolra%2Fsandbox%2FGadget-responsiveContentBase.css&rev2=1163452302&action=&unhide=

There's some explanation of the reason for this change at mw:Parsoid/Parser_Unification/Media_structure/FAQ

Thank you, Arlolra (talk) 21:11, 4 July 2023 (UTC)

 Done Izno (talk) 17:10, 5 July 2023 (UTC)

It appears that the selector for this line MediaWiki:Gadget-responsiveContentBase.css#L-160 (158-161) is insufficiently precise, or that italic elements, in Vector 2022 skin need other classes. (not sure how to link to the range, linking effectful style line).

@media ( min-width: 1500px ) {
	.ns-0:not(.page-Main_Page) .mw-body-content .mw-parser-output > * {
		margin-right: 350px !important;
	}

On wide pages, I'm seeing 350px of right margin after every italic element, which makes math-heavy pages nigh unreadable.

Mcint (talk) 00:02, 14 December 2023 (UTC)