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.
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:
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?
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 () 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.
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.
) 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.