Improve indentation in hierarchical select lists

Wouldn't it then be better to use the "box drawing" Unicode characters?

So instead of

one
— oneone
— onetwo
—— onetwoone
— onethree
two
three

you'd end up with

one
┣ oneone
┣ onetwo
┣━ onetwoone
┗ onethree
two
three

… but let's look at something more complex, where we can choose to handle deeper levels in one of several ways:

one
┣ oneone
┣ onetwo
┣━ onetwoone
┗ onethree
two
┣ twoone
┣ twotwo
┣━ twotwoone
┣━ twotwotwo
┣━ twotwothree
┗ twothree
three

or even:

one
┣ oneone
┣ onetwo
┣━ onetwoone
┗ onethree
two
┣ twoone
┣ twotwo
┗┳ twotwoone
  ┣ twotwotwo
┏┻ twotwothree
┗ twothree
three

I think that "box drawing" #5 will be a bit of overload but more importantly may look nasty with quite so many web fonts (with optimised or stripped character sets especially).

Then think about all possible CSS styles, line heights etc. etc...

#8: good point! Let's go with #4.

Please provide the possibility to choose the character at least in D8!!

I still don't know how to hide horrendous dashes in my hierarchical views exposed filters..
On admin interface is ok, but on a long select field for site users, searchable with js (Chosen in D7), is often stupid / ugly.

I am not really sure if I can form an opinion on this. The dash and spaces look much more cleaner.

The box characters is interesting, but I am doubtful about its rendering in other browsers and accessibility.

I pick up this one trying move forward to get into the 8.8 release hopefully. First I tried to use the patch from #15 to see if it works on 8.8.x-dev version?

Result of $ git apply ~/Desktop/core-proper-dash-2384203-15.patch can be broken down to that 9 files, sorted into separate cases:

Patch failed as it does not apply

1. core/lib/Drupal/Core/Menu/MenuParentFormSelector.php: at line :72
2. core/modules/book/src/BookManager.php: at line :367
3. core/modules/taxonomy/src/Plugin/views/filter/TaxonomyIndexTid.php at line :189

No such file or directory

1. core/modules/taxonomy/src/Plugin/Field/FieldType/TaxonomyTermReferenceItem.php: phrase "TaxonomyTermReferenceItem" does not coin up in code repository indeed.
2. core/modules/taxonomy/src/Plugin/entity_reference/selection/TermSelection.php: file still exists, but containing directory names has been condensed from "entity_reference/selection/" into single "EntityReferenceSelection".
3. core/modules/taxonomy/src/Tests/Views/TaxonomyIndexTidUiTest.php: file still exists, but containing directories has been changed from "src/Tests/Views/" to "tests/src/Functional/Views/".
4. core/modules/views_ui/src/Tests/DisplayPathTest.php: file still exists, but containing directories has been changed from "src/Tests/" to "tests/src/Functional/".

Error message does not mention (because modifications apply cleanly)

1. core/modules/forum/src/Form/ForumForm.php
2. core/modules/taxonomy/src/TermForm.php

We may want to consider using U+2015 Horizontal bar (rendered like this: "―") which seems wider in terms of character space than the regular em dash:

