Feature Request: drop container css and csp concerns

[ngiebel]

The following is from #9

Is there a reason that the css could just not be loaded by the module and left up to the using application to add the css if desired? It seems to be very application/use-case specific and not in general required (I could be missing something though). The css could be noted in the readme with use case situations.

Removing it should at least:

eliminate CSP concerns allow users of the library to selectively use the overlay method when needed, along the lines of adding the current css rules as .drag-active .use-overlay.drop-container reduce css overhead when rules are not needed

@ngiebel I think that those are some reasonable ideas. What would you think about a provider-level configuration that determines if the css is injected or not. Alternatively, perhaps styles could be added directly to elements conditional on directive attributes.

@ggoodman

Having the provider level config option to not load the css should work. Would you want to provide a style sheet with the dist for those that need to conform to certain CSP policies to use or just have a mention of what would need to be added in those situations?

I am not sure that it is possible to achieve the :before rule by adding styles directly to a dom element, so you would have to do the dom manipulation manually. It might be easiest to leave it as css and classes.

An option that I can think of for a non-overlay version of a drop-container would be to add the class .drop-container or .drop-container-no-overlay based on an attribute. Possibly that attribute could just be the drop-container, defaulting to true if undefined so as to not make a breaking change. So the html would end up being something along the lines of

if you did not need/want the overlay. I cannot think of when it would need to be dynamically configurable, so just using the string value of the attribute should be okay (at least to start with).

After digging around a bit it looks like the style loading could more easily be determined by using angular.$$csp().noInlineStyle instead of using a configuration value.

I was also thinking about what the classes for a dropContainer would make the most sense. It might be better to always leave the .drop-container class there always and append an additional class to signify overlay use, but that would mean a breaking change due to the css rules changing. Thoughts?

Hi Nathan,

Can we move this discussion to a github issue? I'm already a bit rusty with the internals of this lib. It has been running without any major issue in production for some time. For this reason, I would ask contributors (maybe you?) to get the ball rolling on a refactor like this.

Geoff

[ngiebel]

I would ask contributors (maybe you?) to get the ball rolling on a refactor like this.

I don't have an issue working on making the changes, just trying to figure out what might be a good direction to go is.