Page MenuHomePhabricator

List indicators overlap with left floating images/blocks
Open, LowPublic




  1. See the (non) indented bullet list (:*) at:

  1. See the (non) indented paragraph (:) at:

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:01 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz11782.
bzimport added a subscriber: Unknown Object (MLST). wrote:

Not browser dependent -- tested with both IE6 and Opera 9.5 beta

MER-C added a comment.Apr 7 2008, 9:40 AM

Wikitext to reproduce:

Non-indented text.

:This text is indented one step (supposedly).

::This text is indented two steps (supposedly).

*:List indent.
#Ordered list.
#2nd item.

<br clear=all>

On the English Wiki (see [[User:MER-C/Sandbox]]) the above fails to indent at all. On the Test Wiki (see [[testwiki:User:MER-C/Sandbox]]) the result is slightly better but still borked.

The workaround here would be to use a table, but you shouldn't need one.

  • Bug 25158 has been marked as a duplicate of this bug. ***

That's a CSS float bug. The list items are actually indented, but only relative to the left margin of the page instead of the image. This happens with all indented elements. This cannot be fixed in Mediawiki.

Actually, I found out it's not a float bug; it's the default behaviour for list markers. They are placed outside the flow (list-style-position: outside;). Setting list-style-position to inside will put the markers inside the flow, but that clashes with the design of having them outside. So it's basically a design issue.

TheDJ added a comment.Dec 4 2011, 2:20 PM

This is a well known CSS problem. You could say that it is a bit of a flaw/oversight in the design of the CSS standard.

Been playing around a bit, and something like:

#mw-content-text ol,
#mw-content-text ul,
#mw-content-text dl {
overflow: hidden;
list-style-position: inside;


#mw-content-text li,
#mw-content-text dd {
padding-left: 1.5em;
text-indent: -1.5em;

/* Correct directionality when page dir is different from site/user dir */
.mw-content-ltr ul,
.mw-content-rtl .mw-content-ltr ul {

		/* @noflip */
		margin: 0.3em 0 0 0.6em;
		padding: 0;

.mw-content-rtl ul,
.mw-content-ltr .mw-content-rtl ul {

		/* @noflip */
		margin: 0.3em 0.6em 0 0;
		padding: 0;

.mw-content-ltr ol,
.mw-content-rtl .mw-content-ltr ol {

		/* @noflip */
		margin: 0.3em 0 0 2.2em;
		padding: 0;

.mw-content-rtl ol,
.mw-content-ltr .mw-content-rtl ol {

		/* @noflip */
		margin: 0.3em 2.2em 0 0;
		padding: 0;

/* @noflip */
.mw-content-ltr dd,
.mw-content-rtl .mw-content-ltr dd {

		margin-left: 0.6em;
		margin-right: 0;

/* @noflip */
.mw-content-rtl dd,
.mw-content-ltr .mw-content-rtl dd {

		margin-right: 0.6em;
		margin-left: 0;


Actually comes quite close. The problem is that it significantly changes the layout of all these elements. hlist on en.wp for instance was immediately troubled by it. Additionally, long lists wouldn't flow around the floating element anymore, but always be as a block to the right of it.

It has other problems too, especially on talk pages where all indents are now misaligned (due to not adhering to the default 1.6/3.2em indent space). Also, list-style-position: inside; casues numbered lists to align the list markers to be *left* and push the items to the right as number of digits increase, which is also rahter unsightly.

TheDJ added a comment.Oct 7 2012, 1:27 PM

For future reference, English Wikipedia now has the template Flowlist that can be used to workaround this problem selectively.

Suggest we close this, as I can't imagine a nice CSS solution for core.

  • Bug 48322 has been marked as a duplicate of this bug. ***

In line with bug T55991 (duplicate of this specific bug) that I've opened time ago, I was able to fix the issue forcing:
div.floatleft {

Now the output is identical to the image that use the thumb parameter.

In is visible its effect.

Evaluate & test this patch to verify if it's applicable as broader fix.

Thgoiter removed a subscriber: Thgoiter.Feb 22 2015, 9:05 PM
TheDJ changed the task status from Open to Stalled.Feb 23 2015, 8:45 AM

@Andyrom75 You are describing a different issue. Your issue is the lack of margin on the floatleft class (this is actually intentionally, it is supposed to do nothing more but floating left [a functional generic class without side effects], classes like thumb and infobox add the margin [more specific classes]).

This ticket is about the fact that even if you reveal the the indicator by adding margin on the floating element, you still don't get any indentation on deeper levels inside a list. The effect has the same cause, but this issue cannot be worked around with margins, unlike your problem.

Andyrom75 added a comment.EditedFeb 23 2015, 1:31 PM

@TheDJ, in this case T55991 has been wrongly marked as a duplicate. I'll move the above comment on the other bug, and maybe there I'd like to continue the discussion.

Edokter added a comment.EditedFeb 23 2015, 3:21 PM

It is a duplicate issue; the root cause is the same, namely because lists are styled with list-style-position: outside; to make list indentations uniform. This has always conflicted with left floating content.

Enwiki has a template for this[1], accompanied by some CSS in Common.css[2]


Can margin-right:1.5em; solve the problem in any situation? (I've checked only in the one appeared in it:voy)

TheDJ added a comment.Feb 23 2015, 8:11 PM

No. margin-right:1.5em; doesn't solve the problem, it just hides the problem for single level lists. Additionally, applying it to all floatleft elements will also break other use cases of floatleft which do not have such lists next to them.

The template (and it's accompanying CSS) described by Edokter provides a better fix and can be applied on a case by case basis, so that it doesn't have undesired side effects for other floating elements.

Melos added a subscriber: Melos.Jul 31 2017, 12:31 PM

This bug seems resolved in some browsers like chrome/firefox. IE or MS Edge seems still affected.

TheDJ added a comment.Nov 29 2017, 4:35 PM

Just a note as this issue came up during the wishlist survey.

The only other identified technique we could use here, might be:

.mw-parser-output ul,
.mw-parser-output ol {
    list-style-position: inside;

.mw-parser-output ul > li {
  text-indent: -1em;
  padding-left: 1em;
.mw-parser-output ul li > ul {
  margin-left: 0.6em;

.mw-parser-output ol > li {
  text-indent: -1em;
  padding-left: 1em;
.mw-parser-output ol li > ol {
  margin-left: 2.2em;

While close for Vector, this still isn't entirely matching existing indentation levels, but it's where i gave up experimenting.

The problem we identified with such techniques, is that you cannot predict the size for ordered lists very well, causing your indentation to vary in multiline situations.

Additionally, list elements are all over the place, and used for many purposes. By changing the text-indent, padding and margin, we are guaranteed to mess up lots of other content.

Aklapper changed the task status from Stalled to Open.May 10 2020, 9:01 PM

I don't see what/who exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status. (If this task can only be fixed by changing the code of web browsers, then task status should be "invalid" as it's out of scope for Wikimedia.)