Zoomin info messes with svg rendering somehow

Developers
#4

The arrowhead is specified by means of an ID reference. In zoom-in view, there is already an element with that same ID in the tiddler Foo that is not visible. Therefore this element when referenced via ID does not result in a visible arrowhead.

Which element is picked up in case of ID clash is browser dependent and this is a really good example of why we should avoid ID usage in TW.

#5

There has been a discussion somewhere here at Talk, that talked about the possibility to close all “other” tiddlers, if a link is clicked. … As far as I can remember there has been a solution. …

The Zoomin story-view puts the currently visible tiddler into the background and hides it, if a new tiddler is opened.

So if you find the thread I did mention, you could implement it and properly close your second tiddler. So the Bar tiddler should show the arrowhead, since it would be the only ID that is visible.

#6

@pmario - this? https://github.com/Jermolene/TiddlyWiki5/pull/3412

1 Like
#7

There has been a different discussion here in Talk I think.

#8

Is it this one.

#9

@arunnbabu81 … Yes, … Did you actually save your problem?

#10

From what I see, in both story views the SVG elements are part of the dom and in the same locations. So if it were a referencing issue I think the result would be the same
Here’s the dom with zoomin

image
image1493×457 80.2 KB

Here it is with classic:

image
image1480×435 62.6 KB

Note that in classic both tiddlers are visible so it were an issue of referencing I would have imagined it would manifest itself when both SVGs are displayed. But it is the reverse.

#11

The difference is that in zoomin view, the element being referenced is hidden.

#12

Here is an HTML file that contains nothing but the SVG elements copied twice

image
image913×293 2.99 KB

(rentame .json to .html)
svgs.json (38.3 KB)

#13

But in zoomin is where it doesn’t work.

#14

I don’t know how else to get this point across. The element being referenced in zoomin view is the hidden one. You have duplicate IDs, this is not valid. That is the crux of the issue.

If you can reproduce the problem without duplicate IDs, please report back.

#15

I checked and indeed, when ‘display’ is none is when the browser gets confused about the elements that are being rendered…

#16

There are duplicate IDs in all cases… Even when both elements are visible.

#17

I’ve reported an issue to Chrome

#18

This is not an issue with Chrome, or any other browser. The behaviour you have encountered is expected, and fully explained by the HTML/SVG specifications.

1 Like
#19

I have just had a brief look at this because their seemed to be a contentious issue and miss understanding in this thread.

On review this is my conclusion which may be wrong.

  • The mermaid plugin converts diagrams described in its scripts into html, more specifically SVG, and presents the resulting diagram.
  • When doing this, as one can see if you use the browser inspect is does so by using the id= attribute on all its various elements, although makes no attempt to keep them unique. Many id’s are in fact generic names and capturing the resulting html shows there is no attempt to make id’s different between diagrams.
  • This is arguably a design fault within the mermaid plugin for two reasons;
  • As a result of this inappropriate design choice within the mermaid code when combined with tiddlywiki single page we see unwanted artifacts.

Of note: when using the zoom in story view if you first hit close all, then open each tiddler containing a mermaid diagram the unwanted artifact do not occur in the first instance of viewing each diagram.

Options:

  • Use another diagramming plugin in tiddlywiki without this design “error”
  • Somehow try and isolate each diagram perhaps in a separate iframe (untested)
#20

Hi @TW_Tones that’s not quite right.

I’ll repeat the salient points:

  • SVG can be used in two different ways in HTML documents: as an image, and as an embedded SVG fragment (docs here)
  • Image apps like Mermaid always generate SVG images
  • SVG images using certain features cannot be embedded as SVG fragments (the relevant feature here being using IDs to cross reference within the SVG image)
  • There is no automated way to convert SVG images into a form that can be used as an SVG fragment

Nobody is at fault here; all of it is just a consequence of how things work. None of it is even TiddlyWiki-specific; theses are totally generic web development points.

#21

I am not sure what I said that “is not quite right”, if i look at the generated svg it contains a lot of id attributes set and they must be unique, and are not as soon as you display a second diagram. I am not contesting anything else you said including in your most recent reply.

I would be happy for someone to contest what I did say, if its wrong.

#22

Hi @TW_Tones indeed, I should have made clear that some parts of your explanation are correct. But the conclusion (that Mermaid is doing the wrong thing) is not correct, and your explanation omits the key technical detail.

#23

Hmmm, you’re probably right.