Page MenuHomePhabricator

Use 'outside' instead of 'Inside' for list-style in Mobile version so that long line bullet list items are more scannable
Closed, ResolvedPublic


Using the 'inside' parameter in 'list-style' have converted bulleted and numbered lists to 'hard-reading' thing. Blocks merge and offset from the position of the markers does not help.

Left: expected, right: actual

gAL5uyG-Zp8.jpg (653×867 px, 140 KB)

Maybe we can remove it from .content ul ol?

I understand - really small screens may have problems with reading of thin column. But I think the best solution is - to add @media rule for small screens.



Note, the margin to the left of the list items

Developer notes

Add a padding left e.g.

list-style: square outside;
padding-left: 42px;

To avoid references list touching each other (T216591) {
    margin-right: -1em;

.reflist ol.references {
    padding-right: 1em;
There are several articles with 100+ ol list items, we need to make sure that indentation (`outside`) works well there. Example:

= QA instructions
~~Visit on a range of browsers. ~~
**Environment:** staging
**Browser & device:** iOS/Chrome & Safari, Android/Chrome & Safari, desktop/Chrome&Safari
**Skin**: MFE/Minerva
 - Visit
 - Ensure that the list item indicators do not stick out beyond the left-edge of the content container. In other words all of the content should be flush on the left side. Here is an example of what it should **not** look like:

Previous QA Results


QA steps

Environment: production
Browser & device: mobile, iOS (Safari) & Android (Chrome)

  • visit pages with over 100 references (Obama, China, Shakespeare
  • go to the references section
  • ensure that all reference numbers are right-aligned (with each other), and all reference text is left-aligned
  • ensure that no reference numbers are clipped by the edge of the screen

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Great catch @Edtadros. To further illustrate the issue here I've attached a screenshot (slightly modified content to make it a little more compact), with an indication of the content boundary. Thinking maybe this won't work with ols after all, since unlike uls the list indicator is not a uniform width (i.e. as the numbers get into double, then triple digits they become wider).

ol issue.png (1×375 px, 160 KB)

Change 491644 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Revert "Switch to outside list style for ordered lists too"

Change 491644 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Revert "Switch to outside list style for ordered lists too"

This should be fixed in master and production.@Volker_E @Alexhollender please confirm and then untag this with kanabana... throw this into the design backlog or reading web backlog to work out next steps.

I'm not able to load master (maybe I'm using the wrong link?) but confirming this is fixed in production.

I think we still want to switch to outside list style for ordered lists (for scannability, for consistency with unordered lists, and to avoid the rendering bug inside styling causes in VE as seen on T208102).

I think the solution is to simply use bigger padding? 1em is clearly insufficient, but, at a glance, 2.5em seems fine (fits up to 3 digits). 2.5em is also equivalent to the padding browsers use by default (40px).

@matmarex I agree that this would be great to implement, given the improved legibility. If we only use margin I think we'll end up in a situation like this:

only margin.jpg (1×750 px, 179 KB)

Did you have a look at the pen @Volker_E started? It seems like it could be a good direction:

I see what you mean, but I don't think that's a problem. I've always seen ordered lists displayed (and printed) in this way (with the digits of the same magnitude aligned).

JTannerWMF added a subscriber: JTannerWMF.

Jess will take a look as well.

Summary from VisualEditor's perspective

There are three possible ways we could display ordered lists (screenshots/mockups of

With "inside" list markers (currently in production)With "outside" list markers aligned right (@matmarex's proposal)With "outside" list markers aligned left (@alexhollender's proposal)
image.png (615×633 px, 45 KB)
image.png (615×633 px, 45 KB)
image.png (615×633 px, 45 KB)

Pros and cons:

With "inside" list markers (currently in production)

  • Efficient use of space
  • Long lists are not easily scannable for readers (hard to see where list items begin and end)
  • Easy to implement
  • Due to bugs in browser support, they don't render correctly in VE (T216792), so we would have to use one of the other styles in VE anyway

With "outside" list markers aligned right (@matmarex's proposal)

  • Less efficient use of space
  • Easily scannable for readers
  • Everyone on the Internet does lists this way, because it's the default
  • Easy to implement (this is the browser default)

With "outside" list markers aligned left (@alexhollender's proposal)

  • Less efficient use of space
  • Easily scannable for readers
  • At least some text editors default to this (LibreOffice, Google Docs), so users may be used to it
  • Tricky to implement (we would have to specify the exact margin/padding for list items up to 10, up to 100, up to 1000 etc.; I'm not sure what is the font situation on mobile, but there might be no margin/padding that aligns the numbers correctly for every possible font, although 0.5em per digit should work)

My aesthetic preference is version 3 (@alexhollender), however I think that in terms of scanability either that or the version by @matmarex will work. So due to ease of implementation, I'd vote for the proposal by @matmarex

cc/ @alexhollender

Change 494374 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/skins/MinervaNeue@master] Switch to outside list style for ordered lists too (second try)

As an insight (content got Base80 background, ol of enwiki British Museum article started at 900 with start=900 HTML attribute on ol and I've removed the columns:

image.png (640×2 px, 263 KB)

I'd suggest amending the padding from 2.5em to 2.25em equivalent to 36px to stay in a 4px base:

image.png (652×2 px, 262 KB)

and also amend ul padding in a follow-up to have a clean scan-line:

image.png (626×2 px, 156 KB)
image.png (618×2 px, 156 KB)

@Volker_E I don't think 2.25em is guaranteed to exactly match the width of 3 digits plus a dot with every possible font?

@matmarex I don't think there's any distinct number that gives us that certainty. :P
Example on Barack Obama, with 2.25em together with the new operating system font stack of T175877 on Chrome/macOS:

image.png (568×640 px, 86 KB)

We've got enough body margin to allow very long (1000+) or wide (f.e. 888 or 900) items to overflow.
I think that 2.25em/36px provides us a good compromise between indentation and providing space for 100+ items.


image.png (562×640 px, 111 KB)

image.png (566×642 px, 85 KB)

Okay, I don't really mind either way, let's do that.

@Jdlrobson if i'm reading this correctly, the proposed change (ol changes list-style to outside from inside, padding-left: 2.25em is added) would at least break the references display in the apps, possibly more. We could implement an override in page library before this goes live again unless there's some other way to work around this.

Screenshot of numbers cut off in the Singapore article references on the iOS app with the proposed changes:

Simulator Screen Shot - iPhone X - 2019-03-12 at 16.14.00.png (2×1 px, 364 KB)

Article HTML

Would simply increasing the padding solve the problem? And if so, what is the right value? 2.5em? 3em? I think these would be just as reasonable to use for the website as the currently proposed 2.25em.

Thank you @Jdlrobson and @JoeWalsh for checking this, I would not have expected this to cause problems with the apps.

@JoeWalsh Thanks for those insights. What is your preferred way forward (I personally wouldn't rely on that value being unchanged for all future)?

@Volker_E my preferred way forward would be to override the style in the apps for now so that this can be whatever is best for the web. Both apps will be switching to a new endpoint for article viewing and the long term solution for CSS interdependency is being worked out there.

Mentioned in SAL (#wikimedia-operations) [2019-03-19T17:14:24Z] <mholloway-shell@deploy1001> Started deploy [mobileapps/deploy@64f09a0]: T150377: Bump wikimedia-page-library to 6.3.0

Mentioned in SAL (#wikimedia-operations) [2019-03-19T17:18:11Z] <mholloway-shell@deploy1001> Finished deploy [mobileapps/deploy@64f09a0]: T150377: Bump wikimedia-page-library to 6.3.0 (duration: 03m 47s)

Mentioned in SAL (#wikimedia-operations) [2019-03-19T17:31:22Z] <mholloway-shell@deploy1001> Started deploy [mobileapps/deploy@64f09a0]: T150377: Bump wikimedia-page-library to 6.3.0

Mentioned in SAL (#wikimedia-operations) [2019-03-19T17:33:12Z] <mholloway-shell@deploy1001> Finished deploy [mobileapps/deploy@64f09a0]: T150377: Bump wikimedia-page-library to 6.3.0 (duration: 01m 50s)

@JoeWalsh are we okay to merge the Minerva patch now (knowing that it won't go out until next Thursday (28th)) ?

@Jdlrobson if possible, it'd be better if it could wait until after the next Android release that includes page library 6.3.0 CC @Dbrant

@matmarex Yes, thanks; this should be OK from our end.

Change 494374 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Switch to outside list style for ordered lists too (second try)

(not sure if Reading folks want to run this through QA, should we just mark as resolved?)

@alexhollender over to you. Please expand QA steps as you wish.

The alignment of the references looks good on mobile, and it seems like there is no longer any clipping of li numbers.

On a larger screen the columns of references seem to be too close together. On Vector there is ~27px between the two columns. Given the larger font-size in Minerva it seems like more than 27px would be warranted, though currently there is only 19px of space. Is that issue relevant to this patch?

column spacing.jpg (1×1 px, 423 KB)

@matmarex @Volker_E any idea if the issue I mentioned in T150377#5156510 is related to this patch, or should be tracked separately?

@alexhollender That is correct, the ol receives 3.2em on desktop/Vector and only 2.25em on MN. As the 2.25em were difficult to come up with, a possible way out could be adding some magic on mobile mw-references-column .references, like padding-right: 1em – probably only on tablet and desktop where the columns kick in.

@Volker_E ok great. Going to put this in needs more work since it seems sensible to take care of that with this task. If you decide it would be better handled separately feel free to move this on to QA.

@alexhollender I don't think it's a new issue, I think it would have looked similar (if not worse) before the patch.

Here's a quick experiment with the browser developer tools, I changed the padding-left: 2.25em; to padding-left: 0; list-style-position: inside; to replicate what we had before:

image.png (566×1 px, 151 KB)
image.png (566×1 px, 146 KB)

(for anyone following along, the article in these screenshots is

The problem from VE's perspective is fixed, so I don't really care if you continue here or file another task :)

Change 513990 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/skins/MinervaNeue@master] Adding a reflist.less file to hold Template:Reflist specific styles

@alexhollender the patch above adds a column-gap: 2em to the references list (instead of padding-right: 1em). Due to the difference in font size between Vector and Minerva, it's hard to judge if this is enough, but it's more it was before.

Change 513990 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Adding a reflist.less file to hold Template:Reflist specific styles

this change is visible on the beta cluster right now:
(the .reflist element has a column-gap: 2em; rule).