Write browse element icons as <img>

[AntonKhorev]

A smaller version of #5355 that doesn't include way node folding and grouping. Things should look mostly the same with better icon alignment. Although as you can see below, the priorities of icons if several are applicable are different. If an element has both shop and building tags, which icon should we show?

Before / after:
/

Before / after:
/

---

There are three different PRs for browse element lists:

• Show "node also part of ways" as nested lists on way pages #5317 that converts "also part of ways" from sentences into collapsible sublists. This requires more vertical space.
• Browse element folding nested lists and <img> icons #5355 that tries to address the vertical space issue by grouping way nodes. It was easier to do if css background icons are converted to <img> elements which made the PR quite large.
• This PR that converts css background icons to image elements.

[github-actions]

	1 Warning
⚠️	Number of updated lines of code is too large to be in one PR. Perhaps it should be separated into two or more?

Generated by 🚫 Danger

[tomhughes]

So to summarise on the question of what happens when there are multiple icons the old logic is that priority is defined by the order of the rules in the CSS which is mostly alphabetical except that the generic building rule is with the way rules which come after the node rules although the node/way split is really nonsense.

The new logic handles everything alphabetically, except that now the last rule wins rather than the first, and building is now ordered with other things so loses to shop but beats amenity.

My principle suggestion is that a key/value rule should always win over a key only rule as it's more specific.

If we want total backwards compatibility then the first matching rule should win - an way to do that would be to walk target_tags in reverse order when looking for a match.

I'm not sure that really matters though - if there are multiple key/value matches then there's no real right or wrong answer as to which one to choose.

[tomhughes]

Why use a variable for this when it doesn't ever seem to change?

[AntonKhorev]

That was the easiest way to stop linters from complaining. Otherwise they tell to use interpolation. But as soon as I use interpolation, html gets escaped.

[AntonKhorev]

And it won't exist if we do #5317. Not having to deal with inline icons is one of the goals of that PR.

[tomhughes]

Hmm that style warning is a bit annoying, because string interpolation would be really nasty there, so I guess we live with the dummy variable for now.

Other than that is looks good now.