[META] Determine best method ensure consistent theming of Off Canvas Tray

Obviously this would be asking a lot of theme developers

Not really. Most are using preprocessors anyway so, for example your Scss would be:

:not(.off-canvas-admin) {
  .other-class-1 {
    attribute: value;
  .other-class-2 {
    attribute: value;
  }
}

Which would compile to:

:not(.off-canvas-admin) .other-class-1 {
  attribute: value;
}
:not(.off-canvas-admin).other-class-2 {
  attribute: value;
}

But that still does put some burden on the themer. They should not need to worry about this.

We could gain one rung in the ladder of specificity by prefixing (the tray css) with the id instead of the class. It goes against general best practices but in this case, where there is not likely to ba anything further down the cascade from the tray I think it might be warranted.

This is a lot like the Drupal Gardens themebuilder. In fact, it's almost exactly like the themebuilder. We explored most of these options for that project, and ended up with an aggressive CSS reset plus an ID-based specific prefix for all the styles we actually wanted. That would be my recommendation here as well. It was practically bulletproof, and a lot easier to maintain than an iframe- or JS-based solution would have been.

an aggressive CSS reset plus an ID-based specific prefix for all the styles we actually wanted.

That's a good idea; the off-canvas tray looks great on my theme, but just adding some greater specificity would cover our bases for themes that risked overriding them. I don't think it's necessary to deal with anything more aggressively than that. Besides, there are always going to be theme builders who WANT to override those styles. I've personally had a good dozen clients who would be freaked out if it looked like it didn't "fit" their branding.

Besides, there are always going to be theme builders who WANT to override those styles. I've personally had a good dozen clients who would be freaked out if it looked like it didn't "fit" their branding.

Yes, but we should be clearly documenting that those users (who want to theme the tray) use theme override in the .info file. That should not impact how we write the css.

@tedbow

After looking at this from many angles now I think your summary is correct.

I do also think that the method for styling the tray should follow the quickedit pattern. however there are a few questions we'd still need to answer.

1. Should these admin styles be scoped only to the offcanvas tray or to a more general class like "admin-front", so that they could be used more broadly for styling other dialogs, the toolbar, etc.? If so we would potentially reduce overall code by only then needing one reset and one set of styles for all 'front end admin" things.
2. If we are enabling styles to be pulled from a theme is it even necessary to have a default set of style sheets or can we simply move them to the theme and have less code to maintain?

The drawback of #1 is that in order to get the tight scoping we want we may need to duplicate multiple IDs in the CSS eg.

#toolbar .admin-front .myclass
#ui-dialog .admin-front .myclass,
#ui-dialog-offcanvas .admin-front .myclass {
  attribute: value;
}

Unless we could get away with only using the IDs in the reset css which I'm not sure would work. @ksenzee, thoughts?

Would what I suggest [won't] actually work. What if Settings Tray was disable[d] would this cause a failure b/c the library depends on library that is not available or [would it] just not load?

If we were to do this the way it's been done for other core components, we'd add base or 'structural' css to Stable, base css with added classes to Classy, and theme or 'skin' css to Bartik and Seven. The assumption of that approach is that you are laying the groundwork for themes to extend and style these components for their front ends.

In this case what I believe the user expects is that the tray is themed by some administrative CSS that comes from outside their front-end theme. In the case of quickedit we made the assumption that the source should be the admin theme, essentailly re-routing it's theme inheritance to the front end through a PHP tunnel. This is great for quickedit, but what I discovered in styling the tray was that, because the tray has some special needs based on it's context just piping in the admin theme is not a great solution. That's why I like the approach of the patch that follows the quickedit pattern, because it enables adding a *sub-theme* for the tray (and/or other fornt-end admin things) whose chain of inheritance flows through the *admin theme* not the front end theme.

That's essentially the value of the approach in #2632584: Add a "public admin" theme subtype so that admin themes can have subthemes for front-end UI components