Good ... afternoon (darn, it is late)

Can you think of a better way to render a referenced SVG-file in HTML scrollable ?

The only working solution for me is inline SVG, which means that the XML-code of the SVG image must be copied into the page, preferably as the child to a block-tag (e.g. <div/>).

As I have many pages with always 1 SVG image (making up almost the whole page), I can automate the creation of the page with a script and a template HTML-file (preferable) or with a javascript replacement for actual HTML-code (not good).

What I would have preferred, is no inline-SVG at all, but an <object/> tag. Unfortunately, when I dynamically set the height for the container-tag according to the screen and have already set the overflow style (auto or scroll), upon page-load, the scrollbar appears for only a moment, then disappears (a fixed height in the style of the container has the same effect).

For me, the object tag does not use up enough space or none at all inside the container block element, no matter what is its content.

The Web already tells me: Forget it!
But most of the pages I read are a little old and do not really focus on scrolling SVG. Maybe you know better.

Not that I would script this to produce static pages with inline-SVG, but ... really! Calling that a necessity is cruel and the ugliness of the procedure just appalling.

Do you really need code? The importance is more on the catchwords, above, I would say. And I want to make it clear. Please rather inform me, where my description is lacking precision.

TY a lot!

Yes!

Actual code will explain what you're after in far fewer words/bytes than your description of that code, and reduces the number of questions that need asking.

Post the simplest working example you've got using inline SVG, then the equivalent but broken non-inline version.

Does it work with other image-types?

In the examples below, that I have prepared explicitly for this post, everything works, AFAIS, as I expected.

Difficulties arose during the creation of those pages:

• The SVG-files that Inkscape creates, use the svg namespace for most tags and attributs, also xlink is still used as namespace for the href-attribute. I had to eliminate all these namespace designators.
• A default height for the container tag (<div/>) had not been overwritten by the onload-function. I still do not understand this issue. But eliminating the style attribute “height” from the CSS section on top, has corrected this, scrolling makes sense, now. I still do not deem this correct behavior.
• Edit/addition: stroke and stroke-width are set inline by Inkscape (with values 'none' or '0'), where there is no visible stroke in Inkscape. You find these details only in the XML-code of an SVG file. If I am not erring, CSS will not overwrite these inline-attributes.

What remains of my original post and problem description: It appears to be impossible to just store an SVG-file from Inkscape and then to reference it in an object tag, like in the first example. There is in any case, a lot of XML-manipulation necessary before this works. Automated generation of several such HTML-pages, as a consequence, appears to be almost (correction) impossible.

But automation was at the origin of my current endeavor.

Example pages:
1. external SVG-file:

HTML: https://www.uplawski.eu/div/svg/page1.html
CSS: https://www.uplawski.eu/div/svg/svg.css
SVG: https://www.uplawski.eu/div/svg/page1.svg

2. Inline SVG:

HTML: https://www.uplawski.eu/div/svg/page1b.html

Mark this thread by pushing the SURRENDER button.

1 members found this post helpful.

The issue in the title is solved (SVG/HTML), but not for SVG-files ex Inkscape.

Maybe something like this?

You lose interactivity with the <img/> tag. Inline-SVG and the object tag are recommended for that. Both have caveats and/or advantages, I am in the middle of a quest... and maybe will sort out some of it. Sometimes.

Maybe something like this?

In your opinion, how is that different from my example with the external SVG in post #4, apart from the inline-style?

There is one advantage in your example: You can have a javascript-routine overwrite the default values for height and width. With a centralized style for id or class, I have not succeeded in doing that but have eliminated the defaults. I should replace one CSS-class by another, instead.

But maybe you see other things, which I do not.

(I admit I really don't understand what you wish to accomplish, and if you succeed or not, and if you succeed what was the solution.)

That remark would have helped the thread from the beginning.

What I want, is a scrollable SVG that I can style with CSS (and javascript). See question on top.
What I did was create SVG in Inkscape.

This did not work.

My hand-knitted examples in post #4 are achieved by manipulating the SVG-file prior integration in HTML.

I cite myself:
The “solution” is none as I still need to manipulate the XML-code of an SVG-file. This can be a lot of work if you want several such pages. I can try to write routines which automate all these processes, but go in favor of filing a feature-request for Inkscape. Bug-reports for the xlink-namespace have already been taken into account.

I venture, that a “Web-compatible” or “HTML-integratable” SVG type should be produced, as an alternative to all the others.

Edit: I found out about the extension which creates css-classes to replace common inline-styles on selected objects in Inkscape. But for the time, I cannot produce nice results with this function, as I have to adapt my own workflow again, to use it. It is anyway not a solution to the core-problem. Part of it, maybe.

On further thought, I should have posted this in “Software”, rather than “Programming”. The question would have boiled down to:

“How in hell can I transform a programming problem into the Inkscape-usage problem that it should be?”

Edit: There is an old feature request on GitLab which is of such general nature that it covers my concerns as well.
Edit II: ... or not. New feature request.

1 members found this post helpful.

The objective of this struggle is here.