Token browser as expandable form, replacing modal

Interesting idea. There is only one problem, with the token browser being in a modal you have the problem that the field the token is pasted into is the last clicked field, with the token browser going into a fieldset it is a similar problem. so if you are keyboard and or screenreader user that might still problematic but i imagine it also tricky for regular sighted users using the mouse. you are in the context of the same page all the time and you dont switch between the dialog and the "main" page so how to know where to paste the token? i've linked an issue as a related issue we've summarized the problem space and provided a few potential solutions: ✨ Don't base the token insertion process solely on the last clicked field Active .... but all that discussion in this issue here as well as the discussion in the other issue about the idea of having a drop button boils down to the more fundamental question in which direction the ui of the token module should be heading which is covered in 📌 Token UI 2.0 Active . and the suggestion in this issue is one of the potential directions imho. but still that might need a bigger discussion. as a start i could put the token ui 2.0 issue on the agenda of one of the next ux meetings as well as bring it to the a11y office hours to get a few more perspectives.

[...] one problem, with the token browser being in a modal you have the problem that the field the token is pasted into is the last clicked field

That's true, I forgot about that.

What if all Token-supported fields had their own innocuous, right-aligned "Token browser" link? That way, it will be available, non-obtrusive, and the system will always know where to insert the token.

When a user clicks the "Token browser" link, the Token tree is shown, and the user can expand and collapse it. When a token item is clicked, it is entered into the corresponding field. (I had to hit Tab in my crude prototype screencast, to focus in the field)

1. A field with the Token browser link

2. The Token browser expanded

3. The field is populated after clicking a Token

MP4 file: Token.browser-each-field-expandable.mp4 →

I am attaching the crude HTML and CSS, in case anyone else want to experiment with it as well, see "4-Token.browser-each-field-expandable-HTML-CSS.txt". Simply copy paste it into the browser.

PS. Another thought: An autocomplete option would be nice, so that the user can type "date", and then [node:date-created], [node:date-updated], etc. are presented as options, but maybe that's not possible, or discussed elsewhere?

I think this may be a nice option however I would have a few concerns:

1. The modal can be expanded to the size of the screen if desired. This option would be limited to the width of the container the field is in. Consider if you had paragraphs for example where theres alot of fieldset wrappers narrowing the width. It could lead to a potential undesirable experience. That being said, if its a choice that can be made on the field then perhaps a non issue.
2. The position of the token browser link could interfere with help text. Maybe if it was something more like a contextual link thats unobtrusive could be an alternative?
3. Personally I'm fine with the modal option. I just think we need better ajax support to handle recursion or subform like i did as a custom element in my module to not lock user into global restricted depth limits: https://git.drupalcode.org/project/custom_field/-/blob/3.0.x/src/Element...

Thanks for the feedback @apmsooner, I really appreciate it.

1. About width, I envision it to automatically expand to the width of the screen. I'll add that in the Issue Summary. You're correct that edge cases could appear, where the structure of the fields might limit the max. width, like with paragraphs ...
2. The position could interfere with help text, and using something like a contextual link might be the solution. Or perhaps simply position the link right after the field? I'll add that as alternate position.
3. I think the modal feels dated, and I always need to expand and resize it, hope I clicked the right field first, check if the token got entered, etc. Also, for new users, it may take some time to understand how it works.

I concur with your thoughts and I like the idea of having options. I still think a form element that allows more options is the best solution so someone can set like 'dialog' or 'inline' as a setting and for dialog, it would be trivial to support a setting for size (ie; small, medium, large) with predefined width/height as I pointed out in https://www.drupal.org/project/token/issues/3478595#comment-15869783 📌 Improve the Browse available tokens link Active . For me, at least having the option to expose settings is critically needed. Having a default recursion limit of 3 is fine for some cases but deep nested entity reference properties can't be seen usually. Some sites may have a ton of fields so anything above 3 would be memory overload but for a smaller site or carefully modeled, setting it to 5 is no problem.

Thanks again for great feedback, I have added your mode proposal to the Issue Summary.

About recursion, I think maybe that's better addressed in another issue? Maybe you could create a Token issue dedicated to idea, if it doesn't already exist?