Gray markers will mean that the panel contains the defined styles from the previous breakpoint, and blue and gray markers together will say that the panel contains both the overridden styles in the current breakpoint and the styles defined in the previous breakpoint (see Mixed in the screenshot).
This can help save the user’s time and help them navigate the Design tab more efficiently.
Please let me know if such a feature request already exists so I can vote and remove the current request.
What do you think about mixed markers - is it a good solution from a Ui/UX perspective or a bad one?
Having a way to visualise the inherited styles / overrides is a worthwhile request.
Two indicators side by side is not necessarily the best approach, but I like the general idea of having multiple states.
Hello @StrangeTech
How about a different indicator color (or gradient) to indicate inherited and overridden styles, and gray for inherited styles?
How do you see a more practical solution to this problem? 
Similar topic and similar proposition:
I brought @creer’s point up in a bug report a month ago (well, I mentioned it in passing, and it has also been mentioned from time to time over the years), but then deleted this point, as it wasn’t directly related, and I didn’t want to distract from the actual bug.
This is what I wrote:
So if any value is applied on other than my main breakpoint, I’m not aware of it.
I’m not making any propositions here, but I think it’s important to have something like this available.
Just out of curiousity, on separate topic but regards to these colour codes - when I pasted a html on the canvas and I have my class already in the CSS stylesheet, the class is purple. When I paste them without any existing class in the stylesheet, it was blue. When I call the class myself and had then in my stylesheet the class is green colour.
Is this correct understanding?
Hey @Aizat. It’s simple.
Blue classes are Tailwind classes.
Green classes are global classes.
Purple classes are virtual classes.
Global classes are classes that are being applied globally and are explicitly setup via the Cwicly interface inside the global class panel.
Virtual classes are basically just references. It basically can be anything, except a global or original block class.
Common use cases:
It’s your best friend in potentially dozens of use cases.
Most users just add “empty” global classes here, which isn’t the intended way in Cwicly.
If it’s not a global class (which I explained above), it’s a virtual class.
Hope that helps a bit.
And your external classes can be whatever colour you select 
thanks alot, it helps!
