Somewhere along the way it seems some of the desktop styling made its way back to mobile.

The desktop styling was never disabled, and is constantly changing. In fact there are several edits in 2019. It's also possible this was an intentional change made by wikis so we'd want to do some community consultation to check that before making any changes here.

Note: An override now wouldn't guarantee it doesn't change again in the future and was always one of the big downsides of the approach we took with this feature.

This is not a regression. I added these styles "back" as part of TemplateStyles for mbox to make them consistent with desktop. While I appreciate that there is concern here, since mbox is now styled with TemplateStyles, I see this as completely on the community side to potentially change.

Incidentally, you apparently missed that .hatnote is also now TemplateStyles. ;)

Here's the relevant TemplateStyles page: https://en.wikipedia.org/wiki/Module:Message_box/ambox.css

@alexhollender_WMF - thoughts from your side?

@Izno thanks for the context. I think the colored left-border and the gray box around the ambox help it stand out on desktop, where the interface is relatively dense and complex. On Mobile the interface is much more simple and intentionally paired down in a variety of ways (e.g. the borders around infoboxes are less dark). In the mobile context I think the colored left-border and the gray box clash with the visual design of surrounding elements, and thankfully aren't necessary for making the ambox noticeable.

One of the design principles that I am still working to formalize within our design style guide, is a minimalist approach, where we use the fewest design elements necessary in order to achieve the usability goals. In this case, as I mentioned above, I don't think the additional visual elements are necessary.

Does that make sense? And how would you feel about us removing those styles from mobile (prioritizing context over consistency here)?

To start, from a general point of view of my own that I am pretty sure WMF shares: WMF should broadly avoid styling Editor-Created Things inside .mw-parser-output unless they are adding something to the output as with e.g. the little "learn about this message" link that shows up on the right of .ambox.

It is fundamentally our content that we have created, styled, and made, and accordingly the community should get to decide how something looks. While I am a community member, in lieu of a community consensus and discussion otherwise, I made the decision to make the display consistent with desktop.

See also that hacks.less even exists. (Apparently a reflist.less also exists solely to add column-gap: 2em but targeting .reflist which is an editor construct; why is that not targeting the .references list directly? Need to file a task for that.)

That any styles exist at all related to anything inside .mw-parser-output for MobileFrontend/Minerva is essentially an artifact mostly of JS-loading MediaWiki:Mobile.css -- which even today carries a huge warning sign that we have mostly respected; see also T190083 -- and the ad hoc approach WMF has taken to mobile since a decade ago when MF was first developed, notably that mobile didn't display .ambox at all using the same MF-rips-content-out-entirely as current-day .navbox until the community indicated this was a problem (see also the modern version of it T307848 which I should/could work around today if I haven't yet). Were Mobile.css render-blocking, and were .ambox displayed on MF from the beginning, this never would have been a question because the community would have decided on and subsequently added the appropriate styles a decade ago and the WMF would never have decided how it should look, or needed to, except perhaps to add the modal for the detailed ambox view. Which I am pretty sure was some collaboration given the necessary addition of the relevant class .hide-when-compact on the community side that MF hooks into to differentiate issue from detailed description/solution. (There is a gadget these days that uses the same class for non-mobile cases, CSS and JS, available for Vector and Vector22 and Timeless -- Timeless has its own CSS. Really should look into adding that for Monobook.)

Regarding specifics, in some order or another:

One of the design principles that I am still working to formalize within our design style guide, is a minimalist approach, where we use the fewest design elements necessary in order to achieve the usability goals.

