Problem/Motivation
The Token browser dialog modal has worked well, but can also be a bit slow to use, since you almost always need to move and resize it, before finding the right token. For some users an inline expandable form by each field may be preferred.
Steps to reproduce
Use the Token browser dialog modal, and need to resize and move the modal continually.
Proposed resolution
We could make the tokens available via an expanding form, directly on the page under each Token supported field, to allow immediately scrolling down through the available tokens. This will lead to several improvements in the UI:
- There is no need for resizing and dragging the dialog modal
- A lot of tokens can be immediately visible
- There is no longer a width problem, where token lines break
Token browser GUI
See Token.browser-each-field-expandable.mp4, and images below for a mock-up.
1. A field with the Token browser link

1.1 Alternate position, after the field
To not interfere with help text ... or maybe inside the field?

2. The Token browser expanded
It's not very wide in this mock up, but it should expand to the full width of the screen.

3. The field is populated after clicking a Token

Two modes, Inline or Dialog (Token browser settings)
A new Token browser settings page should support different display modes, allowing a user to choose between "Inline" (via each field) or "Dialog" (current dialog modal). The "Dialog" mode should support a setting for size (ie; small, medium, large) with predefined width/height (25%, 50%, 100%).
The new Inline expandable form should be set as default going forward, while allowing those who still want the modal to switch to that, so the modal might stay as an option under Token settings.
Token browser settings

Token browser settings, options

Remaining tasks
Decide if it's a good idea, and if yes, create the feature.
User interface changes
Token browser now offers an Inline expanding form, under each field, and keeps dialog modal as an option.
A Token settings page is added under /admin/config/system/token.
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 8.2-Token-settings.png | 29.23 KB | ressa |
| #8 | 8.1-Token-settings.png | 24.33 KB | ressa |
| #6 | 6.1-Token.browser-link-after-field.png | 5.77 KB | ressa |
| #4 | 4-Token.browser-each-field-expandable-HTML-CSS.txt | 158.93 KB | ressa |
| #4 | 4.3-Token.browser-each-field-expandable.png | 62.75 KB | ressa |
Issue fork token-3489325
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
ressaComment #3
rkollerInteresting 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: #3478554: Don't base the token insertion process solely on the last clicked field.... 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 #1229568: Token UI 2.0. 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.
Comment #4
ressaThat'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?Comment #5
apmsooner commentedI think this may be a nice option however I would have a few concerns:
Comment #6
ressaThanks for the feedback @apmsooner, I really appreciate it.
Comment #7
apmsooner commentedI 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. 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.
Comment #8
ressaThanks 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?