-
-
Notifications
You must be signed in to change notification settings - Fork 18.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate plugin css override from main css. #668
Comments
For this specific reason and a few others we use LESS. You can simply comment out Thanks for the suggestion. |
Not everybody are using less. Have same logic for css would be great too. With my sample,
Well, you're telling me to modify vendor files imported from bower. Sorry, but really, no. :-) |
Could you describe your issue please? |
Simple: I load an external css thee for select2 but it's overridden by AdminLTE css so I have some weird rendering. That's why I suggest plugin separation from core for css. |
@almasaeed2010 why closing this issue? |
please read #1086 |
Could you please re-open? Still relevant. |
Hello @soullivaneuh, We apologize for the delay. After looking into this further, we decided that we won't add this suggestion. The reason is that creating a css file for each plugin is a task that we don't want to take over ourselves nor do we want our users to add more than necessary css files. That is, take select2 for example, it is had its own css files that have to be loaded before adminlte's css files. So now we already have 2 files to load. Adding more files to serve the same purpose is not appealing. For further explanation about page load with external files, please read the following article https://varvy.com/pagespeed/combine-external-css.html Finally, this is the reason for us to use preprocessing tools such as LESS. Unfortunately, some technologies have to be learned by users when using certain frameworks such as AdminLTE to reach the utmost customizability. We appreciate your suggestion and apologize for any inconvenience! |
Please reconsider this issue. In some case, we don't want the overridden css of a plugin because we don't use it or we use a different version of it. This is my case as I said on the beginning:
This change nothing, your css override, even if it's loaded after, brake the select 2 4.0 rendering.
Having only one CSS file to increase load speed is not a right argument IMHO. All developer who take a little care about page load will use tools to combine all vendor file like grunt, gulp or even assetic for Symfony.
Maybe, but this is not always possible to work like this. For example, in SonataAdminBundle which uses your theme, we directly dispatch a ready to use UI with vendor css in here. If we want to remove the select2 css override, we simply can't. |
It's not right because indeed, it's an application-level concern, not a library-level concern : if you have 10 libraries, you still want to have only one file, so having 10 files combined by library authors does not help that much. Also, with HTTP/2 concatenation will become questionable, so you should probably leave this decision to the application developer if you want to make your library future-proof. To go further, having to learn less to use your lib might not seem a big deal, and while it is quite a reasonable decision for projects, it makes using your library as the dependency for another library (as opposed to a project) quite a bigger deal, because it means that the dependent library now also depends on less. In our case, the dependency is only if you want to "reach the utmost customizability", you say, which makes it sound like a feature, when it actually is to fix a bug. Imposing less on our user's toolchain so that they can get a bugfix does not seem very sensible, especially if the dependent library is not even a frontend library, and users might be less familiar with javascript and its ecosystem than you think they are. Finally, note that if you still want to provide a big file for BC's sake, nothing prevents you from doing it, and IMO it would be great to provide both. Please consider reopening this issue, I think this small bug shows a big usability issue in this project, which would really gain a lot by fixing it. @ju1ius, would you like to chime in? I think maybe you might know how to solve this properly. |
At least, if you want to keep this logic on less only, you should split this file: https://github.com/almasaeed2010/AdminLTE/blob/master/build/less/AdminLTE.less Because ATM, if I just want to remove the select2 plugin css, I have to copy paste the whole file for that. At least, having a |
Currently, we are considering a potential fix for this issue. Please review the issue-668 branch. Let me know if you have any concerns. Thanks! |
@almasaeed2010 Done in #1101 |
I have an issue with select2 4.0 and a custom css import.
CSS is still overrided by AdminLTE.css that I don't want to be.
Please separate AdminLTE core css from plugin to let user choice of which file to import.
I propose:
AdminLTE.css
-> All css with plugin (keep BC)AdminLTE.core.css
-> Only AdminLTE related CSS.AdminLTE.plugins.select2.css
-> Select2 CSSAdminLTE.plugins.another_one.css
etc...Related to #589 and #661.
The text was updated successfully, but these errors were encountered: