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

Description

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

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.

Replication

Visit https://en.m.wikipedia.org/wiki/PhosAgro?oldid=776134001#Subsidiaries

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)

.mw-references-wrap.mw-references-columns:first-child {
    margin-right: -1em;
}

.reflist ol.references {
    padding-right: 1em;
}
**Caution**
There are several articles with 100+ ol list items, we need to make sure that indentation (`outside`) works well there. Example: https://en.m.wikipedia.org/wiki/Singapore

= QA instructions
~~Visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Test_lists on a range of browsers. ~~
**Environment:** staging
**Browser & device:** iOS/Chrome & Safari, Android/Chrome & Safari, desktop/Chrome&Safari
**Skin**: MFE/Minerva
**Steps:**
 - Visit http://reading-web-staging.wmflabs.org/wiki/Puerto_Rico?useformat=mobile#Notes
 - 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:
{F8550236}

Previous QA Results

StatusDetails
FailedT150377#4962190

QA steps

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

  • 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

Details

Related Gerrit Patches:
mediawiki/skins/MinervaNeue : masterAdding a reflist.less file to hold Template:Reflist specific styles
mediawiki/skins/MinervaNeue : masterSwitch to outside list style for ordered lists too (second try)
mediawiki/skins/MinervaNeue : masterRevert "Switch to outside list style for ordered lists too"
mediawiki/skins/MinervaNeue : masterSwitch to outside list style for ordered lists too
mediawiki/skins/MinervaNeue : masterSwitch to outside list style

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).

Hm, it looks like this is on production? @Jdlrobson @matmarex

Volker_E updated the task description. (Show Details)Feb 19 2019, 10:04 PM

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"

https://gerrit.wikimedia.org/r/491644

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

https://gerrit.wikimedia.org/r/491644

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:

Did you have a look at the pen @Volker_E started? It seems like it could be a good direction: https://codepen.io/alexhollender/pen/mvoXWq

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 https://en.m.wikipedia.org/wiki/List_of_regions_of_the_United_States#Federal_Reserve_banks):

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)

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)

https://gerrit.wikimedia.org/r/494374

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:

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

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

BeforeSuggested

@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?

Volker_E added a comment.EditedMar 5 2019, 12:05 AM

@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:


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.

Japanese:


Farsi:

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:


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.

Volker_E added a comment.EditedMar 13 2019, 2:16 AM

@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

alexhollender removed alexhollender as the assignee of this task.Mar 19 2019, 7:20 PM
Jdlrobson moved this task from Done to Tracking on the User-Jdlrobson board.Mar 25 2019, 10:00 PM

@JoeWalsh @Dbrant Looks like the Android app release happened on April 23 (https://lists.wikimedia.org/pipermail/mobile-l/2019-April/010681.html), and it looks like the change you mentioned has made it in (I assume that's this commit: https://github.com/wikimedia/apps-android-wikipedia/commit/145e0b8fe118724a28d1a7d9f2b5ac654b734e5a). Is it okay to go ahead and merge https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/494374 now?

@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)

https://gerrit.wikimedia.org/r/494374

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

Jdlrobson updated the task description. (Show Details)May 1 2019, 8:44 PM

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

alexhollender updated the task description. (Show Details)May 3 2019, 6:16 PM

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?

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

Volker_E added a comment.EditedMay 23 2019, 2:51 AM

@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:

BeforeCurrent

(for anyone following along, the article in these screenshots is https://en.m.wikipedia.org/wiki/Barack_Obama)

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

matmarex removed a subscriber: matmarex.May 27 2019, 5:38 PM

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

https://gerrit.wikimedia.org/r/513990

@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

https://gerrit.wikimedia.org/r/513990

alexhollender added a subscriber: Jdrewniak.

this change is visible on the beta cluster right now: https://en.m.wikipedia.beta.wmflabs.org/wiki/Albert_Einstein
(the .reflist element has a column-gap: 2em; rule).

ovasileva closed this task as Resolved.Jun 11 2019, 1:31 PM

yay, all done!