Use the admin theme for the Outside In sidebar

@xjm

When we build edit module we encountered this issue as well and discovered that it is not possible to use the admin theme unless the modal (in this case the off-canvas tray) was in an i-frame which is undesireable for many reasons. What we could do is copy styles from the Seven theme into the module.

I don't think that is a particularly good solution for a couple of reasons. One is because it's not DRY. Another is that it only makes sense for sites where the admin theme is Seven, and many sites will install another admin theme in which case they would get their admin theme styling on admin pages and Seven theme's styling elsewhere.

This has been a nagging problem for a long time and it's one that I think is outside the scope of this issue. The solution needs to be something like a module for "administrative stuff that gets displayed when the active theme is not the administrative theme" that did something like discover what the admin theme is then @import the CSS from that theme's CSS directory into a CSS file in the module directory, then that module could be a dependency for any "admin thing" you want to put on the front end, including outside in, quickedit, jquery modal, Panels IPE, etc. etc.

For the purposes of outside-in, I think we should create styling that simply resets whatever is being provided by the frontend theme to something as generic as possible.

@xjm

Both toolbar and quickedit provide aggressive resets so that front end theme styles don't leak through, but each has it's own resets. If we were to find a way to programmatically bring in styles from the admin theme then it might make sense to have a single reset file that covers all 'admin things" that appear on the front end.

This could possibly be accomplished by adding a parent class to all of those things like .admin-tool or something. Then we could have a reset file that had:

.admin-tool thiselement, 
.admin-tool thatelement { 
  long list of attributes 
}

Selectors with more specificity might still leak through, but at some point it becomes the responsibility of the front-end theme to be aware that it f-ed up the admin theme.

The more I think about this though the more I feel that these administrative things are something that should not live in the admin theme directory at all but have their own separate home that behaves more like a module or library than a theme. There are several reasons for this:

1. There will be "admin things" that appear both on the front end and in the admin theme. These things need to have the same styling in both places.
2. When "admin things" share styles—eg. the toolbar and outside-in module—in order to be DRY those styles should be coming from the same place.
3. The "Admin things" like toolbar, off-canvas tray, quickedit have a very different set of design constraints than standard admin pages and, will require a lot of custom CSS (particularly for position and animation) that is not needed for admin pages. We don't want to junk up the admin theme with all of that.
4. For a variety of reasons site builders may not want the "admin things" on the front end to share the styles of the admin theme.
5. If the components, templates and styles for these "admin things" are in a single library they can more easily be leveraged by contrib to extend existing or create new "admin things"

It should still be possible for this library to behave like a theme in that a site builder might disable and replace it, only they would use libraries to do this not themes.

All of the above leads towards the conclusion that perhaps this is a much bigger issue that needs it's own meta (there may indeed be one already, I recall Lewis Nyman doing a lot of research in this area) and not a child of outside-in.

In the near term we can continue developing styles for the tray in a consciously non-dry way by borrowing thing from toolbar and quickedit with an eye to eventual recombination in a more holistic solution.

Let's postpone discussion 'til out-side in is stable.

This proposal is bigger than this issue. There are already several issues around moving *all* admin stuff on the front end into a separate library or theme. Moving settings tray styling should be dealt with as a part of that process, not in it's own issue.

Changing to new settings_tray.module component. @drpal thanks for script help!