List field "allowed values list" strips HTML from label

Bumping target issue, adding tags

@greatmatter Description is not clear for me, could you please attach the screenshot.

@fazni please avoid assigning Novice issues (see https://www.drupal.org/node/1319140 for details).
Trying to reproduce the issue (and provide screenshots) could be one possible way to move this issue forward.
Thank you!

@valthebald, thank you your feedback is important, I don't know too much about the policy.

I add somthing like that drupal.org|<b>drupal.org</b> in field allowed HTML
At level of HTML ( I inspect elements) of select it will be stripped "<select><option value="drupal.org">drupal.org</option></select>"

At level of page (front-end/display) the style(css) of the <b> tag will be applied.

I would say this works as intended.
The html is not displayed in the label on the node form (I believe this is correct), but is respected on the front-end.

Working on this from Drupalcon Amsterdam

It might be still a issue in the node edit form because it might be difficult to separate values when you have multiple values there with different tags. A simple example where is difficult to separate values without HTML in the admin form:

I can see this being beneficial. But I have concerns for tags such as the anchor.
This could potentially render the list unusable.

Image tags would also be a problem.

As suggested, we could strip the href from the anchor but with the image we could have a really horrible looking drop down.
I appreciate these are edge cases but I'm concerned we will be introducing the potential for more issues later on.

So it looks like adding html to the `option` tag is invalid mark-up.
As discussed on SO:
can I use html tags in the options for select elements
This make me even more nervous for going against standards outside of Drupal.

I would consider this issue as 'works as expected'.

When HTML tags are showed in the edit view it's much more useful.
An example where tags are displayed and attributes are removed.

I fail to see what is there for review. It looks to me that there is a discussion going on and there is neither consensus on the problem nor on the solution.

Please do update the issue summary with the problem and proposed solution.

I feel people will rarely use allowed HTML tags for listbox. However since we explicitly mention allowed tags this issue needs to be addressed. I tried adding only image tags and it came up with blank values in the form making it difficult to choose.
We should decide on how we display this in the form. can some UI person help on this

Adding UI tag so that some UI expert can suggest alternatives.

As stated in #13, the option tag cannot contain markup.

So it looks like adding HTML to the `option` tag is invalid mark-up.
As discussed on SO:
Can I use HTML tags in the options for select elements?
can I use HTML tags in the options for select elements
This make me even more nervous for going against standards outside of Drupal.

The issue I see is that the list field type is working as intended but the description is confusing in saying that the label can contain markup. This is the same for the float list and integer list. I suggest that this line in the description is removed.

I created the patch to change that I proposed.

@greatmatter, @darrindeal : After adding the latest patch provided by @darrindeal, I still can't see the HTML tags are applied.
Is it possible to add the steps to replicate the issue?

As mention in the #13 we can not add html tags to options in list field.
@tanubansal #20 patch is to remove the description which was invalid and confusing.
Patch works perfect for me, +1 for RTBC.

After adding patch #20, tested via below mentioned steps :

Add a field of any type, but choose "list"
In the "Field Settings" tab, there is a line of text in the description that says "Allowed HTML tags in labels
Add any of the aforementioned HTML tags as a label
Go to the Edit form for the content type
Observe that the list item has the HTML stripped out.

Description text has been removed and updated
This can be moved to RTBC

Applied patch #20 and it works fine.The misleading description is removed after this patch.
Screenshots

before patch:

after patch:

Would be useful if someone could update the issue summary since it took a while for me to figure out what this issue was trying to change.

Tagging for subsystem maintainer review in case they want to provide feedback on the solution.

I think we should retain the text but clarify that it is only used in display mode, not form mode

I agree that the allowed tags list should be kept, but that a warning should be added to clarify that any tags are stripped from select options as per HTML specification.

However, one clarification: HTML tags are allowed in labels, not only in Display mode but also in Form mode, if the field widget is set to Check boxes/radio buttons.

Rerolling the patch #20 as it does not getting compatible with the current version 10.1.x, so i made it updating the patch and now its applied perfectly. updating the reroll_diff along, And hold it to the NW as #29 suggest.

Removed unused statements, Attached interdiff for same. please review.

Updated the IS without verifying if the bug still exist.

I think it is still a good novice issue so I will keep it on the list for the mentoring team for Vienna.

The Drupal Contribution Mentoring team is triaging issues for Drupalcon Vienna 2025 and we are reserving this issue for Mentored Contribution during the event. After 17th of October, this issue returns to being open to all. Thanks!

I am removing the Novice tag from this issue because I am a little confused about what I would be verifying based on the steps to reproduce after trying to follow the issue comments. It is possible that this is Novice, but I think it would need a bit more clarity in the steps to reproduce section of the issue summary based on some of the comments with screenshots.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is...