[Feedback] new names of utilities classes in bootstrap 5.0 beta-1 look weird.

[TanvirArjel]

.ms-* for margin-left does not make sense. There is nothing called margin-start..ml-* looks more readable and meaningful for margin-left.

Please keep all the utility class names as same as bootstrap 4.x.

Most importantly, changing the utility class names will make v4.x to v5.0 up-gradation impossible.

Thank you.

[patrickhlauke]

the new shorthands work in combination with the RTL work, which replaces terms such as "left" and "right" with more universally applicable ("start" and "end").

[patrickhlauke]

Most importantly, changing the utilities classes names will make v4.x to v5.0 upgradation impossible.

there are many more differences between 4.x and 5.x - jumping between major versions always requires fundamental changes

[ffoodd]

Well, we —and most of the web— are following semver, meaning that a major release breaks things and is not trivial to upgrade to.

However it's possible, and pretty easy when it comes to class names since we maintain a comprehensive migration guide listing every changes that should be known while upgrading from v4 to v5— so in that case upgrading only require to search for old class names and replace them with the new ones.

As @patrickhlauke says, those changes are meant to ease RTL support and usage—which is one of the most requested feature ever— and to do so, we chose to use class names inspired from logical properties. So yes, margin-*-start are a thing in CSS (eg. margin-inline-start on MDN).

Sorry you dislike this, but that's a move meant to reach an even larger audience for Bootstrap, ease its usage for RTL users, and only a first step since at some point we'll all use logical properties as a basis. Everyone will get used to this and we'll get internationalized layouts for free. 👍

To sum up, we won't roll this back and if you want to upgrade, you'll need to read our migration guide since most of our utilities are renamed in v5.

[Maometos]

I agree with Tanvir Arjel, in css we have margin left, margin right and padding left, padding right, so it doesn't make any sense to use start and end as short name to a css left and right, and RTL has noting to do with margin and padding, the left stay always the left and the right stay always the right whatever you use RTL or not
maybe it has relation with flex box there is start and end in flex box for the alignment and ajustement but this is diffent than margin and padding, so it still doesn't make any sense to use start and end for margin and padding.

[mdo]

There are CSS properties for start and end—for margin, padding, and more. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Logical_Properties

[ffoodd]

Moreover it's all about RTL, and being able to write a single template that'll work in both directions—since .margin-start will declare margin-left in LTR and margin-right in RTL—or to write a RTL template that makes sense, since if we kept left and right, processing with RTLCSS would have resulted in .float-left { float: right; } which would make even less sense that .float-start.

And this is basically what logical properties will allow in a (very) near future—we even considered completely dropping physical properties to use the logical ones, at some point.

FWIW, you're still able to rename utilities thanks to our API, as long as you build CSS by yourself.

[borracciaBlu]

Hi, I understant that a big effor has been done for the RTL, that this one is a major version and things are meant to be broken and I understand as well that this will be the future.

That said, margin start and end feels so unnatural right now.
I feel as well the same pain of TanvirArjel and Artister, It feels that in name of the RTL we lost some of the most used (and perhaps loved) utility classes.

I understand that there's no turn around on this but wouldn't be possible to be less drastic and mitagate a little bit the transition?

Why can't we still have left|right and at the same time start|end?

Would that be possible to have them optional?

If none of that was possible, could you pls at least put in the documentation how to restore them using the utlity api?

Thanks for your understanding and effort.

[ffoodd]

Nothing's lost since they're still here: simply renamed. We also renamed .font-weight-bold to .fw-bold for example.

Having them alongside would be a nonsense and would confuse more than it'd help. And they cannot be optionnal nor "restored" since they're here, renamed. Our docs already mentions how to modify utilities, but here's a sample to rename margin-start:

@import "bootstrap/scss/utilities";

$utilities: map-merge(
  $utilities, (
    "margin-start": map-merge(
      map-get($utilities, "margin-start"),
      ( class: ml ),
    ),
  )
);

This would basically regenerate our "margin-start" entries using .ml-* class pattern. Using this for each left and right related utilities would "restore" the previous names — and if you choose to do so, I suggest you read carefully our related changelog to ensure you don't forget anything.

[bestguy]

Thanks for example, but is there a way to support both ml and ms though instead of replacing like you have here?
Best I'd can think of is SCSS @extend for each of the ms-* and me-* utilities, but looks like ~80 at a glance.

RTL support is nice to have, but the reality is larger apps with separate component libraries etc would benefit from easing in the change some way.

[ffoodd]

You could add new utilities with the same properties and values, but that may end up with code duplication (or require some new tooling to pack things).

Using @extend could be simplified using nested Sass loops (over properties, breakpoints and values) but feels pretty weird.

We may find a way to support multiple class names for a given utility, but I won't bet on an ideal solution for this. Any PR is welcome if you find a way :)

