Exploring the Enhanced Capabilities of Glide's Native Form

[Mauro_Ayala]

@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!!!

@Himaladin

/*Container Form*/
#page-root:has(.prevent-submit) [aria-label="Submit"] {
pointer-events: none;
opacity: 0.4;
}

/*Edit Form*/
#overlay-root:has(.prevent-submit) [aria-label="Submit"] {
pointer-events: none;
opacity: 0.4;
}

[Himaladin]

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.

[Himaladin]

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.

[Mauro_Ayala]

@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.

@Himaladin

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]

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.

[Danny_Nielsen]

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;
}

[Himaladin]

Still works on my side. Did you turn off “use compiled css” and turn on “Preview custom css”?

[Danny_Nielsen]

Might be why. No i “use compiled css” for other parts (has this checked on).

[Eric_Penn]

@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

[Himaladin]

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.

[Himaladin]

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.

[Himaladin]

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%;
}

1. 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.
2. 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.
3. @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.

@Himaladin

/*Edit Form*/
#overlay-root:has(.prevent-submit) [aria-label="Submit"] {
pointer-events: none;
opacity: 0.4;
}

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.

[tuzin]

Some CSS only works when compiled CSS is enabled. Any idea why?

[Himaladin]

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?

[Himaladin]

Is this the code example you were referring to that I found in another thread?

div[class*="container-padding-md"] {
max-width: 100vw;
}

[Himaladin]

@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.

[Danny_Nielsen]

When you have “form in form”: In second/overlay form, add seperator with class “allow-submit”.

#page-root:has(.prevent-submit):not(:has(.allow-submit))
[aria-label="Submit"] {
pointer-events: none;
opacity: 0.4;
}

I haven’t do extensive testing

[Himaladin]

Thank you for your suggestion, Danny. It seems you’ve already used the method to disable the ‘use compiled CSS’ button.

Does this mean you require the use of another class name to prevent submission in the second/overlay form?

[Danny_Nielsen]

Yeah, as you (and others) have mentioned in several threads, using “use compiled CSS” just adds more problems then it solves. I’ve changed all CSS to work without “use compiled CSS”. I now only use “Preview custom CSS”.

THE SETUP IS:

FORM → SHEET 1 (main)
I use “prevent-submit” as CSS class on multible hint/seperator, and Visibility conditions to toggle on/off. I got a button (accualy several) that “Show form screen” → Overlay to FORM → SHEET 2.

FORM → SHEET 2 (secondary)
This form is affected by “prevent-submit” from FORM → SHEET 1, it transfers over = the “Submit” button in is grey’ed out. But if i add a spacer/hint with CSS class “allow-submit” in FORM → SHEET 2, it’s fixed; the Submit button is back to normal. When i use:

#page-root:has(.prevent-submit):not(:has(.allow-submit))
[aria-label="Submit"] {
pointer-events: none;
opacity: 0.4;
}

And why use “prevent-submit” in the first place. A few elements in glide don’t have “required”, Rating is one of them. But main reason is, that my FORM → SHEET 1 is on big Custom Collection. And “required” used on components in custom Collection doesn’t work. So i keep hints with “prevent-submit” in the screen until everything required i filled out.

[Himaladin]

OK, this works by adding a spacer component with the class name “allow-submit” and applying these two codes. Thank you.
The class name in the overlay should be changed to “disable-submit” to prevent overriding effects.

/*Overlay Form*/
#page-root:has(.disable-submit) [aria-label="Submit"] {
    pointer-events: none;
    opacity: 0.4;
}

#page-root:has(.prevent-submit):not(:has(.allow-submit)) 
[aria-label="Submit"] {
    pointer-events: none;
    opacity: 0.4;
}