Last modified: 2009-07-20 04:49:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4829 - List misalignment in Monobook and Chick skins
List misalignment in Monobook and Chick skins
Status: RESOLVED DUPLICATE of bug 12262
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 4896 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-02-02 00:08 UTC by Michael Zajac
Modified: 2009-07-20 04:49 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Michael Zajac 2006-02-02 00:08:02 UTC
Ordered and unordered lists align differently in Monobook and Chick skins, while they align consistently in 
browsers' default rendering and in all other skins.

In these two skins unordered lists have a default margin-left: 1.5em, while ordered lists have margin-left: 
3em applied (to give room for 3-digit list item numbers).  When the two types of lists are nested and 
mixed, the hierarchical relationship is not reflected correctly in page rendering.

The simplest fix is to add margin-left: 3em for unordered lists, in these two skins.  This will change the 
rendering of pages, but will make them consistent with other skins, so it is solving a problem.

More info: [[en:MediaWiki talk:Monobook.css#Consistent list alignment]].
Comment 1 Michael Zajac 2006-02-02 01:38:36 UTC
Correction: ordered lists have margin-left: 3.2em; applied.
Comment 2 Netoholic 2006-02-02 02:13:49 UTC
Disagree with adding margin-left: 3em to unordered lists, as they are often used in tight spaces, like data tables.  
This change could also affect threaded dicussions and votes, where it may no longer be clear who someone is 
responding to.
Comment 3 Michael Zajac 2006-02-02 08:49:29 UTC
If mixed, nested lists actually do appear in discussions 
or votes (doubtful; show me an example), they 
currently render differently in some skins, so they are 
definitely broken for some readers or for others.  
Applying a fix would repair this discrepancy.

Where this is more important is the structure of 
complex lists in articles, where the hierarchical 
relationship of nested lists is rendered wrongly in 
Monobook and Chick.  This affects the actual meaning 
in articles, and should be fixed.

Example: [[en:Romanization of Ukrainian#Table of 
romanization systems]].  The table notes must have 
manually-applied list numbers, because a wiki ordered 
list was drawn too far right and looked like it was 
subordinate to an item above it.
Comment 4 Michael Zajac 2006-02-02 16:33:57 UTC
Regarding data tables, we could apply an override to 
make lists in tables as compact as possible:

  th ol, 
  th ul, 
  td ol, 
  td ul { 
    list-style-position: inside; 
    margin-left: 0; 
    padding-left: .5em; 
Comment 5 Michael Zajac 2006-02-03 19:31:50 UTC
Another editor pointed out that definition-list 
definitions also align inconsistently with other lists, in 
Monobook, having <code>margin-left: 2em;</
code>.  For the sake of presentation, they ought to 
have the same margin-left as other lists.  

Since they are less likely to be mixed with other lists, 
and are extensively used for indenting discussion, 
changing this should be considered carefully.
Comment 6 Brion Vibber 2006-02-06 21:22:30 UTC
*** Bug 4896 has been marked as a duplicate of this bug. ***
Comment 7 Brion Vibber 2009-07-20 04:49:14 UTC

*** This bug has been marked as a duplicate of bug 12262 ***

Note You need to log in before you can comment on or make changes to this bug.