Although issue title mentions "dash" (probably because using them is a good-old pattern burned in Drupal UI's history), however, we don't need to stick with these horizontal lines for proper indentation. Of course, we cannot use regular space character (because web browsers' render engines will filter them out when graphically rendering the inner text nodes of <option> items. Instead, we can freely use U+2003 Em space, which is the widest I found in the collection of all space separators listed:

If we do this, then one concern may raise is that the user could find hard to overview the level of indentation. Especially on such a deep level as an Administration menu can be.

So in this case we could combine a tiny point (eg. U+00B7 Middle dot character) with the wide whitespace from above. As middot has a relatively low numeric position (No. #183) then probably most devices, including old ones or IE-equipped will be able to render with their fonts available. (This is the reason why I not recommend the very similar-looking U+2027 Hyphenation point or U+22C5 Dot operator characters, because their codepoints are much higher: #8231 and #8901 respectively. Chances that these may fall into "exotic" consideration on a given OS platform blocking their proper rendering.)

If we agree to go towards this direction, then the formerly single-char separator matures into a string of two characters, like in the code example below from core/lib/Drupal/Core/Menu/MenuParentFormSelector.php:

...
if (!empty($element->subtree)) {
  $this->parentSelectOptionsTreeWalk($element->subtree, $menu_name, $indent . '· ', $options, $exclude, $depth_limit, $cacheability);
}
...

This way that would be elegant to organize these two chars into a proper PHP-variable of string, so we could refer it from multiple places for the sake of consistency. And maybe @kopeboy's idea could also be closer to implement.

Also tested with the Book module's outline lists:

Based on @nod_'s patch from #15 I followed the same files to port these improvements to 8.8.x-dev version. The only one file in his patch that I was not able to dig up in 8.8.x code structure is the old /core/modules/taxonomy/src/Plugin/Field/FieldType/TaxonomyTermReferenceItem.php. Any hints would be appreciated to figure out if it still exists or not? And I also tried to search for str_repeat('- in the core/ directory to see if I can find more hierarchical lists, but it seems like that's all.

Test assertions updated regarding previous results.

I found the reason of the failure: an extra space character was added later in parentSelectOptionsTreeWalk() method. Now removed, let's see!

As @sysosmaster pointed out on DrupalChat.me, these Unicode characters should be referenced properly by their numeric codepoints instead of directly put them into PHP files in their pure form. And PHP 7 offers (see release notes and documentation) built-in support to handle them on its "native" level (our internal Drupal\Component\Utility\Unicode class is not needed for this, I think). So here's an updated patch provided.

Interesting, on local repo it applies cleanly. Anyway, search & replaced "core/lib/Drupal/core" to "core/lib/Drupal/Core" in paths.

Silly mistake, I forgot to replace single quotes to double ones, sorry.

2384203-improve-indentation-hierarchical-select-lists-34.patch Code reviewed by me.
Code change in patch looks OK to me.

Visually it looks like this for me

I am not sure thats whats proposed but if it is it can be RTBC'd

@Balu Ertl,

The only one file in his patch that I was not able to dig up in 8.8.x code structure is the old /core/modules/taxonomy/src/Plugin/Field/FieldType/TaxonomyTermReferenceItem.php. Any hints would be appreciated to figure out if it still exists or not?

That code is now in \Drupal\taxonomy\Plugin\EntityReferenceSelection\TermSelection::getReferenceableEntities(), which you already updated in the patch :)

@amateescu thanks for the hint! Glad to hear that it's already covered :)

Removing meaningless "[patch]" prefix from issue title.

Since the last UX review was 4 years ago, it'll probably need another review. Tagging it to check it.

Using the dot indention I believe is the cleanest solution. It has clear and consistent left indentation and has less visual weight than the — character so the eye can focus on the text (what a user is looking for).

Only thing I would love added is to construct a breadcrumb like trail above the select box to display the current hierarchy so a user does not have mentally assemble this based on the analyzing the visual levels. I image this can be done in JavaScript best. Maybe its best left for a module to progressively enhance the core hierarchical select boxes?

Removed Duplicate post - Sorry Drupal having 500 errors

Now tested with Drupal core 8.8.0-beta1 and Claro theme has not addressed yet this issue in any other way:

So I think we should deliver some solution, so let's commit in patch #34, please.

Working on it

Verified and tested by applying the patch on Drupal 8.9 and 9.It was working as expected.It looks good to me.

Steps to test -
1. Go to the admin site.
2. Go to admin/modules.
3. Enable the Simple hierarchical select , book and menu ui modules.
4. Go to admin/structure/taxonomy/manage/tags/add.
5. Add some taxonomy and verify parent terms.
6. Go to admin/structure/menu/manage/admin/add?destination=/drupal8.9/admin/structure/menu.
7. Add some menu link and verify parent link.
8. Go to /node/add/book.
9. Add some book and verify parent item.

Before_Taxonomy -

Before_Book -

Before_ParentMenulink -

After_Taxonomy_D8.9 -

After_Taxonomy_D9 -

After_ParentMenulink_D8.9 -

After_ParentMenulink_D9 -

After_Book_D8.9 -

After_Book_D9 -

@priyanka.sahni thanks for thorough testing and documenting with screenshots!

So is this really still waiting for review?

@hexabinaer Indeed ticket apparently stuck in “Needs review” status. If you agree with the changes, feel free to toggle to RTBC.

Who from the Drupal Core team could have a look at this? Just found it and think it would still be a helpful improvement. Could / should we ping someone from the UX team for feedback?

#34 patch failed.
Re-rolled patch #34 (branch-9.5.x).

i've applied the patch in #61 to a 9.5.x-dev install. in regards of accessibility i've noticed one significant problem that might entail some discussion and work. I've tested with a Menu parent select and Voiceover on MacOS (12.6) for one menu link in the administration menu.

first i've checked the current behavior in drupal 10.1.x-dev: https://www.drupal.org/files/issues/2022-09-22/before_patch_10.1.x-dev.mp4 - you get each option announced the prepended dashes are not.

i've then tested the patch on drupal 9.5.x-dev with the patch applied https://www.drupal.org/files/issues/2022-09-22/after_patch_9.5.x-dev.mp4 . as you notice the voiceover announcement prepends a comma right before each option. but no matter if there is one dot or three dots there is always a single comma announced upfront.

so in both cases the hierarchy of the the options is inaccessible - at least for Voiceover but it would be interesting what NVDA and Jaws are announcing with the patch applied. and with voiceover the single prepended comma that is announced provides no function and is more confusing than providing any queues to the screenreader user.

As already mentioned in the thread in the #ux channel on the drupal slack. the issue would be a real good topic for the next a11y office hour.

Since the beta versions of 9.5.0 and 10.0.0 have been released, most issues should now target 10.1.x. @Balu Ertl, can you update the MR?

Usability review

We discussed this issue at #3310096: Drupal Usability Meeting 2022-09-23. That issue will have a link to a recording of the meeting. For the record, the attendees at this usability meeting were @AaronMcHale, @Balu Ertl, @benjifisher, @dancbatista, @rkoller, @shaal, @simohell, and @worldlinemine. A quick recap of what we have discussed:

1. As @rkoller pointed out, the latest patch causes screenreaders (at least macOS' VoiceOver utility which I tested with) adds a plus word “comma” in extra before saying the label of the actual option item.
2. It can be considered as a regression compared to the currently implemented solution which does not add extra noise only the label is read purely.
3. Ideally, the level of depth within the hierarchy should be also communicated somehow. Although it inherently increases code complexity. From this point on this ticket is also an a11y issue too.
4. The practice of using non-ASCII Unicode characters was also challenged by the argument that they can be displayed in every case on every platform.
5. However, we agreed that horizontal guidance is necessary for the human vision to let users easily connect the selection mark on the left (in the case of LTR writing direction) to the chosen label.

I think the next step for this issue is to improve the accessibility. At least do not make it any worse (see #63, #68); if possible, improve it.

Once that is done, we can decide exactly which character to use. The usability meeting agreed that the "after" screenshots were an improvement over the current version. Several attendees thought it was helpful to have the vertical and horizontal spacing be the same.

I think this is a SC 1.4.4 issue.

Even adding an HR would help.

Here's a useful guide to best practices as of 2023 - https://adrianroselli.com/2023/10/splitting-within-selects.html

Hi all! Following up on a Slack conversation...

A "solution" some of my colleagues came up with -- not going to be a broadly helpful solution, but it might help some folks who come across this issue (note: see "Limitation" below!) --

TL;DR: We're using optgroup elements, and repeating the first/parent item, so that there's a "selectable" version of that parent item (optgroups themselves aren't selectable).

⚠️ Limitation: You can't nest optgroups, so this solution only works with one hierarchy-level, so to speak. As such, it isn't a solution for menus, and it won't work with "has taxonomy term (with depth)" situations with more than 2 depth levels. So, like I said, it's not going to be helpful for actually solving this broader issue, but I'm sharing anyway, in case it helps someone with a comparable use case!

-------

All the details are in this "optgroup demo" gist. (Let me know if you have any questions -- I'll see updates here, but the quickest way to reach me is on Drupal Slack: @alison)

Patch for core 10.3.x