[aribudin]

I think this change is for the better, after 2 days using ps, pe, ms, me, -start, -end, it is quite easy to migrate to bootstrap 5. it only takes about 1 to 2 days to get used to.

[josephcrowell]

This is also already the way that Flexbox does things already, so anyone with anything more than a precursory level of experience should be familiar and comfortable with this syntax.

…

On 12/12/2020 10:19 am, aribudin wrote: I think this change is for the better, after 2 days using ps, pe, ms, me, -start, -end, it is quite easy to migrate to bootstrap 5. it only takes about 1 to 2 days to get used to. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32402 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVELW7FBUUYSXADCEA7SETSUKZHRANCNFSM4UTXHD4A>.

[borracciaBlu]

@aribudin , for sure this change is for the better and I see that start|end is going to be the future.

I guess my point is, please have mercy of all developer that till yesterday, for 15 years did opened their editor and typed left|right and pls don't be blind in front of the pain that will come.

@ffoodd , I may be wrong but I don't think fw-bold will be so problematic compared to the right|left, start|end as the syntax does match somehow with an existing mental model.

Sorry again to be so pedantic and thanks again for the amazing work and effort done.

[ffoodd]

No worries, this is a discussion and we really appreciate any insights—that helps a lot to understand painpoints for our users, and to be more accurate in our explanations and documentation.

From a Bootstrap perspective, renaming is renaming: upgrading to v5 will require the same amount of effort to search and replace font-weight-* utilities than left and right occurrencies.

The mental model you're referring to is not questionned by Bootstrap or its naming but by the industry and its standards: the logical mental model is rising and will eventually overthrow the physical one. Bootstrap is only moving with the standards and the industry.

[TonyBaldascino]

I fully appreciate the resistance — RTL isn't a feature most users need and these changes add complexity for them with no perceived benefit (besides making them aware of the logical properties).

I'm not a huge fan of the less natural/semantic property naming in general myself... but this is not a Bootstrap problem.

e.g. using border for the sake of clarity

*-block-start applies to top
https://developer.mozilla.org/en-US/docs/Web/CSS/border-block-start

*-inline-start applies to left
https://developer.mozilla.org/en-US/docs/Web/CSS/border-inline-start

One thought is that separate packages could be built (RTL-disabled or RTL-enabled) which could allow for a transition in mindset to hopefully occur more naturally over time. However there's a strong argument to be made that v4 began to introduce these concepts to users via Flexbox ahead of the major shift in v5. And this would obviously create a headache regarding documentation as well.

Lastly I will play devil's advocate a bit here — since CSS still allows for both border-left and border-inline-start to be used, then why shouldn't a UI framework also allow for that same flexibility with its classes?

[ffoodd]

Being used by most of our users is not a requirement, we're following and answering to feature request — and RTL is the most requested feature ever. The current implementation is the best way we found after months of tries and discussions. Working on a major release is obviously the best time to implement it, allowing us to introduce breaking changes.

Natural and semantic naming is very subjective, we do our best regarding naming but yeah: naming is hard, natural and semantic are subjectives concepts — and well, Bootstrap is opinionated and makes choices. As you mention, flexbox and grids introduced those naming years ago, and those naming will become the standard pretty soon (thus will appear natural and semantic for more and more people).

By the way, using border-line-start instead of border-left is not a RTL or naming thing. It's just so much more powerful by adding your layouts an unbelievable adaptability to all languages and user preferences. You get this for free by simply using new names for old properties.

Why shouldn't a UI framework also allow for that same flexibility with its classes?

Because a UI framework is only a few people, working for free—and what you're suggesting would require a huge amount of work to implement and maintain.

I already suggested several workarounds and improvements that can be considered:

• in a custom build, renaming or duplicating utilities thanks to our utility API,
• allowing aliasing in some way in our utility API, maybe behind a flag (eg. $enable-aliased-utilities) or something.

Both would only help users making a custom build, but we cannot support multiple build on our own.

As mentionned, any help or PR welcome :)

[borracciaBlu]

@ffoodd this would be a basic implementation but i believe it would do it #32525 .

I hope this will help the conversation, as you mentioned:

• only for custom build
• duplicating the utility
• using a flag $enable-aliased-utilities

utilities touched:

• float-left
• float-right
• left
• right
• border-left
• border-right
• margin-left
• margin-right
• negative-margin-left
• negative-margin-right
• padding-left
• padding-right
• text-align-left
• text-align-right
• rounded-left
• rounded-right

[ffoodd]

Let's have a look, thanks for the PR!

[zorn-v]

new names of utilities classes in bootstrap 5.0 beta-1 look weird

