Changes in light mode as seen by removing it from the first field, but it should be fine to fix in dark mode.

Simply removing the background is not an ideal solution as the colour was used as a visual clue that the field is read only. For the input fields it used the css below

@media (prefers-color-scheme: dark)
.form-control:disabled, .form-control[readonly] {
    background-color: var(--gray-800);
}

.form-control:disabled, .form-control[readonly] {
    background-color: var(--gray-200);
    opacity: 1;
}

Simply removing the background is not an ideal solution as the colour was used as a visual clue that the field is read only. For the input fields it used the css below

@media (prefers-color-scheme: dark)
.form-control:disabled, .form-control[readonly] {
    background-color: var(--gray-800);
}

.form-control:disabled, .form-control[readonly] {
    background-color: var(--gray-200);
    opacity: 1;
}

You are right - i think best would be to have a bg-readonly class

I have tested this item ✅ successfully on a1aac82

Thank you!

@MacJoom why all this extra CSS when you could fix everything only in the HTML side, ie:

<form action="<?php echo Route::_('index.php?option=com_messages'); ?>" method="post" name="adminForm" id="adminForm">
    <div class="card">
        <div class="card-body">
            <fieldset>
                <div class="form-group">
                    <div class="mb-3">
                        <label for="userName" class="form-label"><?php echo Text::_('COM_MESSAGES_FIELD_USER_ID_FROM_LABEL'); ?></label>
                        <input type="text" disabled class="form-control" id="userName" value="<?php echo $this->item->get('from_user_name'); ?>">
                    </div>
                    <div class="mb-3">
                        <label for="date" class="form-label"><?php echo Text::_('COM_MESSAGES_FIELD_DATE_TIME_LABEL'); ?></label>
                        <input type="text" disabled class="form-control" id="date" value="<?php echo HTMLHelper::_('date', $this->item->date_time, Text::_('DATE_FORMAT_LC2')); ?>">
                    </div>
                </div>
                <div class="form-group">
                    <div class="mb-3">
                        <label for="subject" class="form-label"><?php echo Text::_('COM_MESSAGES_FIELD_SUBJECT_LABEL'); ?></label>
                        <input type="text" disabled class="form-control" id="subject" value="<?php echo $this->item->subject; ?>">
                    </div>
                </div>
                <div class="form-group">
                    <div class="mb-3">
                        <label for="message" class="form-label"><?php echo Text::_('COM_MESSAGES_FIELD_MESSAGE_LABEL'); ?></label>
                        <textarea disabled class="form-control" id="message" rows="20">
                            <?php echo $this->item->message; ?>
                        </textarea>
                    </div>
                </div>
                <input type="hidden" name="task" value="">
                <input type="hidden" name="reply_id" value="<?php echo $this->item->message_id; ?>">
                <?php echo HTMLHelper::_('form.token'); ?>
            </fieldset>
        </div>
    </div>
</form>

0 new classes, 0 new CSS Variables and it works by default with light/dark/themed!
Bonus it's also accessible!

I have a problem. I am testing on 5.0.0-rc3-dev newly updated this morning with git pull and npm ci. I have two Super Users and one Administrator. In Private Messages: Write the Select a User field does not list any users so I am stuck. Can't test.

Agree with @dgrammatiko here

OK just looked again and actually not that easy (I guess I'm the idiot). This is the read view. We don't want the textarea being parsed as html and showing the tags when showing the user a private message. We want to render the actual HTML.

I think the mistake here is that we pretend these are form fields when they clearly aren't. This is only a form for the hidden input fields and to facilitate the reply button at the top. There's no scenario when these become editable (because the edit.php is obviously for that).

Here's a proposal #42135 of a way that removes all the input like elements and uses dt/dd's. If we decide to go back towards the more input/form like methods then do what @dgrammatiko suggested and make them formally invisible. Right now I assume that the label and elements aren't linked the way we intend them from an a11y perspective (although I assume @brianteeman knows better than me - so feel free to contradict).

I have tested this item ✅ successfully on a1aac82

Tested successfully in 5.0.0-rc3-dev of 14 October using PHP 8.2.11 in Wampserver 3.3.1, in Light mode and Dark mode in Chrome.

What to do now with this PR? It has 2 successful human tests so I could set it to RTC, but it seems to me that it would become obsolete when PR #42135 would be merged, which already is RTC.

If we want to treat this like a form field we should use formal input fields with labels as @dgrammatiko mentioned.

If we’re happy rendering this without form field style rendering we should merge my PR and maintainers or a release lead should decide which approach

Closing in favour of #42135