@Himaladin i try in 2 ways:
a) two diferent custom forms
b) two diferent forms in two diferent custom screens
When CSS detect .prevent-submit are showing in any screen or form , all “Submit” labels on the app turn “unclickable”. If i added more classes ej: prevent-submit2 is the same problem, because when CCS detect any prevent class are present, turn all “Submit” buttons on the whole APP “unclickable”. I can’t change “submit” labels on forms to custom labels. Do you have any suggestions?? Thanks for your help in dvance!!!
Can you provide a screenshot of how and in which component your prevent-submit
class name is placed? If you are working in a native form, this issue should not occur. You should be using just this one code
#page-root:has(.prevent-submit) [aria-label="Submit"] {
pointer-events: none;
opacity: 0.4;
}
Have you followed the steps shown in @Robert_Petitto video?
If you use a custom form, you don’t have to use this CSS approach, as you can use custom actions to control your button.
It seems like you want to indicate that your prevent-submit is overflowing into the form and you can’t change the button label. I can’t imagine how this could happen. If you close the form, the component containing that class name should no longer exist, unless you’ve placed it on a detail page. If that’s the case, then you can’t prevent that interference, including renaming the class.
@Himaladin that’s correct, I was using it on the ‘details page,’ which depended on the form that displayed ‘prevent-submit.’ I solved it by creating a new page with a new form. Thank you very much for your help.
Yes, this interference is happening because both of your forms are still on the same screen. I might be able to add a workaround by hiding the component containing the ‘prevent-submit’ class if another component, like a spacer, is placed in your second form.
/*Hide Prevent-submit*/
#page-root:has(.preventSubmit-override) .prevent-submit {
display: none;
}
Another approach is to check the “required” option so you can hide the hint component if the condition is empty in the visibility settings.
Stopped working for me. Changed “#page-root” to “#main-root”, works again.
Others that had same problem?
I now use:
#main-root:has(.prevent-submit) [aria-label=“Submit”] {
pointer-events: none;
opacity: 0.4;
}
Still works on my side. Did you turn off “use compiled css” and turn on “Preview custom css”?
Might be why. No i “use compiled css” for other parts (has this checked on).
@Himaladin I wonder if some other codes that only worked with “preview css” might work with “compiled” using #main-root?
I’ll give it a try later when I’m back online
Are you confident that #main-root works for you? I’m testing why it doesn’t work for me. Sometimes, issues with a slow browser can disrupt testing.
Additionally, if you are using a translator, this code will not work because the button label is “Submit.” You will need to adjust it to match the existing label or add the appropriate selector.
No, the hierarchy of #main-root is a great-grandchild of #page-root. If it works, then #page-root should work as well. I suspect that :has does not apply when the “Use compiled CSS” button is enabled.
Issue with the “Use Compiled CSS” Toggle Affecting CSS Specificity
@Eric_Penn, I believe I’ve identified the source of the issue, and to ease your curiosity, I conducted the following tests with the code to set a container’s maximum width:
/*Doesn't work when the toggle is on*/
#page-root .normal {
max-width: 100%;
}
/*Works whether the toggle is on or off*/
#main-root .normal {
max-width: 100%;
}
- When the toggle is on, you can only use the
#main-root
selector instead of#page-root
because#page-root
is too broad or not specific enough compared to#main-root
. However, when the toggle is off, this limitation doesn’t apply. - Specificity is critical when the toggle is on, especially within forms. For example, code targeting
#main-root
won’t work inside a form because forms are placed in a higher DOM structure that isn’t under#main-root
. This issue doesn’t occur when using#page-root
, which is broader. - @Danny_Nielsen, the issue isn’t that
#page-root
doesn’t work, but that you need to be more precise when dealing with forms. For instance, using#main-root
is effective when working with the “form-container” on the main screen, and#overlay-root
for overlay screens. This specificity is essential when “use compiled CSS” is enabled, but less critical when it’s off.
In conclusion, it’s not that the CSS feature like pseudo-class :has
is unsupported, but that the scope becomes restricted when compiled CSS is applied. You might find that you need to maintain two sets of code if you choose to enable compiled CSS, as the toggle significantly impacts how your CSS targets elements.
In summary, there are still many codes that won’t function if you enable “use compiled CSS,” especially those outside the #page-root
scope due to the process of restriction, minification (shorter distances), and validation of the applied CSS.
Recommendation: To ensure broader and more efficient CSS application without the need for excessive specificity adjustments, it’s advisable to keep the “Use Compiled CSS” toggle disabled. This approach simplifies maintenance and expands the reach of your CSS styles.
Some CSS only works when compiled CSS is enabled. Any idea why?
I don’t have the expertise to answer the exact “why” for code that works when this toggle is enabled, and I’m not sure if any CSS preprocessors are being applied to modify the written code, as I am not working in that environment. Personally, I prefer working with raw CSS.
Do you have any opinions or answers regarding the implementation of the code you’re referring to?
Is this the code example you were referring to that I found in another thread?
div[class*="container-padding-md"] {
max-width: 100vw;
}
@Eric_Penn, if you want to run your code with the ‘use compiled css’ button turned off, just add #page-root
in front of the CSS code that isn’t working. I think this is a way to redirect your code without changing much of the code that’s already written.