Hi, a nice CSS trick thanks to @ThinhDinh to submit an Edit screen even if required choice components are not selected.
Use case: in an Edit screen, wish to display many choice components in bar for UX matters (instead of dropdown menu), but with 5 items.
→ This implies to make the choice component required, even if it is not mandatory in reality
→ This implies that the User is unable to submit/done the Edit screen if each component have not been selected.
Has anybody figured out how to apply CSS to a specific button type (solid, transparent, border only) without using the class name (ex: .ijHjak)?
My buttons also have visibility so it appears nth-type(#) changes based on which buttons are visible to the user as one person might have 8 buttons and another might see 10.
Yes, this is a key point anyone should take into account every time you use a position-specific CSS.
You would have to do a math, then a template OR have the right conditional visibility conditions for each type of user, taking into account every element on the screen.
I guess I’ll have to wait until Glide implements button specific classes. There is [data-test=“app-button-view”], but that effects all button types and not a specific type of button.
@Jason Maybe we can do like [data-test=“app-solid-button-view”], etc for each button type? Could be a good item for the next Live session!
That makes A LOT of sense! So in theory, if you rename the Button 1 component “Hello”, it would get a class name of like “button-hello”, which you can then use with CSS to target that specific button.
Why is it that sometimes, and with some CSS, the components in the editor look different in the real app? Some times the position of the component is different than in the real app.
My guess would be that it is browser-specific behaviour. CSS is a black art (at least to me), and getting it to play nicely with all browsers can sometimes feel like an endless game of whack-a-mole.
Due to the fact that the float button has the customizable title attribute which is normally used as a tooltip, we can use this to select exactly that element.
Wait a few minutes … I’m sharing an app that I wrote as an exercise.
@Joe_Gabriele Copy this APP, the concept is very simple.
If you want to customize a button you can edit its style in the “Button Types” Tab of this app.
Dear @Jason it would be incredibly much easier to select any component if we could have a programmable attribute (even better if dynamic) as is the case with the floating button.
Perfect thank you so much! Ill have to try this later to see if I can get it to work how I need to. This could save a lot of frustration! Guessing to change it from a floating button to a normal one, I can just manipulate the CSS?
Currently I use a solid button (first), multiple transparent buttons (middle) and a border only button (last) to create what I currently use:
Of course you can manipulate the CSS in every way, but unfortunately the DIV element of the normal button does not have the title attribute (as it has the float button instead).
So we lose the fact of being able to select a specific button, and we can only select all those present in the detail screen using the attribute: [data-test = “app-button-view”].
Or, at least I can’t do better than this…
Hey Roldy, I tried the floating button and its working, sort of. Any idea how to not make it floating? Also, if I have 2 floating buttons, the last one, which I am trying to manipulate, always stays at the bottom.
No idea about the possibility of making them non-floating because in the detail screen (DOM of Glide), the parent element of the floating buttons is different from the parent of the non-floating buttons (and all other components that do not float). This is the reason why it is not possible to make them non-floating by hooking their ordinal position to that of the non-floating elements.
Also, according to my knowledge, with CSS it is not possible to change the parent of a child element; it could be done in javascript but we can’t use it here.
However, you can change the position of a floating element, but only considering the screen size. You shouldn’t have any problems doing this, as for each floating button you can express the positioning in a fixed way by specifying with the TOP and LEFT properties the coordinates of each in pixels of the screen or as a percentage of the screen size; for example like this:
position: fixed! important;
top: 50%;
left: 50%;
Of course this is an inconvenient solution if your APP is intended to be used in devices with possible different screens (as most of the APPs are); so I do not recommend it because it is not fully responsive to the contents of the app detail.
I have a case where it is fine, but it concerns a scenario where the size (resolution) of the monitor is predefined and has no scrolling.
Definitely, I believe that the customization normal-button problem would be perfectly solved if we could selectively work with normal buttons: it would be enough for the Glide developer team to add a customizable attribute to the normal buttons as they did with the float buttons thanks to the title attribute.
Maybe I have dwelt a little too much and maybe we went off topic … let’s continue elsewhere in case you need it.
