Button: border radius, there's a better way.

[geoidesic]

Firstly I love Attractions. I've selected it for use.

One thing that seems completely wrong to me though is the approach to button radius. The way it works is just counter-intuitive and frankly, unusable.

Problems:

1. There's an assumption that's been made; that we want very round buttons as the norm, which is not the case, the norm is currently rectangular with custom radius.
2. The way rectangle prop has been used where it divides the $border-radius var means that if you want square buttons mostly, you can no longer have round buttons. In other words; if you change $border-radius to make square-corner buttons, round no longer works and you cannot have any round buttons. You really want the flexibility to have both.

Solution:

1. Start with $border-radius default being 0
2. rectangle should not adjust $border-radius
3. There should be a size rather than small, then we have have 5 different sizes: xs, sm, md (default), lg, xl.
4. round should adjust border radius, not by a factor but rather by a hard-coded value proportional to the size prop, or a calculated value proportional to height, and should always render a completely round button.

[illright]

I see your point. I'll have to agree that the button styling is rather opinionated, it has grown from a project of ours where the design system assumed buttons to be as round as they are. The rectangle buttons were designed as a completely different sort of UI element – they were supposed to constitute a menu, being large and strictly outline, not be used in parallel with the regular button component. The round buttons are also not really round, but rather they are meant to be "icon" buttons – buttons without text containing a single icon and requiring equal padding on all sides. It's just that with the default values such buttons also happen to be completely round. That's an unfortunate name.

I recently came across the Fluent UI's Compound Button and fell in love. I think I want the rectangle buttons to be that instead, and then it will probably be time for them to become their own component.

That said, we are open to altering the Button component's philisophy, but we'd rather have it incremental, in patches of non-breaking changes, where possible. That's why I don't think that setting the default button radius to 0 is a good idea. I remember you pointing out in another issue that a border radius this large looks bad, but this ultimately comes down to preference. As for the button sizes, I see a lot of UI libraries do that, but struggle to find a usecase for anything other than regular and small. Maybe you could pitch this idea to us? :)

Here's a plan the way I see it:

• Add a new component for rectangular buttons
• Deprecate the rectangle prop
• Allow tweaking the padding through a variable (two variables: all-side padding and horizontal increment, such that 0.7em 1.1em falls apart to 0.7em and 0.4em)
• breaking: rename round buttons to icon buttons.
• breaking: repurpose the round prop to override the border radius to be 50%

What do you think of it?

@aabounegm would also want to hear your opinion on this

[aabounegm]

Personally, I agree that we still need more SASS variables for per-component customization. I like the way Vuetify achieves it by having some global variables, with more variables for each component defaulting to the global one. Take the $btn-border-radius: $border-radius-root !default; for example.

About the buttons in particular, I also agree that round should be renamed to icon, and I do feel that the default buttons are a bit too round, however, I actually think they go nicely with the whole design principles of Attractions (though that might be a prejudice from the aforementioned project we used it for).

