[FEATURE] relative paths break when embedding the SVG

[LukeLR]

Describe the bug
When the SVG image is in-line embedded in the homeassistant dashboard, relative links inside the SVG image will break, as the browser will try to fetch the resource relatively to the dashboard URL, not the SVG image URL. This affects for example raster images, which are not embedded in the SVG file.

For example, the floor plans of our rooms and lamp icons are available as PNG images, so my SVG image includes a PNG (example.png) which is in the same folder as the SVG image. When loading the SVG image directly in the browser using its URL http://<ha-ip>:8123/local/floorplan/floorplan.svg, the browser fetches the PNG from http://<ha-ip>:8123/local/floorplan/example.png. However, inside the floorplan card, the URL is interpreted relatively to the dashboard URL: http://<ha-ip>:8123/dashboard-test/example.png which doesn't work.

Embedding all the images in the SVG and using object clones in Inkscape is a workaround, but due to the base64 encoding of the embedded images, the SVG filesize blows up and slows down dashboard display. Using absolute links to the PNG on the HomeAssistant server inside the SVG is not really feasible for inkscape editing. As another workaround, I tried to rewrite the relative paths inside my SVG using JavaScript, but I can't find a way to execute JavaScript once after loading the document.

It would be great if relative links would work as expected inside the SVG image.

To Reproduce
Steps to reproduce the behavior:

1. Create an SVG in Inkscape
2. Drag an external image into the Inkscape window
3. Choose "Link"
4. Upload that SVG to your HomeAssistant www directory
5. Load the SVG directly in the browser
6. Use the SVG in a floorplan card

Expected behavior
The external image linked inside the SVG will display in the floorplan card. However, it will only be displayed when loading the SVG directly in the browser, not from inside the floorplan card.

Desktop (please complete the following information):

• OS: Arch Linux
• Browser: Firefox
• Version: 137

Smartphone (please complete the following information):

• Device: Fairphone 5
• OS: /e/-OS
• Browser: HomeAssistant app from f-droid
• Version: -

Share configuration
Please share:

• YAML:

type: custom:floorplan-card
full_height: true
config:
  image: /local/floorplan/IMG_20250402_194639.svg
  stylesheet: /local/floorplan/IMG_20250402_194639.css
  rules: []

• CSS: none
• SVG-file (IMPORTANT!) (Use gofile.io, or something simular)

If you create a issue without a SVG example, including the required YAML and CSS to reproduce the issue, it's likely what your issue will be closed, or marked as unresolvable, as it's lacking the proper amount of details. Thank you for understanding the situation.

Additional context
Add any other context about the problem here.

[exetico]

Hi,

Thank you for the bug-report. Hopefully I'll be able to look at it, in one of the upcoming days. Right now, I'm in the middle of implementing quite a few tests for ha-floorplan.

[LukeLR]

Okay, no worries, take your time! Thanks a lot :)

[exetico]

@LukeLR I'd kindly ask for a minimal example with both a SVG and a png file in it. Kindly share it in the issue description, and and notice me hereafter. Please do zip the two files, or share them at https://gofile.io/ or similar, as mentioned in the issue-template.

Update:
Oh, you've already added the SVG, but ignored the comment about sharing it at gofile. I'll see if this is enough :-)

[exetico]

Okay @LukeLR, I get your problem, but I must say, it's very user specific. And to me, it even looks like you have a option to fix it manually, by simply providing the full URL in the SVG.

Here I've tested with: xlink:href="http://google.com/IMG_20250402_194639.png"

As ha-floorplan doesn't know where you store your assets, there's really only a single option: Add a option to define your path, for images, set with xlink:href.

But, how many images do you actually need to add, where you can't just use the image_set action, or define the full path to the image?

What do you expect ha-floorplan to do, if you have a image reference like this: xlink:href="IMG_20250402_194639.png"?

