feat: introduce Section as a new question type

[AIlkiv]

Based on #2824

@Chartman123 This is an interesting feature because in the future it can be expanded to split one form into pages by section. It can also be expanded to display pages only when a certain condition is met. Much has already been written about this.

Demo:
https://github.com/user-attachments/assets/fc7edb0d-1f24-4493-9c48-0a90dda21052

The only problem I haven't figured out how to solve is that on the mobile layout, the menu partially overlaps the Section (you can see it in the demo).

[AIlkiv]

This is necessary for the correct operation of postion:sticky when there are several sections.
And also for the future, to add display by separate pages.

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 44.23%. Comparing base (8eb7508) to head (30e54c4).
⚠️ Report is 27 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #2913      +/-   ##
============================================
+ Coverage     44.18%   44.23%   +0.04%     
- Complexity     1031     1032       +1     
============================================
  Files            80       80              
  Lines          3705     3710       +5     
============================================
+ Hits           1637     1641       +4     
- Misses         2068     2069       +1     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Chartman123]

The only problem I haven't figured out how to solve is that on the mobile layout, the menu partially overlaps the Section (you can see it in the demo).

@AIlkiv @susnux I could imagine that we move the form title to the top bar like in Talk where the chat name is visible there. In Forms we could do it like this:

• Show the title normally in the app content as long as it's visible
• Move the title to the top bar as soon as it scrolls out of the visible area
• Always place the top bar above the app content
• Stick the section below the top bar.

One problem I can see with your current implementation: If there is a very long description added to a section, you're not able to see the questions anymore.

[AIlkiv]

One problem I can see with your current implementation: If there is a very long description added to a section, you're not able to see the questions anymore.

I can add max-height + overflow-y: auto

[AIlkiv]

@Chartman123 I have already added a height restriction for the block.

demo:

demo_form2.mp4

[AIlkiv]

@Chartman123 If the only problem is the menu overlap, then I suggest we merge this PR and discuss the layout change in a new issue, as it goes beyond the scope of this task.

[Chartman123]

@AIlkiv no, we should do this in this PR already before merging. Other than that our main branch is currently ready for the 5.2 release and I'd like to have this in the 5.3 release, so we need to wait until we branch off the stable 5.2

I also don't like the scrollbars that also appear when there's still enough space for the description... So I added Jan and Nimisha from the design team to have a look :)

[AIlkiv]

I also don't like the scrollbars that also appear when there's still enough space for the description... So I added Jan and Nimisha from the design team to have a look :)

@Chartman123 Scroll appears only for long descriptions.

[jancborchardt]

Very nice! Some feedback:

• The divider line is too intense / has too much contrast with the background. Does it use var(--color-border)?
• Indeed there is a risk of too large descriptions, but also having intermittent scrollable areas is not so nice. I would suggest to limit the description to 2 rows upon scrolling down, and you can read it in full again by scrolling up, or tapping it will scroll you up to it?

[susnux]

I am not really sure about the implementation as a question type. Its not really a question type but rather some formatting / structuring.
I know we have also feature requests for paged forms, so maybe we should rather think about a besser way to represent such cases then misuse question types for it.
Examples could be 'forms-sections' which could be assigned to a question or similar, something one could brainstorm about.

[AIlkiv]

I am not really sure about the implementation as a question type. Its not really a question type but rather some formatting / structuring. I know we have also feature requests for paged forms, so maybe we should rather think about a besser way to represent such cases then misuse question types for it. Examples could be 'forms-sections' which could be assigned to a question or similar, something one could brainstorm about.

@susnux In the current context, you are right. But we can expand it and call it “form element” instead of “question.”
I think introducing a new entity will complicate the module more than changing “question.”

To add output to pages in the future, we will simply need to add a “separate page” checkbox to the Section settings in the current implementation.