I think so also. What if I use RTL and need RIGHT margin ? Not START or END ?
I want to margin BLOCK, not TEXT. And need RIGHT regardless LTR or RTL

[zorn-v]

Suggestion

Do not drop l/r modifiers in utilites

[ffoodd]

Seems you did not catch my point. If I margin RIGHT of some block in RTL before, today (in b5) I can not set RIGHT. If I change mr to me - it become LEFT

Indeed, so you'd use .ms-* in RTL to apply margin-right (thus different markup than in RTL, since start and end depend on direction). That's how utilities work, simply use the correct one?

If you had a RTL page styled using v4 (and without its LTR equivalent), you'd need to rename .ml-* to .me-* and .mr-* to .ms-*—basically the opposite of LTR. We may add a mention regarding such a case in our migration guide, though.

As already explained quite a few times now, the main goal of this feature is to allow to work with a single layout for both LTR and RTL.

[zorn-v]

That's how utilities work, simply use the correct one?

It work correct, but why drop utils that affect to ALL people on planet. Like LEFT or RIGHT.
Imagine that I use multi language layout with RTL and LTR included.

[SandyLudosky]

Following the documentation, I have been trying a new utility with the new utilities API

my scss file :

• I need to import bootstrap.scss because $utilities is undefined otherwise
• the goal is to add a new property to make any button rounded with a class 'button-rounded'. simple example to test out the new API to define custom utility classes. not working though
• I am using the https://github.com/twbs/bootstrap-npm-starter to compile the scss files :
  the src is starter.scss and the output is starter.css

    @import "bootstrap.scss";
    @import "bootstrap/scss/utilities";
    
    $utilities: map-merge(
      $utilities,
      (
        "button-rounded": (
          property: border-radius,
          class: button-rounded,
          values: (
            null: 20px,
          ),
        ),
      )
    );

Am I getting this right ?

[ffoodd]

You don't need to import bootstrap/scss/utilities since it's already imported in our main file. I'd suggest you read our Sass customization documentation page, this is unrelated to the current discussion.

[aavmurphy]

Maybe as a compromise, just depreciate (not remove) right & left in v5

i.e. allow both (e.g.) mr-3 and me-3

this would remove a massive chunk of migration work

most people just use bootstrap from the CDN, they dont use scss,

please don't underestimate how much work this will cause.

[ffoodd]

This is a major version and a breaking change, we don't underestimate this. But we cannot release a major version without requiring a migration, otherwise nothing would ever evolve.

Morever utilities are classes, we cannot deprecate them efficiently since there's no way to make the deprecation obvious (while deprecating a function or mixin is quite easy, we simply drop a warning in CLI). And I already discussed several times the issues that would emerge from keeping both names: layouts wouldn't be compatible with both LTR and RTL, file size would be much heavier, maintenance would be a never-ending nightmare, etc.

I mentionned multiple ways to either rename or alias those utilities using Sass. To keep a fully featured output using both names, I'd recommend someone makes a fork and maintain it (as it's been done for Bootstrap in RTL for years). This'd be as simple as adding one of my suggestion above in a fork, without any other differences. And maintain it at least for each release.

[aavmurphy]

@ffoodd its about having a period of crossover, when both old & new classes work at the same time, to facilitate the migration

[ffoodd]

This would only result in a more difficult migration from v5 to v6. Makes no sense when it comes to ease the migration since it'd only allow to not doing anything about those changes.

[hugo-dlb]

I understand the intent regarding RTL and it makes sense to introduce two new utilities for the start and the end.
However I don't understand why the left and right utilities have been removed, in my opinion they serve a different purpose.
The left and right utilities are not only used with text, in fact I mostly use them to add padding or margin between my buttons to have some spacing. In this case, I don't care about RTL, I just want some spacing on the right or the left of my elements, no matter if the text inside those elements is in RTL or not.

My suggestion would be keeping the left and right utilities, and introducing the start and end utilities as they serve a different purpose and can be useful for the reasons you mentioned.

[Allmedialab]

Don't even understand all discussions about this it should have never been changed! It's counter productive, not logic and for dyslectic people like me a disaster! margin-left should be ml margin-right should be mr etc. etc. I use RTL but don't find any logic in this it's mainly confusing!

[TanvirArjel]

@mdo @ffoodd So! after a lot of disscussion what is the final decision? Has ml-* and mr-* been gone forever? or will be back in the stable release of V5.0.0 as almost everybody is requesting to keep it up.

Thank you.

[ffoodd]

AFAIC they're gone in our core. We provided several ways to either rename, alias or work around this but regarding Bootstrap — RTL or not — this is the path toward logical properties in v6.

Keeping the previous class names is almost trivial if you dare using our utility API, there's no point rolling back or duplicate code in our sources.

I still have in mind to provide a fork that simply renames them (as suggested in our docs) but am currently too busy. Anyone involved in this community could handle this at some point.

