The proposed solution using requestAnimationFrame (or L.Util.requestAnimFrame) works, but I am being careful to not break something. It's gonna require me more testing.

For the record, if Kartographer loads the icons from OOui, it will look like that:

Waiting for a decision on where should the icons' assets live: in OOui, in core, or bundled with the extension...

Excellent
Thanks @Krinkle for the details.

A few notes/comments/suggestions:

I'm not sure this is still a valid bug. I tried in preview mode, tried locally, and couldn't reproduce. @Yurik, can you still reproduce?

T157720 improved the style of attributions

Works now, but I created T163146 to review a couple of things.

This is how it looks now, I'm gonna mark the ticket as resolved. I think it's gotten much better, it's consistent with the new color palette, and there hasn't been any activity for a while.

This works, see example: https://www.mediawiki.org/wiki/Help:Extension:Kartographer#/map/7

This phase seems to be done

Testable at https://www.mediawiki.org/wiki/User:JGirault_(WMF)/QA/T154918

Tested after rebase, and it seems to me that all features work . We only need to make CI tests pass.

@Nirzar Looks good

In T153417#3170622, @Pginer-WMF wrote:

Another aspect worth discussing is how to style the "matching part of the title".
I think it is better to use bold (or color contrast) instead of underline, for the following reasons:

• Simplicity. Avoids adding additional visual elements.
• It's a common practice in similar contexts such auto-completion lists in search engines.
• Underline may be associated with links so it may generate some confusion about why part of the result is a link (and another part is not). Although this is a minor concern since, I don't think it would prevent the list from being usable in any case.

Here are some experiments:

• Bolding the matching part (or try the approach live at quora)
• Bolding the unmatched part (or try the approach live at google or bing)

In T162554#3175429, @stjn wrote:

Maybe you could at least ignore the layer in JavaScript if there’s errors for loading it? Right now it bugs out the whole map, and that’s not the best behaviour even if there’s more underlying problems.

https://github.com/kartotherian/tilerator/pull/10

In T162329#3164578, @Volker_E wrote:

@JGirault I agree with your statement about the missing direct shortcut to “Resources” on the homepage. That sounds like a good addition.
Here's a screenshot from your pull request

I don't think this is the right direction as it's a lot of redundant information. I'd rather add a sentence above or below saying if you refer to the colors in code, please use the following naming convention exemplified on white: For CSS --wmui-color-base100, for Less @wmui-color-base100.

^ This hack is the way to go.
The issue for disabling the pointer events on tile layers in leaflet.js was https://github.com/Leaflet/Leaflet/issues/2396.

I have added some thoughts to the topic:

I see the style guide as the language shared between designers and developers.

@Iniquity what colors did you find, and where? This change should have been done already.

In T157752#3150545, @Ainali wrote:

I think there are plenty of usecases for Wikipedia when the coordinates will never be allowed in OSM (think mostly historical data but also events in general) but will fit perfectly in a Wikidata object. It would be great to be able to get these with a query and display it in an article (e.g. all the battles in a war or similar).

In T152736#3145496, @Yurik wrote:

Done in upstream -- Added special handling for this in @kartotherian/server. Basic test on California coast showed a drop from 1.8MB to 855KB.

In T92452#3141633, @Prtksxna wrote:

In T92452#3140093, @Pginer-WMF wrote:

Indentation adds friction to the main scan line when going through the menu. I agree in avoid using them if we can communicate the groups without it.

I am not convinced by this, nor can I find a suitable precedent (examples here would help me). The scan line with indentation makes it easier to spot the grouping. Use of indentation/margins is key in showing hierarchy. Not sure why wouldn't apply such a useful tool for achieving our goal.

• In all your examples, applying line-height: 1.6; and making a few adjustments to center the text vertically would make the proposals look even nicer .

Ok now only the double click on the maplink still opens the dialog. I think I have to extend ve.ui.Command and run mwMaps through this.model.isEditable...

With this patch:

In T153417#3137564, @Volker_E wrote:

Another question from a style guide perspective, should the thumbnails feature rounded borders?

In T160704#3133504, @Jdrewniak wrote:

Just to reiterate my thoughts on the 1rem=10px idea.

The benefit of this would be to easily translate rems into pixels, but then how is this different than setting 1rem=1px and then using values like font-size=16rem? To me the only difference is the decimal.

In T157996#3134832, @Esanders wrote:

You'll want to extend the ve.ui.LinearContextItem like in ve.ui.MWReferenceContextItem in the Cite extension. You can disable the edit button by adding an isEditable method to ve.dm.MWMapsNode.

In T143877#3120161, @JMinor wrote:

For 2, yes, it may actually be quite complicated. I think a major blocker for us was that (and forgive if I'm wrong) the map tags and geojson overlays allowed/required the use of absolute pixel offsets. This was a non-starter for scalable mobile support.

It seems one way to actually fix it would be:

_:-o-prefocus, .styled-select.js-enabled select {
	background-color: var( --ss-c-grey-hover );
	color: var( --ss-c-grey );
}
_:-o-prefocus, .styled-select.js-enabled select:hover {
	background-color: var( --ss-c-grey-hover );
}

In T143877#3120011, @JGirault wrote:

• What's the iOS/Android teams plan regarding Kartographer maps?
• What's needed from the Kartographer developers to enable you?

Moving the discussion from the other ticket to this one:

I chose another fix, which is to wrap the number and the symbol + in a DOM element, and force that element to be displayed LTR.

New patch version features:

• Display top 10 item LTR or RTL depending on the language
• Force display of numbers in top 10 in LTR
• Force display of numbers in language dropdown in LTR

In T147347#3111366, @MaxSem wrote:

Fix the core or patch Mapbox?

@IGW We could do something that smart, but it would require to parse the GeoJSON for markers, which isn't necessarily the simplest thing to do.

Ah, I didn't even notice, thanks a lot @Neil_P._Quinn_WMF ! This will require me a little more work then.

@MaxSem any idea how to fix the failing phpunit tests?

I have issued an upstream patch to the mapbox.js repository, that would fix the issue:
https://github.com/mapbox/mapbox.js/pull/1217

I answered it in the other ticket T160782: Incorrect marker coordinates for outer resources

• Let me explain why this happened. The marker displayed on Google Maps is not the same point as the marker displayed on mapframe. The marker displayed on Google maps corresponds to the center of the mapframe. This is because the url is https://maps.google.com/maps?ll={latitude},{longitude}&q={latitude},{longitude}&hl={language}&t=m&z={zoom}. The marker comes because of the q parameter. If we replace with https://maps.google.com/maps?ll={latitude},{longitude}&hl={language}&t=m&z={zoom}, the map will be displayed with no markers.
  • GMaps with marker: https://maps.google.com/maps?ll=-10.14,28.13&q=-10.14,28.13&hl=en&t=m&z=4
  • Gmaps without marker: https://maps.google.com/maps?ll=-10.14,28.13&hl=en&t=m&z=4

Small PR fixing <title> tags, following the real one from @Volker_E, that was merged yesterday.

Simulation with preferred languages = arabic, french, spanish, hebrew