That's fine. I think WMF having a style guide is Well and Good, and wouldn't want you not to do that. In fact, I personally appreciate minimalism in at least the chrome of the website as well as the basic style of HTML elements (h2.heading, .wikitable, etc.). But that's where it should stop in the ideal world. In fact I can think of at least one case where WMF style (colors, particularly) were rejected (at first) on the basis that there was a) no good reason to change on the community side, and b) the WMF guide is not the community guide or set of sensibilities. If the community should decide to have lots of garish colors everywhere, that's basically its prerogative (well, see the Main Page for long-term sensibilities on that point, but I wouldn't worry that the community would be making every other page else bright pink, Comic Sans, and slanted to 45 degrees any time soon).

the borders around infoboxes are less dark

For infoboxes where the community added the border (notably Template:Infobox settlement though there are others), no longer: those infoboxes with borders have been TemplateStyled for a year or so now, which means they are winning specificity questions (as with this task for .ambox), even were it the case that the related CSS had been in Mobile.css at all as it was in Common.css (until I removed it). For all other infoboxes, MF in fact adds row borders where there are none on the community side, so going from "no borders" to "all borders" is the exact opposite of "pared down".

On Mobile the interface is much more simple and intentionally paired down in a variety of ways.

Yes, practicality of space demands it in some ways, even if aesthetics do not.

In the mobile context I think the colored left-border and the gray box clash with the visual design of surrounding elements, and thankfully aren't necessary for making the ambox noticeable.

This is an aesthetic choice. Inside editor generated content, that's our responsibility and under our authority to change.

I would go further and suggest the point is to clash, a factor that was recognized (at some point) in related discussions regarding amboxes pertaining to deletion, but I don't think I need to make this counterpoint when the general philosophy is more important to recognize/accept.

Does that make sense? And how would you feel about us removing those styles from mobile (prioritizing context over consistency here)?

Firstly, I will not be doing so, and secondly, this is a question for the community, as commented both above and in my original comment on this task. I would expect a well-advertised discussion on the topic with the community before doing so. I think my general philosophy on the point as discussed above makes sufficient sense to decline your request at a basic level if not the more detailed level for this particular case. (For example, I had someone read this message over and basically agreed the borders and icons should be there but the borders could be smaller on mobile.)

As a final comment, once I'm done TemplateStyling things, I am in fact going request via task that these styles either get removed or get moved to a place where they could be turned off (in the same way that MinervaApplyKnownTemplateHacks can be turned false apparently). I haven't done investigation into exactly what MinervaApplyKnownTemplateHacks controls, so there may be some other work/discussion associated with it, but I think the ideal is that that option gets turned to false as wiki communities assert their own styling/character by making their templates Good Enough For Mobile. On that front, it's not a terrible thing that WMF did some groundwork here for the basics because it does allow some wikis to just open MobileFrontend out of the install box and have some classes they can play with without feeling bad about mobile use case, or even for WMF wikis where they don't have the manpower/knowledge to move to TemplateStyles solutions. (I'd be willing to work on the fleet personally, but I'm not quite done with en.wp yet, and for each of those wikis there is a discussion about local consensus for changes that my mostly-only-fluent-in-English-self will have to deal with.)

@Izno thank you for helping me understand this topic area. I now have a better understanding of this sort of "interface" vs. "content" distinction. I respect the division, and also hope that we can all (staff & volunteers) work together as collaborators and stakeholders on both the interface and the content. (Perhaps, in a way, some naivety here is beneficial, so we don't get too locked into our official roles :) As a designer working for the Foundation (and ultimately the Movement broadly) I certainly value community feedback and collaboration regarding the interface. I am hopeful that might be a two-way street.

Regarding the ambox styling on mobile, if you are willing to engage, I'm curious:

• do you see value in mobile ambox styling being consistent among different language Wikipedias? (this was a big objective for our team when we worked on them a few years ago)
• do you think the thick colored border and dark outline styling is beneficial (or even necessary) on mobile? From my perspective: I wonder if it gives, particularly lower urgency ambox messages, too much visual weight on the page?
• are you able to see my perspective of how the desktop styling clashes with the general visual design of the mobile website?

Thanks

In T316986#8237098, @alexhollender_WMF wrote:

Regarding the ambox styling on mobile, if you are willing to engage, I'm curious:

• do you see value in mobile ambox styling being consistent among different language Wikipedias? (this was a big objective for our team when we worked on them a few years ago)

Not really. Most editors do not cross community boundaries, and when they do they're generally smart enough about Boxes. My impression from previous discussions is that most readers probably use their native language +- native language fallbacks for basics and English otherwise (given English size and article detail dominance). A box on the screen, potentially with colors or whatnot, that says "there are issues", is going to be enough for most editors to grasp the sense of it, and for most readers, I anticipate banner blindness is a bigger deal anyway (though some astute readers say they use those to key off on how much to trust a page).

• do you think the thick colored border is beneficial and necessary

Yes. I remain solidly in the "let the community decide".

and dark outline styling is beneficial or necessary

I've been thinking about this generally. I use Timeless at mobile resolution which respects 'desktop' styling, and for most things that display in mainspace, at least a top and bottom border is necessary to distinguish from content above/below. Infoboxes, sidebars, quote boxes, and so on (Timeless thumb images also suffer for their lack of bottom border, even with a touch more margin). You could probably sell me that the left-right borders are not necessary in the general case for these items, including message boxes.

In the specific case here, I think the top side needs either margin or removal since it appears to overlap with the skin border, so there's a visual error there for me regardless. A bottom border here is generally necessary here to me per the general case.

From my perspective: I wonder if it gives, particularly lower urgency ambox messages, too much visual weight on mobile?

"too much visual weight": Define this. :)

The border colors denote the urgency. Red for deletion, orange for severe issue, yellow for style, blue for notice (hence the class names). Red and orange are generally severe enough for general appearance to me (and what the reader gets with those colors); yellow and blue less so (yellow still denoting a problem). But then, to remove it at the lower end we're in a question of both intra-module consistency and desktop consistency.

• are you able to see my perspective of how the desktop styling clashes with the general visual design of the mobile website?

No, not really. I see that you have this opinion, and I can grasp at "these are not minimal", but then, the issues being connoted are not minimal in my opinion.