[0.2] Rework rounded utilities to radius, add ability to target corners

[adamwathan]

This PR is targeting the branch #188 is based on and should be merged against that branch first if we think this is a good idea.

This PR changes the name of the rounded utility to radius, removes the default no-modifier rounded utility altogether, and removes the ability to round the sides of an element (rounded-t-sm), adding the ability to round specific corners instead (radius-tl-sm radius-tr-sm).

Changing rounded to radius

The name rounded is a bit unusual compared to our other utilities. On its own it's kind of nice, "this element is rounded", but when combined with modifiers it starts to feel awkward:

<div class="rounded-lg"></div>

In particular, rounded-none felt really odd.

Other utilities use a more active/declarative tense which feels a little more natural with modifiers. For example, we use tracking-wide not tracked-wide, and shadow-md not shadowed-md.

Switching to just round felt wrong because "round" sounds like you're making something a circle, not just rounding it slightly.

Switching to radius-md feels more consistent with tracking-wide and shadow-md, where it's like we're saying "The radius of this element is medium sized."

radius-none also feels miles better than rounded-none.

It's also closer to the CSS property name which, although not a primary goal when we choose names, always ends up being a plus if we like a name better for other justifiable reasons and it also happens to be closer to the CSS property name.

Downsides

1. This is a big breaking change, but that's why we're still 0.x so while unfortunate, this would be the time to do it.
2. We lose the no-modifier rounded utility in favor of radius-md. I considered keeping a default radius utility, but it feels weird, like tracking would feel without a modifier.

Targeting corners instead of in addition to sides

Currently we support rounding the sides of an element, like so:

<div class="radius-t-lg"></div>

...which would round the top-left and top-right corners.

As part of reworking some of this border radius stuff, this PR replaces the ability to target sides with adds the ability to target corners.

So the above code would could be rewritten like:

<div class="radius-tl-lg radius-tr-lg"></div>

Motivations for this:

1. Currently it's very unintuitive to round a single corner. You have to round the entire element, then disable rounding on the two opposing sides. This is how you round just the bottom left corner for example:

   <div class="radius-lg radius-t-none radius-r-none"></div>
   

   This is really weird. Switching to Supporting corners instead of in addition to sides lets you be very explicit and direct about what you are trying to do:

   <div class="radius-bl-lg"></div>
   

2. The existing radius side utilities have two declarations each; one for each corner they are targeting:

   .rounded-t {
       border-top-left-radius: .25rem;
       border-top-right-radius: .25rem;
   }
   

   This is the reason for issue 1. We are trading fine grained control for a bit of convenience, and nowadays I think I'm convinced that it's better to make this a simpler and more direct abstraction on top of the individual CSS properties.

   Forget this point :)

Downsides

1. Again big breaking change.

2. The tl, tr, bl, br abbreviations are going to take some getting used to; I think they are pretty unintuitive but don't have a better alternative.

3. You now need two classes to round both corners on one side of an element:

   <div class="radius-tl-lg radius-tr-lg"></div>
   

   This is without a doubt harder to read and grok than:

   <div class="radius-t-lg"></div>
   

   It's only worse when combined with a bunch of other utilities too.

   No longer relevant; keeping both.

Q: Should we support targeting both sides and corners?

Part of me really wants to support targeting corners as well as sides, since it's much more common to style two adjacent corners than one individual corner.

~~The issue is it adds 100 more classes to the output, and 20 new classes every time you add a new radius size. This results in about ~1kb of extra file size (minified and gzipped) for the default configuration, which is not insignificant since the whole file is about ~29kb to begin with.~~

It would also be the only time in the framework that we provide "shortcut" classes like that for things you could already do with existing classes. Actually we already do this sort of thing for pl and pr with px, and in a few other places 🤔

So my questions are:

1. Is it worth keeping the side helpers for convenience, despite the extra file size? Is adding two classes with the new tr-style abbreviations so ugly that it's worth it?
2. Should we just keep it to sides and forget targeting corners since that's not terribly common, and instead suggest that people create their own utilities for that if they ever need to do it?

I should've made this two separate PRs and discussions but it's too late now 🙊

[HellPat]

I should've made this two separate PRs and discussions but it's too late now 🙊

Already seen this in other issues ;-)

Just my opinion: Big 👍 on radius > rounded.

Most of the time I will use "sides" and not "corners".
But tailwind for me is for rapid development. I don't want to stop my flow to add a new utility.
(At least not in that phase of development)
I used a own radius-lt and radius-rt a few days ago.

I'm 👍 for keeping both. The increasy in file size is not good, but in 0.x versions okay for me.
Later there (most likely) will be a plugin system or separate components.
I could then opt-out of generating that utilities at all.
Because its RAD, I just want to smash out my site and then optimize later.

When opt-out of components is possible, we do not have any problems at all.

Maintenance of both tools should not be a problem, because utilities are so cool and easy :-)

[adamwathan]

We are going to keep the ability to target sides but add the ability to target corners. This ends up being pretty consistent with how padding, margin, pin, etc. utilities work.

It adds a bit of file size, but we plan to split targeting sides and targeting corners into separate modules down the road to make it easier to disable one option if you really care about the file size.