In our application we have some expression fields in a form which has auto-edit enabled. When auto-edit is enabled the text in this field gets greyed out like this:
We want this text to be black eventhough auto-edit is enabled. I've tried doing this with a conditional layout specifically set for this field, but even then the color gets overwritten somehow. So the next step is doing this by changing the css values.
I've checked which element and css class I need to edit the color, which are the following:
I've changed the alpha channel from 0.38 to 1 and the text color changes to black:
So I took the css class and made the change in my custom.css file. Restarted my application. But nothing's changed.
Anyone know what I'm missing? Thanks!
Best answer by Tim de LangView original
the .css- classes (e.g.
.css-bdbexzin your example) are generated. You cannot use these in your custom css since they'll change in a next build of Universal.
The reason that the text field is grayed out, is probably because it is a expression field that is not editable. This makes it disabled in universal.
You could probably say something like
Be mindful that your can put the GUI in dark mode, and then the
color: black;wouldn't look as good. We have
.lightclasses to help with that, something like
and for dark mode you could do:
Tim de Lang
Thanks for the quick response.
Good to know about the generated classes, I'll make sure to avoid those in the future. I've tried your given solution but sadly it doesn't seem to do anything to the text. I've tried changing some things, but to no avail. I've restarted my application several times as well to be sure.
that's unexpected. Can you verify a few things for me:
404errors for the
custom.css? Is it loaded and applied correctly? Do other styles in
custom.csswork as expected?
computedtab of your devtools? What CSS does it say is applied for the color property? Or does this line of css get applied and overwritten? (https://docs.joomlabamboo.com/getting-started/how-to-use-the-computed-panel-in-the-chrome-inspector.html)
Tim de Lang
There were some errors in the custom.css file pertaining to the use of !important and that the use of the textarea element before the .disabled class is overqualified. I've got rid of those to be sure and the errors are gone. There's another style change in the file that works.
This is the css that's applied to the color property:
For both the .non-edit and the .edit mode it still uses the rgba style instead of the solid black property.
This is my custom.css file:
I'd advise you to put the
!importantbits back, now your rule has less specifity than Universal's own styling, so it will never be applied. These are not errors per se, but they make it a bit difficult to overwrite the rule. But since we're overwriting other rules, that's exactly what we want to do.
Oddly enough, I also do not see that rule in your
computedtab. It should be there, even if it's overwritten. I've validated the following rule on my end, and it works for edit mode:
can you go to
https://[your universal address]/custom.css? It should load the css file. Can you see your rule there?
Tim de Lang
I've changed the css back to have the !important property. I can see my rule when I visit /custom.css:
I also see it in the computed tab now as well:
But for some reason still no change in my application:
Is it somehow because it's an expression field?
Thanks in advance.
That's progress, unfortunately the changes with
textareaaren’t applied yet (You see it's
textarea.disabled. in the computed tab) So the styles from
custom.cssare there, but they're outdated, and the problems I was talking about with specificity are coming up.
Can you try to open in in incognito mode? I think maybe some caching may be going on.
Tim de Lang
Seemed to be a caching problem. It works! Well except for the non-editable HTML-field, but I'll figure that one out.
Thanks for the help!