Author: FT2.wiki
Description:
Examples:
http://en.wikipedia.org/w/index.php?title=Essjay_controversy&oldid=167457832#Wikipedia_critics
http://en.wikipedia.org/wiki/Essjay_controversy#Identity_revealed
Version: unspecified
Severity: normal
Wikitext to reproduce:
[[Image:Example.png|thumb|left|200px|Caption.]]
Non-indented text.
:This text is indented one step (supposedly).
::This text is indented two steps (supposedly).
*List.
**Sublist.
*:List indent.
*Blah.
#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.
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.
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.
For future reference, English Wikipedia now has the template Flowlist that can be used to workaround this problem selectively.
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 {
margin-right:1.5em;
}
Now the output is identical to the image that use the thumb parameter.
In https://it.wikivoyage.org/w/index.php?title=Castel_Goffredo&oldid=394614 is visible its effect.
Evaluate & test this patch to verify if it's applicable as broader fix.
@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.
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]
[1] https://en.wikipedia.org/wiki/Template:Flowlist
[2] https://en.wikipedia.org/wiki/MediaWiki:Common.css
Can margin-right:1.5em; solve the problem in any situation? (I've checked only in the one appeared in it:voy)
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.
This bug seems resolved in some browsers like chrome/firefox. IE or MS Edge seems still affected.
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 {
overflow:hidden;
text-indent: -1em;
padding-left: 1em;
}
.mw-parser-output ul li > ul {
margin-left: 0.6em;
}
.mw-parser-output ol > li {
overflow:hidden;
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.
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.)