Skip to content
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

Closed
soullivaneuh opened this issue Aug 31, 2015 · 13 comments
Closed

Separate plugin css override from main css. #668

soullivaneuh opened this issue Aug 31, 2015 · 13 comments

Comments

@soullivaneuh
Copy link
Contributor

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 CSS
  • AdminLTE.plugins.another_one.css etc...

Related to #589 and #661.

@almasaeed2010
Copy link
Contributor

For this specific reason and a few others we use LESS. You can simply comment out @import "select2.less"; from AdminLTE.less and recompile. This goes to any other component or plugin in AdminLTE. You can also compile the LESS files in the way you mentioned.

Thanks for the suggestion.

@soullivaneuh
Copy link
Contributor Author

Not everybody are using less. Have same logic for css would be great too.

With my sample, AdminLTE.css will still be the complete css file, so no one will be disturbed.

You can simply comment out @import "select2.less"; from AdminLTE.less and recompile.

Well, you're telling me to modify vendor files imported from bower. Sorry, but really, no. :-)

@almasaeed2010
Copy link
Contributor

have an issue with select2 4.0 and a custom css import

Could you describe your issue please?

@soullivaneuh
Copy link
Contributor Author

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.

@soullivaneuh
Copy link
Contributor Author

@almasaeed2010 why closing this issue?

@almasaeed2010
Copy link
Contributor

please read #1086

@soullivaneuh
Copy link
Contributor Author

Could you please re-open? Still relevant.

@almasaeed2010 almasaeed2010 reopened this Jun 29, 2016
@almasaeed2010
Copy link
Contributor

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!

@soullivaneuh
Copy link
Contributor Author

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:

That is, take select2 for example, it is had its own css files that have to be loaded before adminlte's css files.

This change nothing, your css override, even if it's loaded after, brake the select 2 4.0 rendering.

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

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.

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.

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.

@greg0ire
Copy link

greg0ire commented Jul 4, 2016

Having only one CSS file to increase load speed is not a right argument IMHO.

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.

@soullivaneuh
Copy link
Contributor Author

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 AdminLTE.less and a AdminLTE-plugins.less would be a minimum, but the logic I said at the beginning would be better IMHO.

@almasaeed2010 almasaeed2010 reopened this Jul 4, 2016
almasaeed2010 added a commit that referenced this issue Jul 4, 2016
@almasaeed2010
Copy link
Contributor

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!

@soullivaneuh
Copy link
Contributor Author

@almasaeed2010 Done in #1101

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants