Where would we get the list of default renders from? Use something like com_content does?

I would say from the core folder and from the templates folder, which I do believe is the same thing com_content does:
/components/com_fields/layouts/field/
/templates/[your_template]/html/layouts/com_fields/field/

any Opinion @tonypartridge?

Any update on the possible implementation of this?

I'm totally looking for a feature like this so i can style my default rendering. Also would be very helpfull to create auto overrides of specific fields i guess.

@coolcat-creations Hope you don't mind me tagging you, I saw you're active in the development of com_fields, what do you think of this?

If you have a look at my travel field experiment you see a solution for having different render layouts without having to modify joomla core.
I presented it at Joomladay Germany in English. Have to check if the video is already online. http://travel.custom-fields.net/

I presented it at Joomladay Germany in English. Have to check if the video is already online.

@coolcat-creations Hello Elisa, also interested in your presentation. I thought video uploads were finished. Just found 2 videos marked as "private". Any news or clue?

I checked with the video team, it will be uploaded at sunday - sorry for the delay!

Not sure if you misunderstood - I know we can already create different render layouts and use them when we manually insert a field individually in an article.
What I'm talking about with this issue, is having the option to choose (for each field) - between the layouts you created - which is the default render layout that is used by default when the field is automatically displayed with the Automatic Display feature and when is inserted as part of a Field Group.

@AndySDH Yes I think I understood, maybe the video makes it more clear how I solved to chose another layout for the field in the Field options. Disclaimer: This session was planned absolutely as a workshop but just one person of a lot appeared to actually code with me, so I had to change the plan and improvise and present more a showcase than a workshop.

https://www.youtube.com/watch?v=vWhR2wtXetI&t=598s Between minute 10 and 13 you see how i solved to setup different layouts in the field itself. Feel free to contact me personal if you have questions.

@coolcat-creations Hey Elisa, I saw the video, that looks great!
That looks to revolve around building custom sublayouts for a brand new own-custom field though... which looks fantastic but I'm afraid it's not in the scope of this issue.

What I'm talking about is taking advantage of something that it's already in the core of Joomla for the native custom fields. Just adding an option for something that is already built-in.

With the Joomla Native custom fields, you can override the default render.php layout in these folders:

/components/com_fields/layouts/field/
/templates/[your_template]/html/layouts/field/

So say you create a foo.php file. Then, when you're in an article, you can do this:
{field 1, foo}
And the field will be displayed with the foo.php layout instead of the render.php layout.

This you can already do, when you manually insert a field in an article. See this: #15027

The problem is, you have no control of what layout you want to use when you use the "Automatic Display" feature. It will always use the render.php layout. You can choose your own layout when manually inserting it, but not the default layout used with automatic display.

Maybe @Bakual can help us here since he made this feature?

The problem isn't so much using different layouts. Creating a select where you can choose the layout is the real problem. For the content plugin, I didn't have to deal with that part as the layout is just written manually by the user. For an automatic display, you would have to create that list where the user can choose from.

In the end, I think an override can achieve almost the same.

@Bakual Thanks a lot for your reply :)
It depends though, because by using the content plugin you have to insert each field manually one by one.
That means that if you have dozens of fields to display in each article, it gets hard/not practical to mantain if you have to manually insert the content plugin code for every field in every article.
When you could just use automatic display and display them all in all articles (of the desired category).

If the dropdown select is too hard to implement, even a text field would suffice...
"Use Alternate Default Render Layout?" and then in the text field you input "foo", and that field will always use the foo layout when displayed automatically (unless overridden in the content plugin).

It would be a really useful feature.

By "override" I didn't mean to use the plugin. You can override the automatic display layouts already. You can even have an override specific to a certain component (eg com_content) only.
If you need to more differentiate (eg based on category), you could do that in an override and put some more or less hardcoded logic into it. Not exactly as flexible but possible.

If the dropdown select is too hard to implement, even a text field would suffice...

Imho a text field would be a horrible UX. It has to be a select. And for that, it would have to lookup I think four different folders and look for files there. Those files would need to follow certainy, yet to be defined, naming conventions.

Ah yeah I get what you mean. Simply override render.php. But the override would apply to all fields... It wouldn't be that useful. The usefulness for example would be...

A field called "Price". You want it to display with proper separators with number_format($value). So you create a layout with that and you assign it to the Price field.
A field called "Color". You want it to display with <span style="color: $value">$value</span>
A field called "Flag". You want it to display with <img src="$value">
etc... So there are huge benefits in having a field option vs an override for all fields...

Unless there is someway in the render.php override to hardcode a conditional logic based on the ID of the field? I guess that could be a manual workaround...
I agree that a text field would be a bad UX and it would need to be a select, I only proposed it because it still would be better than no option at all haha.
Hopefully a select can be implemented sooner rather than later :)

I've put together #18571 which should do what you want (I think).

Closing this issue since we have a PR.

Awesome!