RTL: refactor using logical names#31210
Conversation
3e622bf to
4e6d6f2
Compare
167a335 to
e94b341
Compare
1a4404e to
6814906
Compare
8733621 to
d50b26c
Compare
|
@twbs/css-review I think I'm done with renaming here: please step in to review the CSS part before I continue with the documentation part. There are a few questions in the PR description, BTW :) |
|
One more comment while I'm here—I think our Vertical: top, middle, bottom Does this get us too far away from logical properties? Is it a weird bastardization? I want to keep these class names approachable. |
|
@mdo yeah I've been thinking the same thing, considering the amount of changes here. The target is RTL only for v5, so logical names should only be a first step for this release. I'll make a step back, and topics like dropdowns, tooltips and popovers will get simplified. However that'd come to us when we'll switch to logical properties: that might require to work on Popper.js at some point… Consider this first commit as a v6 preview or something—I'll trash it while rebasing 👍 |
f587253 to
8b67d5a
Compare
|
@mdo I think it's ready now. To sum up:
Do not forget that it can be merged in my main RTL branch and reworked later :D |
This comment has been minimized.
This comment has been minimized.
|
Not sure why and where we need additional mixins? We could use |
This comment has been minimized.
This comment has been minimized.
|
@MartijnCuppens You're right, I think there's nothing needed RFS side: we don't use its direction-related mixins in our codebase. So until the feature is asked for in RFS, I guess we're safe 👍 So the latest pain point in #30980 concerns Popper.js. This specific PR is definetely ready to review :) |
48451fe to
fec38cb
Compare
223a334 to
b26bb28
Compare
|
I've used Google's Flutter for android development which supports RTL by default. |
Mostly a POC for now, here's a first try on using logical names for physical properties.
It's meant to:
.float-right { float: left; }in RTL)There's still things to consider here, I'm not done with SCSS yet (missing components, carousel, dropdown, popovers or tooltips for the most noticeable) and it'd require to apply those changes in our JS as well as in our docs (and to be heavily documented in the migration page).
@twbs/css-review is this a way I should follow right away?
This is highly questionnable, being consistent requires to rename for example
caret-downtocaret-block-end, or to use new abreviations for our utilities (.mtbecomes.mbsforblock-start, .etc). I tried to be consistent but there's an real amount of work here.To do
Questions
What to do with:
RFS mixins?→ to tackle in RFS directlyDropdowns, popovers and tooltips, relying on Popper?→ JS related stuff, not only renaming….carousel-item-left) → Rename._position.scssdefines fixed and sticky helpers fortopandbottom. They're not impacted by RTL but will require refactor to useinsetvalues and subvalues (eg.inset-block-start) when switching to logical properties. Should we rename classes to be consistent with the whole PR? → Do nothing.