Also, I generally prefer using props rather than SASS variables when it comes to customizing buttons, but that depends on how radical that customization is (for example, I'd choose a SASS variable for changing the background color of all buttons slightly, but a prop for making them round), but that's just me (and might be because of my previous experience with Vuetify buttons).

Coming back to the main point, I would prefer if the default buttons were rectangular, needing to pass the round prop to give them the current look, and not have a separate button component.

To sum up, here is what I think of the proposed plan:

• ❌ Add a new component for rectangular buttons
• ✔️ Deprecate the rectangle prop (and have its style be the default for buttons)
• 〰️ Allow tweaking the padding through a variable (two variables: all-side padding and horizontal increment, such that 0.7em 1.1em falls apart to 0.7em and 0.4em) (one variable for the padding would be enough, imo. I don't understand what you mean by "horizontal increment")
• ✔️ breaking: rename round buttons to icon buttons.
• 〰️ breaking: repurpose the round prop to override the border radius to be 50% (50% seems a little too extreme, making the buttons look like Rugby balls. I'd prefer it give them the current default style)
  

[geoidesic]

I also don't like the idea of a separate component for rectangular buttons. That feels over-engineered to me. I've worked with many UI frameworks and the best one's have a single, flexible button component. Quasar gets it right imho (but they are VueJS-based): https://quasar.dev/vue-components/button. Two components mean they will diverge and ultimately that will cause more problems than it solves.

I don't like the fluent button you linked at all. It's ugly for a start and I think button groups (alla mobile design) are a much better term and concept than split buttons. Quasar again gets it right: https://quasar.dev/vue-components/button-group

I'm in agreement with @aabounegm mostly except for the bit about rugby balls. I think you have to make a distinction between round and rounded, they are not the same thing. If you want rounded corners then that should be a standard rectangular button and you control the radius. If you want a circular button (i.e. perfect circle) then you use round, no-one wants oval buttons but I don't see a problem with 50% radius causing ovals; if you abuse (intentionally or otherwise) round by adding content that distorts the shape, that's your choice.

Maybe round should prevent distortion by increasing height proportionally to keep the button as a circle even with wider content. That would be my preference. I don't like using the term round loosely :)

[geoidesic]

wrt sizing... you may not need additional sizes but more options = more use cases = more users, within reasonable limits... and most CSS users are used to the idea of those 5 categories: xs, sm, md ,lg, xl. They are used for breakpoints, and elsewhere. People are used to that as a standard. So it's a good one to adopt. Regular and small is probably enough for most people but maybe you're building a site where you want people to be able to adjust button sizes... e.g. touchscreen... you want two large call to action buttons. Or maybe you're building a fiddly Desktop interface where you really need lots of really small buttons to fit everything in.

[aabounegm]

If you want a circular button (i.e. perfect circle) then you use round

But why would you need a circular button other than for an icon (for which we agreed there would be an icon prop)? I encourage you to take a look at the Vuetify button, which has props for icon (our current round), rounded (our current default style), and tile, which removes even that little bit of default radius.

[geoidesic]

You might be designing a layout with big round buttons that have text in them. Why limit the creative choices? Maybe you put an image background inside instead of an icon. Round tells you the shape (which is what you care about when you're designing) not the purpose (which may not be the same for every site).

Also why introduce a breaking change to change a term that's perfectly good as it stands?

[geoidesic]

Maybe I'm not understanding the intended difference between round and icon? I looked at the Vuetify button but didn't grok anything related to that difference by reading through those docs.

It's semantics at the end of the day. The word tile doesn't say square corners to me. Tiles can have round corners. Tile to me just means something mostly planar that covers something else in a fixed area, usually repeating. It's not a shape.

[aabounegm]

Ok, to make my intentions absolutely clear, here is what I propose (most screenshots taken from Vuetify):
Normal button (no props passed, no changes to SASS):

icon prop used:

rounded prop used (and I didn't understand the distinction between round and rounded):

Perhaps a tile/rectangular prop to remove the border radius altogether:

And for such oval shaped buttons, we can either introduce an oval/circle prop that would set 50% radius, or leave it to user to override the $button-border-radius variable:

---

As for the sizing, I agree that having xs...xl props would be really helpful (I personally use them a lot with Vuetify), but that's a matter for a separate issue as they will affect more components and incur a lot of changes to the stylesheets (perhaps even with a breakpoint system)

[geoidesic]

Ok but what's the difference between icon and oval/circle in terms of CSS? Like I understand that one has an icon in it but to me the words icon and character are often interchangeable. So I can't at this point see the difference between these two.

[illright]

I think you both got me wrong on the rectangular button component. Let me restate that <Button> and <Button rectangle> and fundamentally different components in terms of design philosophy. It isn't just about making the corners less round – these buttons are meant to be used in a completely different setting, mostly constituting menus. For example:

Notice the size difference. This distinction makes it very clear for the user that these aren't regular buttons: these are prominent actions that a user can take, while usual buttons are more contextual, local actions.

That's why I like the Fluent's Compound Buttons – because they supercharge this idea of menu-creating buttons by giving them additional information, such as a textual description of an action. You wouldn't want this additional text on a regular button:

That's why I think that rectangular buttons deserve their own component. Of course, the current naming is unfortunate, as it doesn't convey the semantic difference between the two types of buttons and misleads users into thinking that rectangle is just a stylistic property (which is made worse by the fact that we put this prop in the Style properties category)

[illright]

Coming back to the main point, I would prefer if the default buttons were rectangular, needing to pass the round prop to give them the current look, and not have a separate button component.

Okay, this might sound like I'm contradicting myself. I suppose I just changed my mind over this discussion.

1. I don't think changing the default border radius is justified
2. I don't think that neither round nor rounded is a good idea

Now let me elaborate on these.

1. Such a change is breaking, but what good does it do to the library users? They can still change the button radius with a Sass variable to their liking, so we're not giving them extra freedom with this change. "It looks better" is subjective, and above all, I really don't want Attractions to become yet another material framework. I think this default gives the whole style of the library a signature character, and as @aabounegm mentioned, it flows well with the rest of the default styles for the library.

2. I believe that an interface with both rectangular and round buttons is questionable. What makes these buttons so different?

In Material, there is a Floating Action Button – something fundamentally different from regular buttons, which justifies the use of rounding. However, we don't provide FABs in this library (and don't plan to), and I can't, off the top of my head, come up with other use-cases of round icon buttons in a mostly-rectangular-buttons setting. Making it easy for rookie designers to introduce such inconsistencies into their designs is not a good idea, in my opinion.

That said, my current position on the round prop stays – I think it should be renamed to icon in order to clarify that all it does is unify the horizontal and vertical padding of the button. As for tile from Vuetify – again, this is a rather uncommon use-case to me, and if someone's already going through the trouble to manage the button content on their own, they can surely write a semi-global selector to style this particular button to have no padding. The same for round buttons – if you know what you're doing, it shouldn't be too much trouble to make up your own .round class, give it a semi-global style, and pass it in with the class prop.

[illright]

@aabounegm by "horizontal increment" I mean the difference between horizontal and vertical padding. It's a good idea to have horizontal padding be larger than the vertical padding for textual buttons, however, some users may want to customize that difference:

[illright]

you may not need additional sizes but more options = more use cases = more users, within reasonable limits... and most CSS users are used to the idea of those 5 categories: xs, sm, md, lg, xl. They are used for breakpoints, and elsewhere. People are used to that as a standard. So it's a good one to adopt.

Well, I cannot fully agree with that. More options = more time to choose + more chance of making a mistake for a rookie designer. People are used to that as a standard, but that's not what makes a standard good. These sizes are used for breakpoints, but the sizes of buttons shouldn't correspond to these breakpoints, i.e., a button on a mobile device shouldn't be xs. I don't see a compelling reason to add these sizes apart from "everyone else did it".

[aabounegm]

@geoidesic

Ok but what's the difference between icon and oval/circle in terms of CSS

I guess you are right. In that case, it can either be just one prop (say, circle), or we can keep both with the same effect just for the sake of semantics

@illright

Notice the size difference. This distinction makes it very clear for the user that these aren't regular buttons

Ok, they aren't regular buttons, but they are still buttons, right? Where do you draw the line between if something is a button or a "special button" that needs its own component? Is a FAB still a button or would it need a separate component? The distinction can be made clear using prop names (like large/tile/block or twoline) or slots (like secondary line or similar)

it doesn't convey the semantic difference between the two types of buttons and misleads users into thinking that rectangle is just a stylistic property

Well, styles and semantics go hand in hand, right? For different semantics you use different styles, and using different styles you convey different semantics. We give people various ways of changing the styles while making clear the intended us of these styles (using prop names or docs or so), and they are responsible for using them in the manner which was intended or in their own way. We shouldn't limit people's creativity because some things just aren't set in stone (for example, you said the large button is mainly used for menus, but your own screenshot says otherwise; if we can break the "rules", why can't others?)

1. Such a change is breaking

I disagree here. Giving a different default look doesn't count as a breaking change, imo. It is very easily noticeable and requires minimal, depending on how many users changed the default $border-radius. I guess the deciding factor here could be a poll in the discussions

2. I believe that an interface with both rectangular and round buttons is questionable.

Well, that's your personal (respected) opinion, but others may have different use cases. You said yourself that we don't provide a FAB component, so people could use round buttons as FABs if they need to.

More options = more time to choose + more chance of making a mistake for a rookie designer

True, but why leave the experience designer out? I believe that having more options (and hence finer control) is always better as long as the defaults provide me with something working and I don't always have to manually tweak each usage of the component.

Lastly, having one component with many different possible shapes might seem inconsistent or unnecessary to you, but I personally feel more comfortable having to remember (and import) just one component and control its style everywhere I need (as is the case with v-btn)

[RikuVan]

Interesting discussion on how opinionated vs configurable to make a component library. Isn't there a difference in this regard between a component library for a particular client or organization, where it is important that design tokens are consistent across products, to a library which wants to be adapted for any developers needs? I feel in many ways Attractions feels more like the latter right now--something made for a client (which is not a bad thing). I would be happy to see it veer to a more community project with more stress on developer experience, but that is up to you guys. There is certainly need for more Svelte component lib alternatives if you want to make that effort.

[aabounegm]

I understand what you are saying, and you have it correct. This library emerged from another project that was a website for our university, which is why it feels opinionated and trying to be consistent. However, we are constantly trying to become more open and cater to more needs, which is why we always appreciate feedback and contribution. That being said, we also try to never compromise in terms of quality, which (aside from being subjective) can sometimes make for a tough tradeoff between convenience and code quality.
To summarize, please keep your thoughts incoming. Any delay in response on our behalf is due to our time being consumed mainly by studies and work, and has nothing to do with our appreciation of your contributions :)