stereotype priorities changed compared to older implementations

Question

related to issue I found that the priority of stereotype based styles are changed.
In the old implementation the e.g. font color was defined by the order of the stereotypes near the rectangle itself. The properties of the first stereotype wins (e.g.  rectangle "==red container" <<RedContainer>><<Default>>...  defines a red font color).
The new implementation ignores the order.

@startuml
' here it works
    ' skinparam DefaultFontColor blue

    skinparam rectangle<<RedContainer>> {
        StereotypeFontColor red
        FontColor red
        BackgroundColor lightred
        BorderColor darkred
        RoundCorner 0
        DiagonalCorner 18
    }

    ' here it fails
    ' skinparam DefaultFontColor blue

    skinparam rectangle<<Default>> {
        StereotypeFontColor blue
        FontColor blue
    }

    rectangle "==red container" <<RedContainer>><<Default>> as rC
    rectangle "==default container" <<container>><<Default>> as r
@enduml

Based on that the whole Tag handling in C4-PlantUML will not work anymore.

Thank you and best regards
Helmut

Comments

A second sample which worked with old implementation

@startuml
    skinparam rectangle<<RedContainer>> {
        StereotypeFontColor red
        FontColor red
        BackgroundColor lightred
        BorderColor darkred
        RoundCorner 0
        DiagonalCorner 18
    }

    skinparam rectangle<<Default>> {
        StereotypeFontColor blue
        FontColor blue
    }

    skinparam rectangle<<GreenContainer>> {
        StereotypeFontColor green
        FontColor green
        BackgroundColor lightgreen
        BorderColor darkgreen
        RoundCorner 15
        DiagonalCorner 0
    }

    rectangle "==red container" <<RedContainer>><<Default>> as rC
    rectangle "==default container" <<container>><<Default>> as r
    rectangle "==green container" <<GreenContainer>><<RedContainer>> as gC
    rectangle "==red again container" <<RedContainer>><<GreenContainer>> as rC2
@enduml

Answer 1

I think the issue come from the fact that multiple stereotype is applied in that case.

Let's take a more simple example:

@startuml
    skinparam rectangle<<RedContainer>> {
        StereotypeFontColor red
        FontColor red
        BackgroundColor lightred
        BorderColor darkred
        RoundCorner 0
        DiagonalCorner 18
    }

    skinparam rectangle<<GreenContainer>> {
        StereotypeFontColor green
        FontColor green
        BackgroundColor lightgreen
        BorderColor darkgreen
        RoundCorner 15
        DiagonalCorner 0
    }

    rectangle "==green container" <<GreenContainer>><<RedContainer>> as gC
@enduml

Just to be sure, in that case, do you expect the rectangle to be red because the <<RedContainer>> stereotype is applied after <<GreenContainer>> ?

So this example is working ?

Thanks!

Comments

No, I have a different expectation (and this was old implementation too):

a) the finally used stereotype properties are independent of the order in the definition:
If I write

skinparam rectangle<<GreenContainer>> { ... }
skinparam rectangle<<RedContainer>> { ... }
skinparam rectangle { ... }  ... defines blue
skinparam rectangle<<BoldContainer>> { ... }  ... defines bold font

or

skinparam rectangle { ... }  .. defines blue
skinparam rectangle<<BoldContainer>> { ... }  ... defines bold font
skinparam rectangle<<RedContainer>> { ... }
skinparam rectangle<<GreenContainer>> { ... }

is not relevant for the final output

b) If an element is marked with multiple stereotypes the first stereotype wins, the next has the lower priority ...

rectangle  "C1"  <<GreenContainer>><<RedContainer>>  as C1  produces a green rectangle

rectangle  "C1"  <<RedContainer>><<GreenContainer>>  as C1  produces a red rectangle

c) if the first stereotype does not define all skinparams the skinparams of the second stereotypes are used ...

rectangle  "C1"  <<RedContainer>><<BoldContainer>>  as C1  produces a red+bold rectangle
rectangle  "C1"  <<BoldContainer>>  as C1  produces a bold+blue rectangle

Thank you for your effort
BR Helmut

---

Thanks for the examples, we are working on this.

Note that the old implementation was working by chance, not by design (!). But since it is the logical way, we are going to restore it.

---

Last online version should work better:

test1 / test2 / test3 / test4

There might be other regressions...

Thanks for your tests!

---

Thank you for the fast fix.
BR Helmut

PS.:

>> Note that the old implementation was working by chance, not by design (!)
As soon there are (big) breaking changes based on the new (styles) implementation shouldn't there be a new version number/name like "plantuml2…." (incl. new PlantUML server or even new file extension *.puml2) otherwise it could be that all dependent tools, ... are not working anymore.

---

As soon there are (big) breaking changes based on the new (styles) implementation shouldn't there be a new version number/name like "plantuml2…." (incl. new PlantUML server or even new file extension *.puml2) otherwise it could be that all dependent tools, ... are not working anymore.

Note that this new implementation is not yet released: only the online server has been updated.

We are confident that we will be able to support both versions (old skinparam and new style) at the same time. So we hope that there will be no breaking change when we will officially release it.

Supporting both versions at the same time will help users to take their time to migrate from skinparam to new style.

So if you find other issues, please post here :-)

Thanks again,

---

Thank you for clarification

BR Helmut

---

Hi,

what is the rationale behind the fact that the first stereotype is prioritized?

In CSS it's the opposite ( when we have the same degree of precision of course ).