Conversation
519429d to
8455438
Compare
Also reorder some variables while I'm here to make more sense
8455438 to
3b76255
Compare
|
About size scale, I'd go for number. Using them in components (eg buttons) is another context, another convention. We may have to document our namings somewhere, would help a lot to spot inconsistencies and name newcomers. |
|
And I'd be in favor of radius, but that doesn't seem much important IMHO. But naming conventions (↑) could help in that sort of case (eg. follow CSS properties / HTML elements to ease discoverability). |
Also reorder some variables while I'm here to make more sense
3b76255 to
f9a67e3
Compare
|
I think leaving it as rounded for now is fine. We can ask folks in our next release and tackle with the beta IMO. Otherwise I think this is good to go! |
|
+1 for the -sm -md -lg. Let the numbers available for us if we want to implement rounded classes based on a percentage. |
* Changes made in migration.md file of documentation Added information about the removal of `.rounded-sm` and `.rounded-lg`. And addition of `.rounded-0` to `.rounded-3` * Moved the edited line Added `rounded-0` to `rounded-3` under v5.0.0-alpha3 * Moved correctly * Added link Added link to issue #31687 * docs(migration): last typo thinggies * Update migration.md Co-authored-by: Gaël Poupard <ffoodd@users.noreply.github.com> Co-authored-by: XhmikosR <xhmikosr@gmail.com>
|
We are use radius size ( Does not work properly in below situation.
|
#30048 is out of date, and I'm second guessing renaming the utilities. @ffoodd and @MartijnCuppens help me out—should we rename these classes all from
roundedtoradius? Should we even both changing the size scale to a numbered scale?Fixes #29989.
Closes #30048.
Closes #31784 (classes can now be expanded and made responsive with utilities API).