Template talk:Mbox

Removed clear: both;

Removing clear: both; solved wrapping problem. Please see diff.

See longer discussion (may soon be archived):

• Commons:Help desk#Need help with Category:Economic inequality and Template:Categorise

Problem and solution is also summarized here:

• Template talk:Categorise#Need help with Category:Economic inequality and Category:War casualties

--Timeshifter (talk) 08:08, 19 August 2018 (UTC)

Width

@Verdy p: I don’t want to further get into edit warring, as regenerating 1.2M pages after each revert is a bit costly game, but I still think that changing the layout of a such widespread template is not OK. If others did so before, blame them, but don’t repeat their mistake. I can support switching to width:auto with adding 10% margin on each side to preserve the visual appearance of the box, given there is prior consensus for it (or at least no opposition for a longer time, e.g. a week). So please revert until this consensus is established. (Or if you don’t want to revert, at least promise you won’t redo this change until there’s clear consensus, and I’ll revert.) —Tacsipacsi (talk) 14:34, 1 July 2020 (UTC)

It was NOT a margin of 10%, but a forced minimal width of 80% which is very bad now with the infoboxes taking more than 10% of the margin...

If you want something "visually equivalent", don't use width, but use left/right-margins of 10% (where the infobox can take space if needed).

A forced width of 80% means that if there's any floatting element beside (notably a wikidata infobox that has been posted in tons of pages), the message will be displayed after a vertical clearing (which can be very tall, if the infobox is tall), so the message will not be visible where it should be, and you obscure its and all the content after it.

Usage of "width:x%" is very bad for accessibility, the only useful case is "width:nem" with n about 36-40 maximum for columns (in multicolumn layouts), or "width:npx" for images which should be at most 250px if they are floatting, otherwise they should be isolated in a galery taking the page width, or islated in a centered block.

In fact that width parameter should be even removed from Mbox, possibly replaced by left/right margins (but there's no way to infer the correct margin values from the specified width value (we don't know the unit used). But using the default 80% is excessive (because it leaves insufficient margins: to fit only 250px of width for floatting elements the total page width would need to be at least 2500px, and this never happens on any device, not even on 4K displays, because the page width is already contrained by the side bar on the left) and breaks many pages showing floatting elements (including infoboxes or images) by creating huge vertical clearing to start below these floatting elements

This forced width of 80% does not make the Mbox more visible, it actually obscures it and the rest of the page. The visibility of the infobox is already warrantied by its colored borders and notification icon. The only valid value for width should be "auto" (thanks for users of smaller screens, and all mobile devices ans almost all desktop devices). This width is only suitable for giant screens (which are extremely rare and even on these, the "px" width is a logical unit measured in terms of view angle, where "1px" is more than one physical pixel): there does not exist any display where the usable page width is 2500px or more for the content area of the wikipage.

So the "width:80%" is harmful for everyone, as it forbids the use of any floatting element. And it's imposisble to determine in Mbox if there are floatting elements on the left or right (and using "clear:both" would be equally harmful). With it, we have to constantly play with the placement of floatting elements, forcing them (including infoboxes or images) to appear after all Mbox. Note that Mbox does not always appear at top of page (there are conflicting cases about what should be at top, but some Mbox are generated inside other templates which also post their own floatting elements, so it's tricky or impossible to determine the correct order).

If you want Mbox to be universally used and placed more freely on pages, it MUST not specify any "width:80%".

So propose instead using a default margin of 10% (and add the necessary parameter). This parameter "width" should not even be used, except with "auto". If a width is specified, the horizontal margin will be "auto" by default, otherwise it will be "10%". You get the same visual look (when there's no floatting element), but without the undesired vertical clearing and the infoboxes or floating images can still take space in these margins to extend them when the width is left at its default value "auto".

Note that this discussion is related to the previous thread where there was a similar problem with "clear:both" which was removed for the same reason.

What is new is that now there are floatting elements on many pages on this wiki, notably since the introduction of Wikidata infoboxes posted in million pages): all these pages have now broken layouts and have to be fixed manually to change the order (and sometimes it's impossible to get the correct order where there will be no clearing caused by these too large Mbox'es).

verdy_p (talk) 17:33, 1 July 2020 (UTC)

@Verdy p: I understand and accept that using width:80% causes severe layout issues on many pages. My most important problem is procedure—I think you should have not done this change without prior discussion in the first place, but reverting a revert before starting discussion is certainly unfriendly.

