mermaid-js / mermaid Public
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usage of duplicate IDs across diagrams has potential to break some diagrams #1318
Comments
|
Good point. I am in the middle of rewriting the rendering engine for flowcharts and state diagrams and I will start using this approach there. |
|
Look forward to it! Great project by the way. |
|
Maybe this is another feature request, but it would be nice if |
|
FWIW, consider the specificity of targeting |
|
Again, there is already an solution for Nodes in Flowchart Diagram, which provides possibility to name two Nodes identically, but refer and style them separately. Not sure what makes applying the same solution for Class Diagram more difficult. Or is just that different contributors works on different parts of Mermaid and do not reuse solutions across for some specific reason? |
|
The opening suggestions is mearly a suggestion, any solution that solves the issue is fine with me, but sequence diagrams use unique ids an do not suffer from the problem the opening statement shows. Sharing the ids works for class diagrams except when the first element is hidden in something like a details element or as shown with the tab implementation above. As for the These are all just suggestions, but out of the two implementations (shared ids vs unique ids) unique ids don't exhibit issues. |
|
So I spent some time on this today, and found that if create my own loader that wraps each diagram in a shadow DOM, I no longer get non-unique ID problems as the individual diagrams no longer are shared. I don't know if this is a direction that Mermaid would like to go in, but it may be something to think about if anyone has general issues with ID conflicts. I find this solves most of my issues. |
|
For more information on fralau/mkdocs-mermaid2-plugin/issues/8: with the mermaid2 plugin for mkdocs we are indeed in the process of implementing @facelessuser's custom loader, as a complement to the standard loader, to solve that issue. mermaid is a wonderful tool and superbly simple to use Let's say that it was a little like Alice's jump into a rabbit hole I know this might sound a little self-centered but I would be overjoyed if I could use mermaid, without worrying about how it works and corner cases (encapsulation). So, if we had all the javacript in a "one-stop-shop", that would make the plugin's code so much simpler. |
|
@knsv Just curious if there was any progress on this - I'm doing a routine bug sweep and it seems that this bug is still a common encounter among users. |
|
Would like to bump the above question, have encountered the described bug myself as a new user. |


Describe the bug
Class and State Diagrams all share
<def>elements with the sameidinstead of making them unique. If given two diagrams that share<def>elements with the sameid, and the first gets hidden, it can affect all other diagrams that share the same<def>ids.In this example, notice that when the Class Diagram is hidden, the State Diagram underneath loses its arrows.
This is because both the State Diagram and the Class Diagram define
<def>elements that use the exact same id. Below is an example of the<dev>id that is generated in these SVGs. It is not unique like other diagrams generate. It would be expected to havedependencyEnd<some_number>, but instead all Class and State Diagrams use the exact same id.This only works as long as the first doesn't get hidden (the only ID that the browser cares about, as IDs are required to be unique).
I imagine stylesheets would also have to get cleaned up as they are currently using things like:
You could maybe get away with something like:
[id^="dependencyEnd] { @include composition; }On a side note, using IDs in general like this could mistakenly break things in a site if a user happens to use the same ID in their document. At the very least, it may make sense to kind of namespace the ids to reduce the chance of a user accidentally using the same ID
__mermaid_dependencyEnd<number>. Something to think about.Expected behavior
All
<dev>elements should be generated with unique ids.Screenshots
See above
Desktop (please complete the following information):
Not OS or Browser specific
The text was updated successfully, but these errors were encountered: