<axa-dropdown>: options inconsistently cropped inside div container with overflow set to auto or scroll

[last-of-the-arctic-vaulters]

When I use an <axa-dropdown> (from React) inside of a containing <div> with css: { overflow-x: scroll; } and click on it, the options appear but get cropped by the div container.

However, when the <axa-dropdown> is at its minimum width and I click on it, the options appear above the containing div, which is the desired behaviour. Persumably a native dropdown list is used in this case.

Update: It seems the options appear above the containing div at some other widths besides the minimum width too, so it appears quite random.

Screenshots

[raphaellueckl]

Hi

Could you provide us with a jsfiddle or a link to where we can debug this behavior? It is a bit hard to understand what the issue really is, because that containing div probably has max widths or heights, when you have to set the overflow css-properties.

Thanks for your help! :)

[last-of-the-arctic-vaulters]

Hi

Thanks for the quick reply. Here is a simple codesandbox: https://codesandbox.io/embed/serene-cdn-plkje?fontsize=14&hidenavigation=1&theme=dark

At larger widths (please drag the divider..) one can notice the cropping and at smaller widths the alternative. It would be great to be able to use the dropdown inside a container with overflow set.

Thanks in advance for fixing it :)

[raphaellueckl]

@last-of-the-arctic-vaulters Thanks for the fiddle! I don't really understand what you mean, because what you describe as being buggy is working for me. See this screenshot:

The opened dropdown is being eaten by the scroll-container around it and no overflow is happening.

If you mean with "smaller dropdowns appear above the containing div", that's because the small dropdown is a "native dropdown". Meaning a native browser dropdown that cannot be styled. To further clarify, have a look at this screenshot from my MacBook:

It is impossible to restyle a native HTML dropdown and one should not attempt to do that. Reason:

https://patterns.axa.ch/iframe.html?id=components--dropdown&viewMode=story

If you open above link in a mobile-browser and interact with an iPhone (not sure how android handles it), you notice that some internal browser-feature takes over, to make it easier for mobile users and people with accessibility issues.

We have added a boolean attribute "native" to use the "overflowing" dropdown on all sizes, which is the opposite of what you are requesting basically (if I understood this request correctly).

I hope this answers your question, otherwise please clarify it further.

[last-of-the-arctic-vaulters]

Hi @raphaellueckl , really appreciate your taking the time to look into this so soon.

Essentially we agree on the analysis.. given my first comment Persumably a native dropdown list is used in this case.

A few points though:

1. The current behaviour of surfacing the native control still seems to depend on width, making usage inconsistent. Is that a bug or a feature.

2. Native dropdowns work for the overflow case illustrated, likely by design.. meaning, it is the preferred behaviour for the control.

3. There are a few types of UI controls belonging to a family where the parts are better seen separate entities working together. The dropdown is one of them imho. Essentially you have a list appearing when clicking on an input control. Due to examples as the one we are seeing here, it is better for the list to appear on its own surface, usually on a higher level, as is done for common popup components. Of course, position, size, and data need to remain in sync. A bit more involved, but it pays dividends to have the design right. One possibility is to have a property for the dropdown control called 'contentSurface', etc ... which could be the classname of the div the list should attach to.. but there are several ways to approach it.

Interested to hear your thoughts. Thanks again for spending time on this :)

[last-of-the-arctic-vaulters]

In summary to this:

The opened dropdown is being eaten by the scroll-container around it and no overflow is happening.

I would say it is not the desired behaviour for dropdowns at all. The list should appear above the noise, as explained in my previous comment.

[raphaellueckl]

To address your first comment (you wrote another one while I was typing):

1. I don't really know that answer, but I will bring it to our team.
2. Ok. Does that mean you will use the native-only variant of the dropdown? Or what is the point here?
3. This would be waaayyy to complex :D I mean, this is totally doable, but we would unnecessarily bloat this component for such a detail-feature. Either we do it the overflow way or not, but not adding a property so a user can decide which way he wants to go. We want to provide some consistency with our components. But I can bring it to our team too, so we can discuss why we implemented it like that.

Second Comment:

I see your point. I don't know the reasoning behind this.

Thanks for your inputs!

[last-of-the-arctic-vaulters]

Thanks a lot.

Regarding point 2.. it just seems strange that the component is vastly more usable at one width than another, switching display mechanism completely. Is there a way to force the non-native mechanism for smaller widths?

I realise many dropdowns out there do not consider the points above. Others may simply add the list as the highest <body> child etc, requiring no extra property. Excited to see what the pattern warriors cook up, inputs a pleasure and thanks again 👍

[raphaellueckl]

Is there a way to force the non-native mechanism for smaller widths?

No, because of the points mentioned here: https://github.com/axa-ch/patterns-library/issues/1976#issuecomment-700096872

Doing that would destroy the UX to people being used to native dropdowns on their mobiles. Also, having too many variants would destroy the purpose of a design system for a company.

But we will discuss this ticket in the team. I think there are a lot of other opinions too. :)

[markus-walther]

@last-of-the-arctic-vaulters:

I am surprised that you did not see the second sentence of the README.md. It says clearly: "The component is responsive, falling back to native look-and-feel under mobile viewports." I.e., this is a feature, and represents good UX.

As answered above, you can set the attribute/property native. Since users don't see the difference at rest, but only when the dropdown drops down (which is a small percentage of the total interaction time), this is a very good compromise that you can use right now.

[last-of-the-arctic-vaulters]

Hi @markus-walther , thank you for your comments.

My focus is not the mobile viewport use-case, but the fact that the normal one (desktop, and dropdown list in AXA style) does not work in these container <div>s with overflow set.

Happy for dropdowns to go native on mobile viewports, but would very much like to have non-native working for my use-case, which relies on regular interaction with the dropdowns. Therefore I would not like to force the native setting for all viewports, but interesting to know it is possible :)

[raphaellueckl]

Hi @last-of-the-arctic-vaulters

Thanks for your comments. We just decided in the team, that we will not support this. If we notice that this would be a common request from our users, we might have a look at it again, but at the moment, the recommendation is to go with the native behavior, if this is becoming an issue for anyone.

I will close this issue here, as we took a decision, but feel free to add further points.

[last-of-the-arctic-vaulters]

Hi @raphaellueckl

No problem and thank you for considering the request.

[last-of-the-arctic-vaulters]

As there is an invitation for a further point, I will remind of the following:

Once the design separates the list from the input, not only can one see the beautifully animated and styled AXA dropdown list behave the same on all desktop platforms, but it also has advantages for mobile.

With the separation in place, one can surface the dropdown list as a centered popup instead for mobile viewports.

When not delivering a native app, I think it is fine for a website not to use the real native controls, but at least try to follow mobile UX philosophies (layout, sizing, gesturing, etc).

If the decision is to use native controls for mobile viewports, why only go native for dropdowns? I think the motivation is mostly rooted in the (in)convenience surrounding the implementation, whereas it seems to be a nice goal to keep AXA branding and style as far as possible.

[last-of-the-arctic-vaulters]

This might be a nice reference for a non-native select (dropdown) for mobile: https://ionicframework.com/docs/api/select

Here are links to the frameworks in use:

• https://ionicframework.com/
• https://stenciljs.com/