Re: [RFC yew-comp/yew-widget-toolkit/yew-widget-toolkit-assets 0/3] minor ui/ux tweaks for pwt and yew-comp

[Dominik Csapak <d.csapak@proxmox.com>]

On 5/6/26 11:41 AM, Shannon Sterz wrote:
> On Wed May 6, 2026 at 9:53 AM CEST, Dominik Csapak wrote:
>>
>>
>> On 5/4/26 4:38 PM, Shannon Sterz wrote:
>>> this series includes two minor tweaks that should improve the usability and
>>> user experience of some yew components.
>>>
>>> dropdowns should now render their pickers below or above the component
>>> depending on the size of the picker and available screen space. a dropup mode
>>> improves usability for filter fields when the picker is rendered above the
>>> dropdown.
>>>
>>> the log view in the syslog and task log components was slightly tweaked to avoid
>>> interference between scrollbars and drag handles.
>>
>> this looks fine to me
>>
>>>
>>> mainly sending this as rfc for now to get feedback on how the dropdown/dropup
>>> is handled here.
>>>
>>
>> i thought a bit  about this, and since the picker in the dropdown is
>> relatively generic, i think it's dangerous to simply reverse
>> the flex direction.
>>
>> we have no idea what the user of a dropdown renders, and if it's
>> e.g. simply sorted list of flex items, that order would be reversed
>> when it would be displayed above?
>>
>> imho what we could do is to expose the position (if possible) to the
>> DropdownController, and the picker renderer can react to that change
>> (by e.g. putting the filter on the bottom manually)
>>
>> wdyt?
> 
> yep sounds good. i'd keep using a reverse column instead of changing the
> markup itself tho. for two reasons:
> 
> - it makes more semantic sense to me for the filter input field to still
>    be the first one in the picker (this also mean the tab order is
>    "correct").
> - scrolling behavior is better, browsers will scroll the picker to its
>    bottom by default.
> 
> we could correct these manually too ofc, but i don't really see the
> upside here. i will drop the first patch of this series and implement
> this behavior in the `GridPicker` component, though.
> 

yes, how the picker decides what to render first is not really
important, so if we can reverse the flex order there it's fine

i'd only want to avoid that we reverse the flex order when we don't have
any information or control over what is actually rendered

>>> pwt-assets:
>>>
>>> Shannon Sterz (1):
>>>     dropdown: add class for dropup mode
>>>
>>>    scss/_dropdown.scss | 4 ++++
>>>    1 file changed, 4 insertions(+)
>>>
>>>
>>> pwt:
>>>
>>> Shannon Sterz (1):
>>>     dropdown/align: make the picker render above or below a dropdown
>>>
>>>    src/dom/align.rs       |  6 +++-
>>>    src/widget/dropdown.rs | 62 +++++++++++++++++++++++++++++++++++-------
>>>    2 files changed, 57 insertions(+), 11 deletions(-)
>>>
>>>
>>> yew-comp:
>>>
>>> Shannon Sterz (1):
>>>     task_viewer/syslog: make padding margin to improve ux
>>>
>>>    src/syslog.rs      | 2 +-
>>>    src/task_viewer.rs | 2 +-
>>>    2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>>
>>> Summary over all repositories:
>>>     5 files changed, 63 insertions(+), 13 deletions(-)
>>>
>