Keep CSS rules static #179
Conversation
Signed-off-by: Giovanni Ferrari <[email protected]>
Signed-off-by: Giovanni Ferrari <[email protected]>
src/components/network-area-diagram-viewer/network-area-diagram-viewer.ts
Outdated
Show resolved
Hide resolved
Signed-off-by: Giovanni Ferrari <[email protected]>
Signed-off-by: Giovanni Ferrari <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
|
Why are the css rules that was in |
You mean to provide a default css file which corresponds to the previous rules and that could be easily imported by the user? Then it would only makes sense for the default array. But yes I agree we should add such a file, it's still handy to have a ready-to-use feature. |
Signed-off-by: Giovanni Ferrari <[email protected]>
Signed-off-by: Giovanni Ferrari <[email protected]>
Signed-off-by: Florian Dupuy <[email protected]>
demo/src/style.css
Outdated
| .nad-vl120to180-0, .nad-vl120to180-1, .nad-vl120to180-2, .nad-vl120to180-3, .nad-vl120to180-4, .nad-vl120to180-5, .nad-vl120to180-6, .nad-vl120to180-7, .nad-vl120to180-8, .nad-vl120to180-line, | ||
| .nad-vl180to300-0, .nad-vl180to300-1, .nad-vl180to300-2, .nad-vl180to300-3, .nad-vl180to300-4, .nad-vl180to300-5, .nad-vl180to300-6, .nad-vl180to300-7, .nad-vl180to300-8, .nad-vl180to300-line | ||
| ) { | ||
| display: block |
There was a problem hiding this comment.
Can't you remove all the display: block rules?
demo/src/style.css
Outdated
| .nad-zoom-1000 :is( | ||
| .nad-branch-edges .nad-edge-path, | ||
| .nad-3wt-edges .nad-edge-path, | ||
| .nad-branch-edges .nad-winding, | ||
| .nad-3wt-nodes .nad-winding, | ||
| .nad-vl-nodes circle.nad-unknown-busnode) { | ||
| stroke-width: 0.25% | ||
| } |
There was a problem hiding this comment.
this rules are common for most of the zooms, so you could have it as default, in order to see better what's changing
demo/src/style.css
Outdated
| .nad-zoom-2500 .nad-disconnected .nad-edge-path { | ||
| stroke-dasharray: 0.5% 0.5% | ||
| } |
There was a problem hiding this comment.
Please keep the rules available to projects currently using them, not just in the demo.
There was a problem hiding this comment.
As @flo-dup suggest, either as default that can be override or at least as importable rules or css.
There was a problem hiding this comment.
About the first suggestion, in fact I don't think we should put any default CSS in the component. That would mean injecting some CSS? Then how would a webpage with two components work, there would be conflicts with the two CSS?
Instead as you said we could give one or several CSS examples. But to me it's not clear how we could include a CSS file in the release.
Another simpler way to do this would be to leave the examples in the demo, and just add in the next migration guide the CSS which corresponds to the previous default DEFAULT_DYNAMIC_CSS_RULES: CSS_RULE[]. Indeed it's just a matter of migration, isn't it?
Signed-off-by: Giovanni Ferrari <[email protected]>
|
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
Fixes #154
What kind of change does this PR introduce?
What is the current behavior?
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change or deprecate an API?
If yes, please check if the following requirements are fulfilled
What changes might users need to make in their application due to this PR? (migration steps)
Other information: