A slight B/C issue. If the 'Show Label' has been set to hide, once the PR is applied there is no way to un-hide the label. The hidden class is saved to the user data with no way to remove it.

@ciar4n good point. Any other idea how to make it B/C able?
hmmm...

In this case none that I can think of.

I think for now we could keep the 'Show Label' fields. Considering the 'Render Class' exists which is adding a class to the field container, I would question the need for a 'Label Class'. So my 2 cents would be to revert replacing the 'Show Label' fields with the 'Label Class' fields.

Yes, you are right, we can control the label by the render class. Just tried to be more consistent for both places. Will change it.

Looks like that now:

This works fine, but I really would like to get a Label Class when rendering.
What we have now is limited to all fields field-label

@infograf768 not sure what you mean? Can you try to explain it different, what the issue is?

In this patch, the Label Class is used when editing an item in backend.
Example adding class invalid to label:

gives when editing an article in backend:

But this can't have any effect on frontend

To be able to render a specific class in frontend, you need a new field in the xml, and then modify the files
ROOT/components/com_contact/layouts/field/render.php
and
/ROOT/components/com_fields/layouts/field/render.php

to add that class after field-label

That new field could be displayed with a showon depending on the value of the Show Label field

@infograf768 i still don't understand. The label class is only for the form (input) not for the rendering part. If you look at the options I even added headlines to clarify this.

In the first version of the PR i did quite exactly what you are suggesting but we said then to remove the label class for frontend again and to leave the show / hide field for rendering.

I still think it is quite helpful to be able to add a specific class in frontend for the label rendering when rendering Label is set to Yes. This will let using different rendering depending on the field.

The B/C issue pointed at by @ciar4n does not exist as far as I could test.
A field formerly set to Hide Label let's change it to show after my patch.

When hiding label, the render label class is just not used as the label is hidden.

This is what I have done:
Added a new field in in /administrator/components/com_fields/models/forms/field.xml (the lang strings are already in your PR) after Show Label:

			<field
				name="render_label_class"
				type="textarea"
				label="COM_FIELDS_FIELD_LABEL_RENDER_CLASS_LABEL"
				description="COM_FIELDS_FIELD_LABEL_RENDER_CLASS_DESC"
				class="input-xxlarge"
				size="40"
				showon="showlabel:1"
			/>

Added the node in fieldsplugin.php line 174 (not sure that one is necessary)
$node->setAttribute('renderlabelclass', $field->params->get('render_label_class'));

Modified /components/com_fields/layouts/field/render.php to be able to use the render_label_class

if (!key_exists('field', $displayData))
{
	return;
}

$field = $displayData['field'];
$label = JText::_($field->label);
$value = $field->value;
$showLabel = $field->params->get('showlabel');
$renderLabelClass = $field->params->get('render_label_class');

if ($value == '')
{
	return;
}

?>
<?php if ($showLabel == 1) : ?>
	<span class="field-label <?php echo $renderLabelClass; ?>"><?php echo htmlentities($label, ENT_QUOTES | ENT_IGNORE, 'UTF-8'); ?>: </span>
<?php endif; ?>
<span class="field-value"><?php echo $value; ?></span>

Same has to be done for the specific /components/com_contact/layouts/field/render.php

I get:

EDIT: if I un-hide the Label, it works fine.

The B/C issue has been fixed with 741c13d

With my patch, as explained above, I could not reproduce your B/C issue, which means we can add the render_label_class as suggested.

If you like, I can show you with animated screenshot

@ciar4n
Shall I do these captures?

@infograf768 you can define the class of the label by .renderclass label thats why we dont add another additional parameter. We start adding too much parameters again. This PR is just to be able to add a class for the label in the form in order to hide it or to do different things. it would be better of course to have the same for the Rendering too but there is already a show/hide field. Means we would need to add another field. As far i know we wanted to prevent to add too many options?

My apologies.. I thought your b/c comment was on the PR in general rather than your specific suggestion. As your suggestion doesn't remove the 'Show Label' field, I see no b/c issue with it.

Adding a 'Render Label Class' certainly makes things a little easier for alternative styling on the label. My only thought on it is that in the case of the render field, you could use the 'Render Class' field to do the same thing. The difference been that you will need to create custom CSS for the class rather than been able to use a currently existing bootstrap class.

.my-label-class label {
   // New label styling
}

or
.my-containerclass label + label {
}

it's just not a label in the rendering, i think it's a span

In fact, it would rather be

.field-label .my-label-class {
    // style
}

to target specifically the custom field markup as we would have
<span class="field-label <?php echo $renderLabelClass; ?>"

In any case, I really think we need this even if it is a new parameter.
@coolcat-creations
Would you accept to update your PR?

I can add back the class of course. that was initially what i wanted to do. Just did not want to overcrowd the parameters again.

Thanks. Will test when done.

Done :)

Also missing same changes in /components/com_contact/layouts/field/render.php

oops, was too fast doing the stuff and did not commit all files. sorrrryy

take your time, I am leaving for weekend

Agree with @Quy concerning note which means modifying both strings.

@coolcat-creations
can you do the last desired modifications so that we can test positively?

Thank you, just did the changes

@coolcat-creations
still missing the indent remarked by @Quy line 295. See above.

I have tested this item ✅ successfully on 7351e21

I have tested this item ✅ successfully on 9721f9f

Ready to Commit after two successful tests.