By the way, I don’t like the solution you picked, either—overriding the Common.css partly hides the issue instead of really solving it, as other pages directly using the messagebox class won’t benefit from it. I know that this is what you (and I) have direct access to, but working around access restrictions instead of seeking for help from people with higher levels of access often leads to inferior solutions.

Also, I think you estimate the number of affected pages to be larger than it actually is: this template is used only on 300k category pages out of the 1.2M, the other three quarters of usages are in other namespaces, where the Wikidata infobox is unlikely to appear. I’m also pretty sure that the majority of those 300k pages aren’t problematic, either: either they don’t use the Wikidata infobox, or Mike Peel’s bot placed the infobox below all other templates in order to prevent this layout issue. This also holds for the parameter, it won’t cause issues in many cases: probably the parameter is used in one-time calls, like {{Mbox}} call placed directly on user/user talk pages, or used in a template that will never be used on same pages as the Wikidata infobox, e.g. {{Deprecated}} or {{Image extracted}}. —Tacsipacsi (talk) 22:11, 1 July 2020 (UTC)

As a response to your message (and the already agreed problem that the infobox was not placed appropriately where it should have fitted (but this also affects talk pages where Mbox are posted, without regard of what is displayed above, which causes also a clearing: this may not be an infobox, but there are frequently images and various samples with floatting contents), I made the margin parameter taking 10%: the default width is still auto, but if any width is specified, the margins are set to auto by default instead of 10%. Given that, the Mboxes that assumed a 80% width (by default are now using a width set to auto but margins set to 10%, so they won't cause anyt clearing as they were. I documented the margin parameter. And the width parameter was in fact not suggested (it already had a status set to "-" and was not shown in the examples).

also I did not override the CSS. It was already overridden by this width parameter...

I think this restores the look and feel, except that now their 10% margin can be used by floats, reducing the mbox as needed without causing any vertical clearing). verdy_p (talk) 22:18, 1 July 2020 (UTC)

I agree that the original look and feel is mostly restored (except where improved, and on extremely narrow screens, where it’s slightly more broken than it used to be, but the win at larger screen sizes with floating elements well overweighs the loss at extremely narrow screens). I would still have welcomed a bit time left for others to comment, though.

In the previous version, the CSS width property was overridden only at request of the template user, which was to provide customization. Now it’s always overridden—this default override should be moved to Common.css to keep consistency (or the whole rule should be removed from Common.css and moved to TemplateStyles, but this requires fixing the thousands of pages using this class directly). When one passes parameters, it is to have a layout different from the layout and naturally leads to an override, but in other cases one could expect as much consistency between the two methods as possible. —Tacsipacsi (talk) 01:10, 2 July 2020 (UTC)

Your revert

@Tacsipacsi: The expansion I made was the simpliest way to correct an error which happens in many hundreds of cases; in my opinion it belongs to templates like {{Mbox}} to care for a proper environment, e.g. to finalize floating – and not to all the templates using Mbox to pass complicated style options. A short time everythng was o.k., now you are successful that Mboxes will look again like e.g. Tunneleffekt.svg. -- sarang♥사랑 16:47, 16 August 2020 (UTC)

@Sarang: |style=clear:both is not that complicated, and probably not often needed in the first place. In this case, for example, {{Igen}} should clean up after its floating boxes, and not all templates should be hacked that are possibly placed after it. Forcing clears is not always a good thing, see the above section about changing this template to fit next to infoboxes. —Tacsipacsi (talk) 17:00, 16 August 2020 (UTC)

Icon

I think it would be nice to change the icon. I propose File:Logo informations.svg who gives Sincerly. Manjiro91 (talk) 21:44, 16 January 2022 (UTC)

TemplateStyles

In order to remove a solid KB of styles from Common.css, I'll attempt to gradually convert this template to TemplateStyles. From what I can see, this template has drifted quite far from Template:Mbox on enwiki, and I have no plans to unify these at this time. (You can find their related change in edit 1 and edit 2).

To minimise disruption, I'll look for any loose non-templated use of internal mbox class by searching via insource, and moving over to mbox, or (if customised beyond mbox capabilities) to an appropiate template that achieves the customised use case (assuming there is one). this way these elements won't become unstyled or become dependent on an mbox that happens to be on the same page. Krinkle (talk) 03:06, 16 March 2024 (UTC)