Can you add a screenshot of what you put into the checkboxes options? I don't understand it from your description.

Yeah, after I posted I realized screen shots would help immensely. I'll shoot some now and post them. In the end, this is less about this specific issue and more about trying to make custom fields as useful as possible out of the box before users have to resort to overrides.

This first image is what happens if you put a space in the label field, and put something (in this case the word Verified) in the "Text" value field and put in "icon-ok" in the render class field.

You can see it renders the field label wrapper and : symbol, and stacks everything, but you DO get the icon (a check mark).

This next one was a test of just putting bootstrap icon code into the "text" value field like this:

Again I used a space in the label field. Here's what renders on the front end then:

But, here's what renders in the article edit on the fields tab:

Here you can clearly see the admin rendering the check mark code instead of just printing it, and of course since I didn't use a label so there's no label.

On a side note, I'd love to either see label not be required (and not render when empty) or better yet, an option to not show the label for that field when it renders (so you still get a label in the edit screen).

Here's if I do the same exact thing, but add the word Verified after the icon code I first placed in the text field.

And here's my browser, modified to remove the field label code and render the icon code properly:

You can see how handy it would be if the code was rendered and the label could be removed.

An update to this, the regular text type field also does not render HTML in the field. The text area does, but not the single text field. The reason I bring this up is one COULD use the regular text field, set it to read only, turn off the label (if it was an option) and stick

Here's a link to a related issue I made this morning regarding turning off the label on the front end:

https://issues.joomla.org/tracker/joomla-cms/13707

One last comment, if we make the text field render html, the "default" field should also render it.

Is this related to the "filter" option? If so, it's clearly not working, or it's saving html but still not rendering it properly.

I guess the problem is security as you can put like that HTML into Joomla very easily. But I don't know exactly how the filtering settings of Joomla do come in place. @mbabker any concerns when we remove htmlentities from here https://github.com/joomla/joomla-cms/blob/staging/plugins/fields/checkboxes/tmpl/checkboxes.php#L30?

On the one hand, you CAN get html using the text editor, but the default editor strips dangerous stuff (whereas JCE has to be set to allow scripts and things). On the other hand, it probably is still a safe thing to scrub it from the basic fields. I was just looking for any creative ways to use the fields without overrides, which could be used to encourage users to try them out.

If my other suggestion gets picked up (ability to turn off the label) at least it's getting close to letting you use a checkbox to turn on an icon since putting the icon class into the render class DOES display it. The only issue then is, it stacks the icon on top of the checkbox output.

Interestingly enough, if you use UiKit instead of Bootstrap, using an icon class in the render class field DOES render it all inline, it just puts that label in there. I think we can close this, but I'd REALLY love support for this:

https://issues.joomla.org/tracker/joomla-cms/13707

To me that sounds like creative hacking of the fields ?
Imho it's a perfect usecase for an override or even a copy of the respective field plugin (which can be reused across sites).

The problem is, I was given the task by the UX team to come up with some real world scenarios WITHOUT overrides. So I was trying some creative ways someone might try to use them without an override. I can't even resort to custom css for these. :)

Going to close this as honestly I'm probably the only person who will ever try this. ha!