Maps4HTML / MapML.js

A custom <mapml-viewer> and <layer-> element suite
https://maps4html.org/MapML.js/
Other
58 stars 16 forks source link

Write <map-a> as a custom element #402

Closed prushforth closed 3 years ago

prushforth commented 3 years ago
ahmadayubi commented 3 years ago

I found this: https://github.com/WICG/webcomponents/issues/634

It seems as though it's not possible to wrap <path> with custom elements. You could use <a is="web-a"> but as @prushforth mentioned that wouldn't work on Safari.

Malvoz commented 3 years ago

It seems as though it's not possible to wrap <path> with custom elements.

I think it should be possible to work around that using <foreignObject>.

Malvoz commented 3 years ago

For example, the following should theoretically work:

<svg xmlns="http://www.w3.org/2000/svg">
  ...
  <foreignObject width="" height="">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <map-a> <!-- or if it's fine to "pollute" this element, remove `<div>` and set the namespace attribute here. -->
        <svg xmlns="http://www.w3.org/2000/svg">
          <g>
            <path d=""/>
          </g>
        </svg>
      </map-a>
    </div>
  </foreignObject>

But perhaps that's not flexible enough?

ahmadayubi commented 3 years ago

@Malvoz Does that allow nesting? For example:

<svg xmlns="http://www.w3.org/2000/svg">
  ...
  <foreignObject width="" height="">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <map-a> <!-- or if it's fine to "pollute" this element, remove `<div>` and set the namespace attribute here. -->
        <svg xmlns="http://www.w3.org/2000/svg">
          <g>
            <map-a>
             <path d=""/>
            </map-a>
          </g>
        </svg>
      </map-a>
    </div>
  </foreignObject>

Or would you have to create another <foreignObject> within the nested <svg>?

prushforth commented 3 years ago
<svg xmlns="http://www.w3.org/2000/svg">
  ...
  <foreignObject width="" height="">
      <map-a  xmlns="http://www.w3.org/1999/xhtml"> 
          <g xmlns="http://www.w3.org/2000/svg">
             <path d=""/>
          </g>
      </map-a>
  </foreignObject>

would be more like what we would need, since we're inside a leaflet map pane with css transforms happening, and I doubt the browser would be coded to look inside a foreignObject for more svg content.

Malvoz commented 3 years ago

@ahmadayubi re https://github.com/Maps4HTML/Web-Map-Custom-Element/issues/402#issuecomment-823263882, yes the inner <map-a> would have to be wrapped in a new <foreignObject> or else it'd be treated as SVG (I believe dasherized elements are treated as unknown elements in SVG, which in turn is treated as <g> for the purpose of rendering).

ahmadayubi commented 3 years ago

It's a lot of nesting in that, each <path> would also have to wrapped in it's own <svg>, it's doable but seems like a lot of DOM clutter. @prushforth thoughts?

prushforth commented 3 years ago

The objective of the map-a would be

a) to provide encapsulation/modularity of code and b) a CSS selector target that could be styled.

The major constraint would be (I believe) that the graphics inside the map-a would have to be accessible to the css transforms that leaflet applies to the ancestor map overlay pane div, without needing special replication or complexity, such as opening a new svg element. It would not be a big deal if foreignObject s could be nested, I think, as long as we keep the namespaces straight.

Nothing would beat interactive testing in devtools to see if it would work!

Malvoz commented 3 years ago

Is it possible to use regular (SVG) <a>? If nesting can be avoided in the output HTML/SVG? Are there other limitations? Using <a> would resolve https://github.com/Maps4HTML/Web-Map-Custom-Element/issues/392. But I guess that's been considered already.

ahmadayubi commented 3 years ago

You could use <a> but you'd need to prevent it's default behavior since the way they work in mapml is completely different for the most part. You'd sort of be hijacking what the <a> element does inside of the tag but if that's not an issue then it can probably be done.

prushforth commented 3 years ago

I don't think using a regular element achieves everything we want especially regarding custom element modularization of code, so closing for now. We'll keep the branch as unresolved.