[v5] Why margin-inline (left + right), but no margin-block (top + bottom)?

[ryanaltvater]

Apologies in advance if this discussion already exists elsewhere, but I didn't come across anything from a quick search of the issues. Mostly found endless conversations around RTL/margin-inline.

---

Recently, I've read quite a bit of discussion on here around the RTL topic and moving away from a physical left and right model to a logical start and end model. As confusing as it was at first to wrap my head around the shift, I'm starting to get it and understand the shift.

After digging through some of the utility docs, migration docs, and actual SCSS files...where is the shift to margin-block? Are we not making a full leap from the physical model to the logical model? margin-left and margin-right have moved to margin-start and margin-end, but margin-top and margin-bottom still remain as-is with no shift to the logical model. For me, that's a little more confusing after everything that I've read and I expected to see this new model reflected 100%. Maybe it is and I'm overlooking it? If so, no need to read the rest of this and please point me in the right direction. :)

If I'm not missing something and it really doesn't exist, is it something that's going to be implemented before release? I guess I can see an issue with how margin-inline is currently implemented as margin-start (or ms) and margin-end (or me), but there doesn't seem to be room for margin-block when margin-start and end already hold these broad definitions instead of something like margin-inline-start and end, which would leave room for margin-block-start and end. To me, margin-start would naturally mean top and left while margin-end would mean bottom and right...but neither of those exist as real properties. Spelling out margin-block and margin-inline makes more sense to me than margin-start and margin-end, and the need to remember those as left and right (at least for the time-being).

My team is currently on v4 and will be utilizing the API to ensure our work doesn't break. We also want to be able to shift with the industry and use what is considered the standard moving forward. This means that we will need to support 2 different sets of utility classes as part of our codebase (physical and logical) to support all of our work. If top and bottom eventually shift to margin-block, then margin-start and end will likely need to change and become more specific like margin-inline-start (or mis) and margin-inline-end (or mie) that is already the standard and supported across browsers. If not something addressed before release, this kind of future update would create a 3rd set of utility classes in our codebase if we moved forward with v5 as it stands currently (physical, current logical, and updated logical).

Like it has been said by the Bootstrap team on a few different threads expressing concerns about this move and immediate deprecation, now is the best time during this major update. So is this something we can think about, discuss, and possibly implement before official release, or is it too late?

[mdo]

My answer is basically "we'll get there" :). It's a huge enough leap to reorient the horizontal directions, let alone introducing a whole new approach. My gut says v6 will see the adoption of more amazing changes like this that force a rethinking of the web design and development vocabulary. Right now we're just not there. Doesn't meant we can't start somewhere though!

Do you have any thoughts on what we can do in addition to the end/start change? Maybe some guides or documentation? Add-one of some kind? Open to hearing how we can better iterate and bridge the gap.

[ryanaltvater]

Hey! Thank you for taking the time to read and respond back to my post. I wasn't exactly sure where to put it when "Issues" can tend to have similar posts and get more eyeballs. :)

All due respect, but I don't see any difference between the x-axis and y-axis. We're already changing left and right, so why not top and bottom. It's already the standard, and as another Maintainer has suggested multiple times elsewhere there's just no better time than now to introduce this adoption to Bootstrap. Personally, I don't think top and bottom are something to wait until v6 for when the standard will have already been out for quite some time at that point. I guess if you couldn't already tell, I'm in favor of taking this the whole way and getting block out there now while we are all already educating ourselves and re-orienting our thinking from physical to logical models. I don't want to make it sound easier than it is, but what exactly is preventing us from doing this and what would it take to make it happen before release? Being as pumped as I am about it, I'd actually volunteer some of my time to help make it happen (if I'm able) as I am sure others who haven't noticed block missing yet will eventually start requesting it and wondering why it wasn't included.

As far as thoughts go, the main thing is moving left and right away from solely owning start and end. We should follow the standard exactly as it is outlined in documentation. margin-inline-start, padding-block-end, border-inline-end-color etc. I should also add that this isn't just about margin and padding. As of right now this link has a list of what I've found are the currently available properties. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties From here, we could use this as a guide to tackle the code and then write the respective documentation and examples to go along with the new code. Again, I'm sure I'm making it sound far easier said than done but starting this change in v5 and only taking it a few steps in that direction before stopping for a later major version at a minimum of a few years away doesn't feel like a good solution. BS4 was released 5.5 years ago. Either all-in, or all-out until it's ready to be all-in.

Why not fully adopt it? Was it an oversight? I'm in support of the shift, and while we're bringing support for RTL localizations, because it's the most requested feature of all time, it doesn't feel like cherry-picking which parts of the model to include is actually supporting developers to adopt/support the change. We're saying "you must use start and end now, goodbye physical model and hello logical model" (unless using the API), but then only really choosing to use the logical model for left and right while leaving behind top and bottom and never adopting block.

I don't know what the solution is, if the answer is not to implement block for v5. I wouldn't be in favor of adopting half of the logical model into my team's codebase until things were fully available. So we would likely find ourselves using the API to revert left and right as I would guess most others would too?

[ffoodd]

Well, other maintainer here 👋

FWIW, we didn't implement margin-inline at all: we only rename our *-left and *-right utilities to be more logical. BTW this is not only a inline and block thing: logical properties are much, much more than that: inset, float and overflow logical values, etc.

We didn't change our vertical-direction related properties because this move is meant to provide RTL support, which is only a horizontal move. No hurry to make unneeded breaking changes. If you read discussions and issues regarding this, you'd understand that for most of our users, this is already a paradigm shift they didn't account for.

Mapping left and right to start and end is somehow understood by everyone thanks to flexbox and grids (I know, they change depending on the axis, but most of our users don't change axis).

RTL has been asked for a long time; support for vertical layout hasn't, neither were logical properties asked (until we worked on RTL).

Regarding logical properties adoptions: my opinion is either we use them everywhere, or we simply don't. They're not required to support RTL, and they're not ready for production yet. Bad support for inset, float values, etc. So that's a no-go. It'd be a nonsense to jump on logical properties if our framework isn't compliant with each layouts and modes.

We deeply thought about supporting this or not, using those names or not, and it took several months of work to get to this point. I'm really confident that v6 will make the switch logical and jump on that paradigm shift. But it's too soon for our users and for browsers as well.