Page MenuHomePhabricator

Custom portlet links are not padded properly
Closed, DuplicatePublic

Description

Portlet links/toggle list items that are added by user scripts (using mw.util.addPortletLink) do not receive the padding other items in the list do because they do not have the class toggle-list-item.


Expected result:

image.png (421×213 px, 10 KB)

Actual result:

image.png (345×220 px, 10 KB)

This can be resolved with the CSS:

.toggle-list > ul > li {
	padding: 0.75em 0.875em
}

Ideally, the menu should also make the text look the same for all items and items added using JavaScript should be shifted to the right so all the text aligns. The items added using JavaScript should also have the background effect applied when the mouse enters them or they are clicked on, but getting the padding right is the most important because it makes the links easier to press and makes them look a lot better.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

cc @Krinkle I really think we need to reconsider the ideas in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/545636
Picking up my comment there "I consider the lack of icon support for Minerva a big problem from a ux standpoint. The links added by gadget do not fit into the look and feel." - now we've had 3 bug reports it seems to support those initial concerns.

What do you think about us adding a hook inside the addPortletLink function (per my description in T236711#5835576) so Minerva can make those changes?

I've restored the patch with this in mind.

I already demonstrated on the orignal task and patch that it is quite possible to style the items in questions this way by default.

I did leave some cases unhandled as you showed, but it was only a proof of concept to show you that there's a viable path forward. I don't have the familiarity with Minerva that you do to know where the remaining CSS would need to go. I'll gladly adapt the core interface if we find that something isn't currently possible or that it would currently require compromises in code quality or maintenance in Minerva's to make work. Do you feel that is the case?

What happens if we style the list items in Minerva according to Minerva's style by default (the right size, font, color and left-padded icon). Then for the nicer ones that Minerva adds itself we replace that default style with the way it looks now (styling icon and text separately). That seems pretty straight forward. I'm sure there's more to it that I'm missing, but I'm hoping a fresh perspective can help here.

As example, below is what it looks today, which I don't think anyone was proposing we actually ship:

Screenshot 2020-02-10 at 15.06.02.png (1×649 px, 98 KB)

As counter example, here's what three lines of not-so-pretty CSS can do:

Screenshot 2020-02-10 at 15.05.50.png (1×1 px, 138 KB)

I'm sure with a few more minutes and intimiate knowledge of Minerva, you can do better than my hack and also fit a background image in there.

Alternatively, while we have been moving for about 10 years towards more universal HTML (for the basic core features that is), we can depart from that and provide more abstract hooks instead. That is what I proposed in 2012 with T42813. The way it would work is that on the server-side we would export the basic structure of this list item as an HTML template with a handful of placeholders, and substitute those at run-time. This way there is no avoidable client-side overhead, extra JavaScript execution, or FOUC. I closed it because I found that whenever I tried, it actually turned out to be a good oppertunity to clear technical debt and not as hard as I imagined to style a plain HTML list item.

Change 545636 had a related patch set uploaded (by Krinkle; owner: Jdlrobson):
[mediawiki/core@master] mediawiki.util: addPortletLink fires hook for Minerva UX support

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

Alternatively, while we have been moving for about 10 years towards more universal HTML (for the basic core features that is), we can depart from that and provide more abstract hooks instead. That is what I proposed in 2012 with T42813. The way it would work is that on the server-side we would export the basic structure of this list item as an HTML template with a handful of placeholders, and substitute those at run-time.

That is inline with what I'm thinking. Universal HTML doesn't seem like a realistic goal to me.

I'll gladly adapt the core interface if we find that something isn't currently possible or that it would currently require compromises in code quality or maintenance in Minerva's to make work. Do you feel that is the case?

From my perspective while styling these links correctly with CSS while possible would be an unnecessary maintenance burden. It would mean we'd have to maintain two different implementations for how icons display in Minerva. The HTML structure of menu items is tied to mw-ui-icon and an icon needs to have an element for the icon itself and an element for the label in additional to all those necessary classes. Even if we made all our menus we still have other icons across the product we'd need to support and make display in consistent sizes etc.

I've asked @Jdrewniak to also weigh in on this discussion as somebody with experience with the pain of icons in Minerva.

Change 545636 merged by jenkins-bot:
[mediawiki/core@master] mediawiki.util: addPortletLink fires hook for Minerva UX support

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