This is more a discussion because I do not believe it is even possible t implement.
What I miss are prefixes. If only every Bs version had prefixes like bs4-modal, bs4-row, bs2-row, etc.. that would be a perfect world. It would be possible to create a single HTML markup that would look good no matter what CSS is used, BS4, BS2, Material, UI-Kit, etc...
I am Joomla extension developer and Joomla templates use a different CSS framework. If you want your extension to look good in every template you have to apply different CSS classes. There is no problem with ui-kit. You can always apply ui- prefixed styles. But it is impossible to make markup that would work on BS2 (which is still Joomla 3.5 base bootstrap version) and BS3. Although HTML structure may be the same, All because of class conflicts. row in BS3 is row-fluid in BS2.
Very often I have modal not working because some 3d party libraries also use modal class. Be it bs4-modal there would be no problems as everything else.
I know it is possible to make your own CSS version with prefixes. Not for BS4 though. But I am talking about CSS that is used by others. The only way it could be solved it it was a core concept from the beginning. So, when I create layouts I can relay that if BS4 is used, there will be BS4 prefixes. I know that I can add prefixes. But that only works if you control as themes as a markup of your application. But if themes are made by others it is a mess. Same problems in the Worldpress world.
I think it's a good suggestion, namespaced our CSS class would be a great improvement and like that it'll avoid libs conflicts 馃憤
/CC @twbs/css-review
Aren't there post processing tools that can handle this?
@mdo Aren't there post processing tools that can handle this?
That is my point exactly. When I create an app and I add CSS there can prepare that CSS as I want. I can prefix it or whatever.
But 褕 made Joomla an example which should illustrate the problem. For example there are Yootheme, JoomlaArt, Gavick, ... template providers. They make Joomla templates and other people use it. Yootheme uses UI-KIT, Gavick - Bootstrap 3, JoomlaArt - Bootstrap 4.
I develop an extension for Joomla and I do not know which template user is going to use. And I know 99% of users will not be able to prefix CSS of the production built template. But I want the markup of my extension to look good in every template. If every Bootstrap version had its own namespace by default, I mean when you install Bootstrap from your repo, then I could be sure that those namespaces are there and I cannot relay on theme developers that they all will add the same prefix for the same library.
They use Bootstrap as they get it from your repo. And even if they would add prefixes to their own versions of Bootstrap that would still not solve the problem. 懈ecause there are hundreds of them and everyone would create a different prefix for the same Bootstrap 4 library. It would be nearly impossible to match all those prefixes in a single markup. And also, update the CSS file will become harder for the end-user, because it will require come prefixes post-processing.
The only solution here is that YOU define a namespace for your library not to conflict with others and if someone whats yet own prefix, they might add it if they want.
But in any case, in every new version of Bootstrap classes have to have unique names, because not only there is a conflict with other CSS libraries who also do not use prefixes, but there is a conflict between Bootstrap versions.
Another case scenario. Universal Web Components. I have a calendar component in my repo with 2000 stars. Right now this component is for Bootstrap 3. And I cannot update t for bootstrap 4. Because it will lose compatibility with BS3 as grid systems are different. This is Web Complement and I want users to use it on any bootstrap version ad even on none bootstrap like Materialize, Foundation, ... I can do those because they have namespaces, but I cannot make this component work good on every version of Bootstrap and the only thing that stops me is that there is not namespace (prefix).
Again you can say that I can add prefixes to CSS post-process, but that it is not me. Someone else who already have bootstrap installed what to use my component. Even if I instruct him to add prefixes, all his other components will be broken. Again one way that YOU define main prefix and this is in CSS by default. You can do that at least for version 5. That would be a start.
I like this idea, but there are some side effects to it:
Aren't there post processing tools that can handle this?
It looks like https://github.com/marceloucker/postcss-prefixer does the job and is quite well maintained. Haven't tested this, but if this solve this issue it might be interesting to mention a section about prefixing our codebase in our docs. For the js side, https://github.com/twbs/bootstrap/issues/29479 might be the solution we need.
@MartijnCuppens It looks like https://github.com/marceloucker/postcss-prefixer does the job and is quite well maintained.
It looks like you do not hear me or you do not listen. Maybe it is my English skill.
using different versions of Bootstrap in your codebase doesn't feel like a best practice technique
I agree. I would not use it if I can. But what if I want to create a universal Web Component that will look good as with BS2 as with BS3 and BS4? How? The end-user will use only Bootstrap file, only one version, but different Web Component users will use different versions of Bootstrap.
And I know this feature is BIIIIIIIGGGG in terms of changes that have to be done. But I believe it worth it. Anyway, it is a good practice to nave namespace for a library especialy such a widely used one.
I really don't want namespacing for our CSS. It's not been much of an issue. I don't think this is something we should take on.
But what if I want to create a universal Web Component that will look good as with BS2 as with BS3 and BS4?
This seems like a bad idea to me. Practically speaking, it sounds like a nightmare, unless you're making completely isolated web components, in which case you're already in a tough spot because that's not what this project is about.
Closing this out for now given the specific use case and post-processors handling the remaining use cases pretty well.
This seems like a bad idea to me. Practically speaking, it sounds like a nightmare, unless you're making completely isolated web components, in which case you're already in a tough spot because that's not what this project is about.
I agree. It is a nightmare to make components for Joomla because of this issue. But just because it is already a tough spot, does not mean that BS should make it even tougher. Actually right now it is unsolvable. It is not tough but the thing you cannot fix.
As I have mentioned BS makes most mess. If only there is a namespace, it would become a tough spot. I mean, hard to do, but at the end achievable.
And look I am not talking about some unique rare case. I am talking about Joomla that has millions of users. And it affects actually any template developer. You have to create a new version of your template for every BS version.
If you would add new stuff to new version but keep backward compatibility, but this is not the case.