[DRAFT] feat: add NcFormBoxSelectNative

[ShGKme]

☑️ Resolves

• Ref: Overview: Settings reorganization nextcloud/server#55667
• The simplest version of select -- Native Select
• Note: .showPicker() is not supported on Safari https://caniuse.com/wf-show-picker-select
  • Instead, rendering Select on top with opacity: 0;
• Alternatives:
  • Full vue-select (I'd avoid it, it is complicated, heavy and too much)
  • Custom select based on NcActions using NcFormBoxButton as the trigger

🖼️ Screenshots

Chromium - Windows

Firefox Windows

Chromium macOS

Safari macOS

🏁 Checklist

• ⛑️ Tests are included or are not applicable
• 📘 Component documentation has been extended, updated or is not applicable
• 2️⃣ Backport to stable8 for maintained Vue 2 version or not applicable

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.41%. Comparing base (150604d) to head (3e07e16).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7838   +/-   ##
=======================================
  Coverage   51.41%   51.41%           
=======================================
  Files          96       96           
  Lines        3147     3147           
  Branches      868      867    -1     
=======================================
  Hits         1618     1618           
  Misses       1279     1279           
  Partials      250      250           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 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.

[kra-mo]

Really nice, thank you :)

[kra-mo]

The only thing is that this makes it so that on macOS, the currently selected item's label is aligned to the top of the component, but in reality, the label is on the bottom.

Not sure if there is an easy fix for this though.

[ShGKme]

Could you share a screenshot? I'm not sure I get what you mean.

[kra-mo]

Your screenshot in the issue description also exhibits this issue. Basically, select on macOS (and to an extent iOS) moves the list up/down depending on the selected item to align the currently selected list item with the component.

Essentially, the label in the list and the label in the component shouldn't move when opening the list and should be perfectly (or at least closely) aligned.

Example of how it should look, seeing "Goldfish" only once:

whereas for us, comparatively, it is shifted up and you see "Never" twice:

[ShGKme]

Example of how it should look, seeing "Goldfish" only once

But in the example the select is small, and our button is 40px.

If the entire button just were a select on the exact same place, it would look exactly the same.

[ShGKme]

It is not shifted relative to macOS's select's picker position

[kra-mo]

I think it's better if I explain it this way: since the component is taller than list items, right now the list is basically aligned as if there was a less tall invisible select that was top-aligned.

But since our label is at the bottom, it should act like there is a less tall invisible select that is bottom-aligned instead.

[kra-mo]

If the entire button just were a select on the exact same place, it would look exactly the same.

And yes, but it should basically be as if only the bottom half were a select, since that is where our label is, not the top half. Not sure if this is easily doable though.

(Maybe if the text in the invisible select could be also bottom-aligned? But maybe it's not smart enough to pick up on that even if it is possible.)

[susnux]

Is this the new way to go with components?
Asking because currently we try to use always NcSelect or its children for consistency and this will add different looking experience.

Especially because we did have special components for special sections before, but they got unmaintained and caused weird design differences between apps (when to use what and why does it look like this in one place but directly next to it it looks different). So we unified the components to generic components.

Here for example I do not really understand why a select in app settings or other form like locations should look and behave very different from e.g. the main app where the NcSelect would be used.

Also in the past it was the goal to have a consistent webui experience independent from the browser or OS, but with such native components we will loose the Nextcloud consistent design and get different look if you e.g. just switch devices.

[kra-mo]

Also in the past it was the goal to have a consistent webui experience independent from the browser or OS, but with such native components we will loose the Nextcloud consistent design and get different look if you e.g. just switch devices.

I don't think that this is really an issue. Many websites use the native select component even when they don't have browser-specific adjustments. I see this as the same as using the native font or not overriding the native context menu, which basically has the same styling as select.

[kra-mo]

Here for example I do not really understand why a select in app settings or other form like locations should look and behave very different from e.g. the main app where the NcSelect would be used.

I do understand what you mean, but to me, there is a pretty clear semantic difference that I can see:

• NcFormBoxSelectNative would be for small, fixed lists. Simple choices.
• NcSelect would then only act as more of an aid to input rather than a dropdown, for more complex cases. Same as the date picker for example, where you can type in the date, but there is also a UI to help you visualize it.

And I don't think that it being form-specific should be an issue. I can't think of many non-form places where selection is needed, including in the main app.

Maintenance is of course another concern, and not my area.