[latere-a-latere]

Dropping this here for future readers that are new to the utilities, a quick snippet that fixes the margin/padding left & right classes. Drop it between your imports of _utilities.scss and utilities/_api.scss.

I find the renaming of these classes to start and end absurd and counterproductive. As long as the backing property is non-logical it should remain as it was.

$utilities: map-merge(
  $utilities, (
    "margin-start": map-merge(
      map-get($utilities, "margin-start"),
      ( class: ml )
    ),
    "margin-end": map-merge(
      map-get($utilities, "margin-end"),
      ( class: mr )
    ),
    "padding-start": map-merge(
      map-get($utilities, "padding-start"),
      ( class: pl )
    ),
    "padding-end": map-merge(
      map-get($utilities, "padding-end"),
      ( class: pr )
    ),
  )
);

[ffoodd]

Thanks for sharing!

[qtng]

I think there is a misunderstanding in what start/end actually means.

With justify-content and align-items, start and end makes sense because both are unidirectional like a line, they naturally have a start and an end. Margin, padding and border in contrast are all multi dimensional, on a flat screen they all have four directions. In a 3D environment we would even have 6 directions, i.e. two additional things like margin-front, margin-back (like a box). In a 3D world it seems more natural to assign "start" to the direction of the viewer, i.e. "front". From that start point you would call the opposite side "back", and the other 4 directions you would call "left", "right", "top" and "bottom" (again, like a box). That is what we are used to, and what makes the most sense.

If we make left the new start because of ltr/rtl, then in context of a 2D screen it would mean the old top becomes "left" and the old bottom becomes the new "right". It's like a street that goes from west to east. If the start is in the west then north is left side of the street, south is the right side, and east would be the end. With justify-content and align-items you don't have all this because they each have only two directions, and the start/end of the one is the right/left of the other.

With margin-inline-start/end it is similar to justify-content and align-items. It is unidimensional because it is relative to writing direction. margin-inline-start can be used together with margin-left, they have different meaning. For example <div style="margin-left:100px; margin-inline-start:50px; direction:rtl"> would result in 100px on the left and 50px on the right. But if you change direction:ltr you get 100px on the left and 0px on the right, the flow relative 50px changes to the left side but is overshadowed by margin-left:100px.

In simple words: margin-left != margin-inline-start, i.e. left/right != start/end

My suggestion:

(1) Reintroduce the old classes (.ml .mr .pl .pr .border-left .border-right, .text-left, .text-right and others)

(2) Change .ms-, .ps-, .-start, .-end to control the flow relative properties margin-inline-, padding-inline-, border-inline-* and text-align:start/end

[ffoodd]

In the end we'll probably drop left and right altogether to only keep logical properties.

We do understand the difference, consider our move as a first step toward logical properties. It's only meant to ease using the same markup for both RTL and LTR, as already explained quite a few times now—and will make switching to logical properties a breathe since we'll only have to drop the RTLCSS postprocessing.

[nsmithdev]

Here is a unique idea to help identifying the v4 v5 upgrade scope and provide visual identification of deprecated class names on the page.
https://gist.github.com/nsmithdev/870e310daaa91b45f64509c61b44bafc

It will place a white box with red border and the class name over all deprecated elements.
My deprecation list is likely not perfect since I used a regex on v4 v5 to pull class names then diff those.
It's more the concept then can adjust as needed when preforming the upgrade.

Another variation might be adding a 1px image then watch server logs for pages that request the image to find less commonly used pages popups, server code etc.. that might have been missed.

[julien-deramond]

This is a very interesting idea @nsmithdev to help folks identify at least deprecated classes. Your Gist (or something close to it) could be integrated into Stylus (browser extension) for example.
IDK how but it could be interesting to find a way to include it in our migration guide.

Something like:

Here is the list of the deprecated classes between <version whatever> and : <include a Gist stored in twbs>
Tip: you can highlight these elements on your website by integrating it in <insert whatever browser extension that can do that like Stylus>

Could you please create an issue with your idea? I'll try to add some ideas as well and we'll see if we can find something that could be automated.

FYI it's not that far in the spirit of #37076. Your Gist would be a kind of a diff between two versions of this glossary.

[ffoodd]

I agree, this is a really good idea!

We could easily maintain such file alongside the migration guide, even handling specific messages for each case.

It really reminds me the way a11y.css works, so I may share some thoughts and ideas at some point—but going this far would probable need a dedicated repo, IMO.

[julien-deramond]

Oh yeah that's true that a11y.css works that way! I know that some tools supposedly can highlight components in a page that don't belong to the DS; same spirit.
Let's talk about our ideas when the issue will be created, but I love the idea so far. Could be very helpful for migrations that can be sometimes rather challenging :p