# Style Class Custom Element State **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [October 5, 2021, 3:58pm UTC](https://forum.inductiveautomation.com/t/style-class-custom-element-state/51620 "2021-10-05T15:58:38Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![franklepkowski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/franklepkowski/32/4808_2.png) [@franklepkowski](https://forum.inductiveautomation.com/u/franklepkowski)\ **Post date:** [October 5, 2021, 3:58pm UTC](https://forum.inductiveautomation.com/t/style-class-custom-element-state/51620/1 "2021-10-05T15:58:38Z")
Hello, Looking to define a style class for a device, say a motor. This device will have 4 states, each of which I want a different fill color for. I would like to create a single style class called “motor” and use a custom element state to define 4 different sub styles which vary by fill color. Any ideas on this? Thanks, Frank ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 5, 2021, 4:23pm UTC](https://forum.inductiveautomation.com/t/style-class-custom-element-state/51620/2 "2021-10-05T16:23:56Z")
CSS states are ‘hardcoded’, and custom state sets are an [experimental feature](https://wicg.github.io/custom-state-pseudo-class/) only supported on [Chrome & Chromium](https://caniuse.com/mdn-api_customstateset) derived browsers. Even if you could define custom element states, how would you pass in which ‘state’ a motor should be in to the component, and how would that differ from just selecting a given style class? ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [October 5, 2021, 4:46pm UTC](https://forum.inductiveautomation.com/t/style-class-custom-element-state/51620/3 "2021-10-05T16:46:41Z")
This may not be exactly what you’re looking for and slightly off topic, but… What I do in my device udts is create two memory expression tags that hold the descriptive states of the mode and status of the device. For example, the status tag from the plc might be an enumerated integer where 0=stopped,1=running,2=Faulted. The ‘StatusDesc’ tag would evaluate to the descriptive state. Then, I have P. Styles for Device/On, Device/Off, Device/Faulted, etc. which are generic for any device status. To use them in my device graphics, I simply bind to the style.classes looking at the descriptive status and use a map transform to assign the style, e.g. ```auto value return Stopped Device/Off Running Device/On ... ``` This effectively abstracts your plc logic (the tag enum or combination of multiple tags) with your graphic logic. The graphics only care what descriptive state it’s in which is determined now by your UDT tag, and now you’re free to use your graphic templates for more than just a device which adheres to the same plc tag logic for those states ---
**Author:** ![franklepkowski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/franklepkowski/32/4808_2.png) [@franklepkowski](https://forum.inductiveautomation.com/u/franklepkowski)\ **Post date:** [October 5, 2021, 4:53pm UTC](https://forum.inductiveautomation.com/t/style-class-custom-element-state/51620/4 "2021-10-05T16:53:15Z")
Hi guys, Thanks for your replies. I guess I am just so used to the vision style customizer. Old habits die hard! ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [October 5, 2021, 5:03pm UTC](https://forum.inductiveautomation.com/t/style-class-custom-element-state/51620/5 "2021-10-05T17:03:01Z")
What the style customiser lacked though is the ability to globally define styles for common things and especially the colours used. Although you can use a cell update binding to bind colours stored as RGB/HEX inside of client tags, cell update bindings are awful to actually use as they can only bind to properties and not tags. To be honest though, the style customiser isn’t that different to a map transform that returns style classes. ---
**Author:** ![franklepkowski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/franklepkowski/32/4808_2.png) [@franklepkowski](https://forum.inductiveautomation.com/u/franklepkowski)\ **Post date:** [October 5, 2021, 5:10pm UTC](https://forum.inductiveautomation.com/t/style-class-custom-element-state/51620/6 "2021-10-05T17:10:17Z")
I agree being able to globally set these is a big plus. Thanks again guys