fix(#8541): fixes display of Enketo select option

[latin-panda]

Description

• Fixes display for:
  • Long and shot words
  • Long and short sentences

#8541

Code review checklist

• Readable: Concise, well named, follows the style guide, documented if necessary.
• Documented: Configuration and user documentation on cht-docs
• Tested: Unit and/or e2e where appropriate
• Internationalised: All user facing text
• Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.

Compose URLs

If Build CI hasn't passed, these may 404:

• Core
• CouchDB Single
• CouchDB Cluster

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[latin-panda]

@garethbowen can you please review this quick fix? Thanks

[garethbowen]

It looks like the width has broken radio buttons:

Have you got a form with a select that you can share so I can test this out?

[latin-panda]

@garethbowen I used the enketo widget form

[latin-panda]

@garethbowen please hold, I'm checking some input display

[garethbowen]

@latin-panda How are you getting on with this one?

[latin-panda]

It turned out to be more challenging to fix than I expected, but I think it's okay now.

Testing using enketo widget form

Short text

Long text

Just normal text

@garethbowen can you please review?

[tatilepizs]

Hi @latin-panda,

I was testing your branch and as you said, everything is looking fine with the enketo_widgets form, but the other forms that contain translations display all the available labels. Could you please check what might be wrong?

8541_long_names_enketo

master

[garethbowen]

Overall looks good, but rejected based on the bug.

[latin-panda]

@tatilepizs I've fixed it.
Inputs with dropdowns and long text behave like in master branch (no wrapping text), but the original issue is solved. The reason is that I don't have enough uniqueness (classes, ids, etc) in the Enketo's HTML to isolate the change without affecting other fields.

Screenshots

[tatilepizs]

Thank you @latin-panda for fixing it so quickly ✨

I just have a question that is definitely not a blocker.
Why for some elements it is going to the next line in the correct place (blank space) and in other elements is cutting the word?
Is this something related to the code or is more related to the form? Do you know?

For example:

Places when the sentence/word is cut in the correct way:

Places when the sentence/word is cut in the wrong way:

[garethbowen]

Starting to look really good, thanks!

I've left a few suggestions inline.

Also in your screenshot here the dropdown option label isn't wrapping at all. I didn't manage to figure out what was going on but maybe you can see something?

https://user-images.githubusercontent.com/66472237/277677449-dad4ca04-b6e0-47dc-96ed-3848e0fbd53d.png

[garethbowen]

I don't think display: contents is valid in this context. I get quite a nice result if I remove these two lines altogether...

Suggested change

	margin: 0;
	display: contents;

Your PR:

My suggestion:

[latin-panda]

We need the display: contents; so radios and checkboxes utilize the space efficiently and display nicely when in columns.
This is without display: contents;

This is with display: contents;

[latin-panda]

I've removed the margin

[garethbowen]

Ahh ok, thanks.

[latin-panda]

Also in your screenshot here the dropdown option label isn't wrapping at all. I didn't manage to figure out what was going on but maybe you can see something?

@garethbowen That's what I tried to explain here, I didn't find a way to wrap it, and that doesn't affect other fields display

Edit:
I kept trying to fix it this morning and afternoon but no luck.
For the record, I tried white-space: break-spaces; but it wraps the word weirdly. It doesn't work either:

[latin-panda]

Why for some elements it is going to the next line in the correct place (blank space) and in other elements is it cutting the word? Is this something related to the code or is more related to the form? Do you know?

@tatilepizs somewhere else in the code, there's an additional rule to break by word instead of by letter when the field is in a column. I initially made it by letter in case of weird big words, which may be uncommon. It looks like the browser deals with long words just well, so because of that unlikely scenario, I changed it to break by word that looks nicer. Thanks for the observation!

[garethbowen]

Thanks for going back and forwards on this!

[garethbowen]

This is so complicated and requires so much testing I wonder if we need a test suite which compares screenshots. Then we can create a form with all of these edge cases and automatically check that we haven't regressed somewhere else...

[tatilepizs]

It looks so much better @latin-panda, thanks ✨

Images attached

[dianabarsan]

This change ended up making these radio span label elements not interact able in new wdio, and also in chrome dev tools - if I open dev tools and click on an element, it won't get focused :(

[dianabarsan]

Related chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1366037
I got this link from this page: https://caniuse.com/css-display-contents#:~:text=display%3A%20contents%20causes%20an%20element's,grid%20or%20similar%20layout%20techniques.