I could introduce a way to add a xlink_href_path option for the ha-floorplan config, and simply split any text before the file-name (removing anything before /, it present), and add the value of xlink_href_path` in front of it. But if this is a use-case for a few images, I think using one of the suggested options, would be more than fine, instead of introducing another feature, for a very specific need 😄?

---

Note to self: The best way of doing this, would be to add the logics in loadFloorplanSvg, and simply looking for images, and replace the paths, but, this doesn't handle a case, where SVG's added with image_set, also consumes external content.

    /* Normalize all href's within the SVG */
    const svgImageElements = this._querySelectorAll(
      svg,
      'image',
      true
    ) as SVGGraphicsElement[];

    const xLinkHrefProp = 'xlink:href';
    for (const svgImageElement of svgImageElements) {
      const xLinkHrefVal = svgImageElement.getAttribute(xLinkHrefProp);
      console.log(xLinkHrefVal);
      if (svgImageElement.nodeName === 'image' && xLinkHrefVal) {
        svgImageElement.setAttribute('xlink:href', 'bob_was_here.png');
        console.log(svgImageElement.getAttribute(xLinkHrefProp));
      }
    }

[LukeLR]

Thanks a lot for looking into this! I think it would be the easiest if relative paths inside the SVG would be interpreted relatively to the SVG location. This is the default when opening the SVG directly in a web browser, or when including the SVG image in an HTML page using <object>. The referenced images are stored right next to the SVG in the www folder of HomeAssistant. In that case, it wouldn't be necessary to tell floorplan a base location for the relative paths.

The SVG displays correctly in the Web browser or in Inkscape. In general, relative paths in the SVG work out of the box, but when the content of the SVG is included inline in the HTML of the HomeAssistant dashboard, which of course has a different URL than the SVG, relative paths are interpreted relatively to that URL instead of the SVG.

The images itself don't change, they are background images of the room plan or static images of the lights. In case of the lights, a CSS style adds an overlay to the image, to reflect the dimming / color state.

I hope this helps understanding the use case. Sorry for not sharing the file via GoFile, I thought using the GitHub attachment would also be ok.

[exetico]

But, forcing a new way of defining the src of a given image, wouldn't that be a breaking change, at least for people which have previously hardcoded a full URL to a given image, or maybe with another trick?

It sounds like you'd like to have the path from image added, like /local/examples/home/, if the image key equals /local/floorplan/home/home.svg, right?

What if the given user likes to have things located at the /local/floorplan level, re-used for other SVG-files (multiple floorplans, or ha-floorplan used for other things, are a thing)? I'm not sure if, or else, how many, does use the image obj. in the SVG files.

I get the overall need, but I'm not really sure, what's the best thing to do? :-)

Let me know what you think. @OzGav Do you have some thoughts here?

Also, it's fine without GoFile 😄. Back in the days, SVG could just be a bit buggy in the discussions-area. But apparently it's not really the case anymore (?).

[OzGav]

I do often embed all my images and yes the file does get big but that is why the cache option was added.

An alternative solution would be to just place empty squares in the SVG and then use the image_set action to load them as needed. The advantage here is you have full control over the placement of those images which meets the option of an image used for a single floor plan or across multiple. I do this as well.

So not sure if a breaking change is warranted if there is a valid method to achieve the desired result?

[exetico]

I've just noticed that Trzinka does mention his setup here: #411
Here a href and xlink:href are added, pointing to /local/img/fp/background.png.

Introducing a feature without user control, would break his setup, and I'm sure other people are doing the same. As ha-floorplan offers a way to customize SVG-files, and not really trying to restrict how to store files in the local / www area, I'm sure it's done in plenty of ways, already 😄.

I'm personally more into a method, where the user defines a path for images, like image_resource_prefix:, and if defined, ha-floorplan will simply prepend the test-string. Maybe even reusing the host information, and generate a full URL like https//ha-destination/local/img/fp/background.png.

I do get the nice thing about having a given image rendered in InkScape, while working with the graphical elements, instead of a white box, or similar.

[OzGav]

Yes an optional key should allow this without affecting existing users

[LukeLR]

Thanks for looking into this! This does not need to be a breaking change at all. Absolute paths (fully qualified URLs including protocol / hostname) and host-relative URLs starting with a / (e.g. /local/...) work fine, so they don't need to be changed. Only relative URLs, that means URLs that don't start with protocol / hostname or a /, need to be fixed. So everything that worked so far will remain working, only the relative paths that didn't work before will start working. Of course, it still wouldn't harm providing a configuration parameter to disable these.

[brandon-fryslie]

tl;dr: Type this into ChatGPT for an explanation and a few solutions: 'Give me an overview of absolute and relative path handling (loading external resources, NOT drawing paths) in iFrame and SVG.'

When you're working in a web browser, relative paths are always determined against the current URL. That would be the URL you have loaded in the browser, whether it is HA or the SVG. This is working as expected.

Even if something seems like an 'easy' fix, it isn't. Every added feature makes more opportunities for bugs, more potential support requests, and restricts the freedom to fix/implement other stuff in the future (more code = harder to change). It's worth evaluating a problem and figuring out whether the ongoing maintenance cost of a solution is worth it by asking: how critical is the problem? Is it blocking anything? Are there workarounds? Does this problem break user expectations or compatibility with other software? In this case I would say the issue does add a bit of friction, but doesn't completely block any use case. There are several easily achievable workarounds. And although it is inconvenient, this IS how I would expect it to work from a web developer point of view. This is how iFrames work too, so if it worked differently it would be inconsistent and unexpected.

Solutions

You have a variety of options:

• Use absolute paths. This is personally what I'd recommend as it's the least faffing around. If you can access your HA instance over the internet this should already work with no additional configuration
• Use an event handler (eg, by putting javascript in the onerror tag) to dynamically fix the URLs
• Load the SVG in an object tag or embed tag

For more options check out the following links:

• https://stackoverflow.com/questions/4476526/do-i-use-img-object-or-embed-for-svg-files/4482962#4482962
• https://css-tricks.com/svg-fallbacks/
• https://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SVG_in_HTML