Change #1260607 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Fix display of map for coordinate values in statement view

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

Change #1260615 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Fix display of map for coordinate values in statement view

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

Change #1260633 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] [WIP] Render the Kartographer map 10px narrower in MEX

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

The default width of the map component is 310 px - this is defined in CachingKartographerEmbeddingHandler.php and has no configuration options. This means that without changing the PHP we will always receive a version of the component that expects to have at least 310px width - a width that the current design doesn't accommodate in the statement view (as currently implemented - it's about 5-10px too narrow on a screen width of 375px).

Option 1 - change the layout

We could change the layout to make space for the additional 5-10px that we would need for the component to render correctly without changing its default size. This would mean slimming down some of the margins / padding on other components.

Option 2 - scale the component

We can override the server-supplied component size in Javascript before we initialize Kartographer. This allows us to control the styling of the element in our CSS without introducing '!important' styles. The map component can then shrink to be narrower than the 310px supplied by the server. This is demonstrated in this patch.

Option 3 - change the generated component size.

This patch is a proof-of-concept for an approach where we can provide an alternative fixed-width for the map component on MEX. The patch makes the map component small enough that it fits within the current design on our narrowest-supported screen size.

These options all apply to the rendering of the statement view (T420591). For the popover (T420585) the issue seems to be a much simpler CSS issue, which this patch addresses.

I'm biased towards fixing problems as close to the root as possible, rather than cleaning up symptoms. So, if we can do Option 3 (change the generated component size) without too much trouble, that's my preferred option. Based on my read of the comment thread in gerrit, and general understanding of Kartographer stuff, I think we can do it. Dealing with the php side of things would also give us flexibility in hypothetical future layouts involving maps.

If Option 3 is too much of a pain, Option 2 is a reasonable fallback.

That said, I'd be fine with slimming down margins and paddings (Option 1). As a small-phone user, having more space dedicated to content and interface elements is preferable. Though, I am not a designer and an anecdote about my personal preferences doesn't count as user testing ;)
On this point, I would defer to @Alice.moutinho.

tl;dr:
these all sound doable. From most to least favorite, I'd rank them as 3 - 1 - 2

Reviewed this together in task time on 31.3 and decided to go with option #3.

@ArthurTaylor I went through the given solutions now, and I would recommend going with Option 2, but with a small tweak: rather than replacing the hardcoded 310px with another fixed value, we can read the container''s actual available width at initialization time and set the map to that (only for small devices).

The problem is specific to smaller mobile devices (375px screens) where the available width falls just short of Kartographer's 310px default .. desktop and larger mobile sizes are working fine and we don't want to regress those. Reading the container width dynamically means we only affect layouts where the map is actually too wide, and everything else continues to behave as before.

Option 1 feels risky because it makes our margins implicitly load-bearing for Kartographer's component defaults . I think this could be easily broken accidentlly later and we should not change the layout only for one component.

Option 3 solves the immmediate problem but in the wrong layer: PHP runs on the server before it knows anything about the user's screen size, so putting a layout fix there means the next developer won't find it when they look in CSS or JS where layout decisions belong. It's also still a fixed value .. If a new device or future layout change shifts the available space further, you're back to the same problem and need another PHP change (to fix a client side issue).

So, based on that, I would vote for Option 2.

To be clear, 310px is not Kartographer's default. It's the default passed to Kartographer, from Wikibase, presumably based on the layout requirements of the desktop view. Kartographer doesn't have its own defaults. For its <mapframe> element, height and width are required parameters (see: Help:Extension:Kartographer)

Change #1260633 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Make Kartographer map view variable width in MEX

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

Change #1260615 abandoned by Arthur taylor:

[mediawiki/extensions/Wikibase@master] Fix display of map for coordinate values in statement view

Reason:

abandoned in favour of Ied78bb204c601ac6e5f119e

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

Change #1260607 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Fix display of map for coordinate values in edit statement popup

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

TV: The provided solution works.
Thank you!