[FEATURE] Perspective Style Class Enhancements

I have noticed that more and more frequently, when you want to do any kind of intermediate-level css without using theming than you have to escape the style class with what feels like SQL injection with something like }.psc-MyStyleClass svg { background-color: blue;}{ in the backgroundImage prop.

i.e. the following (Note anything by @victordcq, @nader.chinichian or @pascal.fragnoud):

The question is, is there a plan to improve this experience? I feel like style classes are a bit watered down to help people that aren’t very familiar with CSS, but in order to leverage them in the designer in any kind of capability past beginner it requires this trickery, or leaving the designer completely to go into theming. Maybe an “advanced” mode in the style class builder that just shows the css for the actual style class that will be created, that you can edit directly would be nice.

I look forward to ideas or improvements that are already planned!

An idea what it could look like with some level of syntax checking, similar to in script transforms:


Here it is another example.

kgamble It will be very helpful.


chad mode :rofl:

When i first found out about this trick it was about a year ago, i believe they than said they werent going to do anything because css is to much to make something about. But maybe since they made its possible now, since more poeple seem to need it and since they recently also changed the ither script editor it might be possible now?


That would be cool and useful.



+1 yes please.

Even for simple classes I find the existing style editor slow and tedious to use.

  • Instead of just remembering property names, you have to also remember where to find them in the many pages of the editor.
  • I feel like the “Applied Styles” pane is difficult to look at. Sure it looks “nicer” than raw style sheet, but I at least have difficulty processing it quickly.
  • It takes many clicks to change a single property (navigation, property selection, value entry).
  • It’s impossible to copy/paste to speed up repetitive tasks.
  • I understand and agree with the goal of making CSS easier for new users. But, eventually, even new users are going to have to lookup external CSS resources. And when they do, some mental gymnastics are required to map existing CSS examples/resources to Ignition because of the unique style editor.

It sounds like there isn’t anything currently planned, so I went ahead and created an ideas post for this. Please go upvote to show IA how valuable this is!


We have an existing ticket that’s sort of a sibling feature to the proposal here - a ‘stylesheet’ resource, per project, where you can enter arbitrary CSS declarations plain text. I think the ‘chad mode’ proposal here (:laughing:) is probably a non starter because of the difficulty of mapping to/from user entered styles and the built in editor (if you enter something by hand that we can’t parse when you deactivate ‘chad mode’, what happens?) - but I’m also not in charge of anything in Perspective, so an ideas post is definitely the way to go.


They are slightly different, but there’s precedent for either nice GUI configuration or advanced configuration in plain text but not both. The same thing could be done here. The stylesheet resource might make this irrelevant though.

From a button action script, for example:

# This script was generated automatically by the navigation
# script builder. You may modify this script, but if you do,
# you will not be able to use the navigation builder to update
# this script without overwriting your changes.

Yes, in fact that method–where you can use GUI and then switch to see plain text it created–is actually great for newbies figuring out how stuff works. At least I found it useful for the action scripts when first starting with Ignition. There’s no need to go back from plain text to GUI. Same precedent as used in Vision action scripts would be perfect here IMNSHO.

While I agree with the above mentioned comments about “This might not work in an automatic mode if you edit it”, would you still need to put the .psc- in front of a theoretical available style sheet? Or would it also just be allowed to add regular classes as possible in the style.classes property?

The way things are currently implemented, to use these manually authored classes you would have to use the psc prefix. We take whatever you put in the style.classes list and emit it to the rendered component with the prefix, so we’d have to figure out some way to bridge that across. It’s another one of the complications with the idea.

Without looking at the code, I will say it doesn’t feel obvious why this is a requirement? Wether I name it psc-bananas or bananas I feel like it would just look at the property in the view.json and just add it as a class on the actual component? Unless its to keep the user from accidentally overriding built in classes?

I think that’s exactly why. Both for our own purposes, and indirectly (because we’re using third party libraries with their own components in various places) it’s “risky” to allow user stylesheets directly onto the page. The psc prefix is just some safety to ensure no weird interactions happen.

1 Like

For those curious by the way, this was essentially implemented, just not exactly how I asked:

A rather simple solution that, I think, would be good in addition to the stylesheet resource would be allowing users to manually enter attributes and values in the "applied styles" area of the editor. Extends the capabilities of the editor without changing the current experience or messing with an extra resource.

I find it annoying having to jump back and forth between the stylesheet and my other pre-defined styles.

There is a workaround to do this in a way:

font size : ; color : var(--error)