Page MenuHomePhabricator

Button, other interactive components: consider a "responsive" size
Open, Needs TriagePublic

Description

Background

In T333392, we added a size prop to the Button component with two values: medium (32px min size) and large (44px min size) to solve the touchable area on small screens. We should also consider other interactive components that include or are combined with buttons to include a large size:

  • Button
  • ButtonGroup
  • ToggleButton
  • ToggleButtonGroup
  • TextInput
  • TextArea (Its minimum height is 64px, so we probably won’t need a larger size)
  • Select
  • Combobox
  • ChipInput
  • Lookup
  • MultiselectLookup

Potential implementations

There are a few ways we could implement this:

1. Status quo: require dynamic binding of size prop

Require developer users to dynamically bind the size prop and set medium or large depending on viewport width. This is a strain on both developer experience and performance, since devs would have to set up a listener that detects when the viewport width changes, find the width, and re-compute the size prop. It makes little sense to do this in JS when it is so easy to do in CSS.

1.1. Slightly better: provide a composable to provide the viewport width

Codex could export a composable to help with this process.

2. Mixin

Provide a mixin that sets different sizes (min-height, min-width, and padding which differs for icon-only buttons) at different viewport widths. It could be parametric to allow for more granularity, or just set large on mobile and medium above that. This solves the problem, but we usually avoid providing mixins for things that will be used a lot, and instead build them into the component via props.

3. Add a largeOnMobile or responsive size or new prop

This would add another value to the Button size prop (or maybe a new prop), largeOnMobile or responsive, that would set the button to large on mobile and medium above that. This would work well if we wanted to limit button sizes to this narrow definition.

3.1 Add a high level of granularity to the size prop

We could allow people to bind maps of sizes to the Button component for maximum sizing flexibility, e.g.

<template>
<cdx-button :size="buttonSizes">Button</cdx-button>
</template>

<script setup>
const buttonSizes = {
    mobile: 'large';
    tablet: 'large';
    desktop: 'medium'
};
</script>

This would work well if:

  1. We wanted to enable this level of granularity, which could lead to UX inconsistency
  2. It will be common to need this level of granularity and not just large on mobile

Acceptance criteria

  • Decide how to support responsive button sizing in Codex
  • Implement and document

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@bwang left this comment about potential implementation paths on the earlier size task; posting it here so it doesn't get lost:

Thank you all for adding the large size to the button! I see that Codex now provides a class for the large button, I wanted to add that for Vectors' use case (large icon buttons on smaller viewports), we'd likely also need a mixin for setting the button size as well.
When I was discussing this with @AnneT, she mentioned that there was discussion about formally supporting this use case with a "responsive" button. This would also work for us, though I think the mixin approach would be simpler and is more in line with the current implementation of the .cdx-mixin-button-layout-flush mixin. Another thing to note, in Vector we only increase the size for icon buttons on smaller viewports, not all buttons. Presumably the reasoning was that regular buttons are quite a bit wider because of the text so its not necessary to change the padding. I'm not sure if the option of a "responsive" button works the same

My 2¢ – I'd be more okay with adding more size values like largeOnMobile if we are confident that this isn't just a one-off that we are only using on Button. Will Icon and Input need similar treatment for example?

From the perspective of a user of the library, we should offer a consistent set of values wherever a size prop is accepted, and any responsive versions of those values should ideally behave the same way across components (same breakpoints, same order of larger on mobile / medium on desktop, etc).

AnneT updated the task description. (Show Details)
AnneT updated the task description. (Show Details)
AnneT renamed this task from Button: consider a "responsive" size to Button, other components: consider a "responsive" size.Jun 7 2023, 5:29 PM
bmartinezcalvo renamed this task from Button, other components: consider a "responsive" size to Button, other interactive components: consider a "responsive" size.Mar 13 2025, 11:57 AM
bmartinezcalvo updated the task description. (Show Details)
bmartinezcalvo removed a subscriber: Sarai-WMDE.