I guess .muted is a bootstrap class, so if your template isn't bootstrap at all (or you can shut it off like you can with uikit yootheme templates), then you DO get regular text as that class is ignored, but MOST templates use BS these days, so it's likely to always get rendered in that grey color.

I agree this class should not be mandatory. I also question whether <dl><dt> is the right HTML to surround all fields. Some fields are full blown editor fields, it doesn't make much sense for them to be lists. I would consider whether this would have an impact on SEO in some cases and certainly for accessibility markup should be used correctly. As I don't know whether I am correct with 100% certainty I am asking the question with the hope of a discussion between more enlightened people rather than providing an answer.

got wiped out of my comment

corrected :)

As for the editor being in a dl. Just move that one to another position. The dl is likely a good choice for most fields shown in that place. I don't see an issue with that.

I agree that the muted class doesn't make much sense. It just tries to mimic the article infoblock but it will be wrong for many extensions and should at least have an own class like "fields-list".
See https://github.com/joomla/joomla-cms/blob/staging/components/com_fields/layouts/fields/render.php#L60 for the line that would need changing.

By the way, the code suggests that container can be adjusted with a parameter named "fields-container-class". However that param doesn't seem to exist. It would have to be a param in the System - Fields plugin. Also the container tag itself has the same code.
@laoneo Did that get removed or forgotten?

the weird thing about it being styled to go with the Details block, is it doesn't get its own title and there's a space in there so it doesn't fully line up with the details rows. But I think maybe the muted class could be added only in the demo content or something, using the render class field and not hard coded if that makes sense.

It is like that because that's the default layout for articles here

For example com_contact is using a layout override. If a template will change that, it can just contain a layout override as well. My intention was to be inline with the com_content. But honestly I'm open for suggestion how this should be done on a better way as I'm developer and not UX.

@laoneo What about those params here: https://github.com/joomla/joomla-cms/blob/staging/plugins/system/fields/fields.php#L440-L441? Where are those coming from?

I'v used that in DPCalendar. Like that I didn't had to do a layout override just because of the different class names I wanted. But I don't know if that would make sense for the core.

Ah I see, it's the item params there. That likely will not work well as the extensions would have to support it.
Would it make sense to have that as a global parameter of the fields plugin then? At least then it would be possible to adjust the fields to a template by using different containers.

Honestly I'm not the fan of offering containers as options.

Agreed, but then we should remove the code supporting it imho.
It can be done in an override easily anyway. It's not like it's a complex layout that is going to change regulary

Absolutely agree.

Please see test this pr #13750 as it removes the muted class and simplifies the logic in the layout. Like that, extensions do need to have a layout override in place, when they want to alter the output.

Closing since we have a PR