Refactoring HTML anatomy of items in layers

[Anshpreet8]

Used the svg "More Vert" icon instead of the details element to avoid having to nest interactive elements inside the summary element, as the suggested layout in the proposal for alternative layer item anatomy

Essentially the same PR as #530, which was closed due to renaming the branch to refactoringLayer

List of Issues that can be closed from this PR:
Closes #263

[ahmadayubi]

@Malvoz was there a specific reason for using SVG icons rather than HTML icons? Like the ones used for the zoom, reload and full screen buttons?

[Malvoz]

@ahmadayubi

HTML characters can be problematic because they tend to render differently depending on the browser/OS.

They're also much more likely to be unintentionally affected by author-provided styles such as font-size and letter-spacing, which is why we reset styles (before leaflet.css and mapml.css is applied). See for example how the zoom controls look with a 5px letter-spacing in #140.

[ahmadayubi]

@Malvoz That makes sense but how differently could the x symbol, for example, render across browsers, it would seem like a pretty consistent symbol.

We used it in the past, and leaflet uses them too, I wonder if it would be better to stick to using them simply for consistency. Also having to generate SVG in JavaScript isn't the most developer friendly code to read either.

[Malvoz]

@ahmadayubi In a nutshell SVG icons generally look better and seem less problematic, but if you'd rather use HTML characters that's fine.

having to generate SVG in JavaScript isn't the most developer friendly code to read

If we want to allow customization of icons in controls at some point, we may perhaps want them to be CSS background-images, such that authors can override them, using e.g. ::part(reload-button) { background-image: ... } (depends on #497). But maybe that can be changed later, as part of or after #19 (in which we'll have to specify icons for all controls, I think).

[ahmadayubi]

I didn't run into any issues, I did notice some alignment issues:

It may also be nice to add interaction to the whitespace:

Previously it would expand the former details element.

Lastly, (not that important), the icons & interaction points seem inconsistent and have different sizes, although I don't think this can be changed given the current requirements and restrictions set (i.e. buttons being 44px and html details element icon being smaller):

[Malvoz]

It's possible to drag to re-order layers in the control when dragging starts on the layer name and the "Layer Settings" control, but not the "Remove Layer" control, just noting that inconsistency.

[prushforth]

We should probably use L.DomUtil.create(...) consistently. I think you can call it with no class values and have it work like document.createElement().

[prushforth]

Everything looks very good to me, and it works very well, too. Good work @Anshpreet8 ! Thanks @Malvoz and @ahmadayubi for your help and reviews. I will merge once Ahmad signs off on it.

[ahmadayubi]

It looks good to me, there are some parts of the code that still use document.createElement from before @Anshpreet8 's changes, if you'd like @Anshpreet8 you could convert all old bits to use L.DomUtil.create() as well to update the entire function and make it more consistent. You could also take advantage of L.DomUtil.create()'s ability to append child and add classes in a single line of code.

I marked out a few places that could be changed but there are other places as well. But these are not critical changes so @prushforth feel free to merge without these changes if you'd like.

[Anshpreet8]

Adding a container to append to using L.DomUtil.create without including a classname present does not append it, so I've used appendChild for those scenarios.