[Themes] Should themes be restricted to just styling inside the editor area?

[peterflynn]

When we talked about themes in backlog grooming, there was agreement on the core team that it shouldn't be officially supported for themes to restyle any UI outside the editor area. Otherwise we'd have to treat every tiny DOM change in the Brackets UI as a breaking UI change... and all themes that touch broader UI would have to be responsible for keeping up with every single UI addition or change Brackets makes each sprint.

I'd originally thought ThemeManager actually enforces this, but it turns out I was wrong -- that was just a misunderstanding of how lessifyTheme() works. It does wrap each theme in a root CSS class, but it turns out that's just used to enable/disable themes. (Side issue: this seems inefficient once many themes are loaded. We should probably use <style disabled='true'> or just create/delete style tags instead).

We could modify this wrapping so it's impossible for themes to affect things outside the editor area -- e.g. wrapping it in an #editor-holder or .CodeMirror selector. (This would still allow themes to affect inline UI such as inline editors and gutter annotations, but that's probably sensible anyway).

Do we want to enforce it that directly? If not, what documentation should we use to strongly discourage themes from going outside those bounds?

[dangoor]

cc @MiguelCastillo

I spent some time yesterday looking at how other editors do themes and what all of the existing themes from the two theme extensions look like. I think that styling the editor area is separate from styling the UI and the other editors that allow styling of both tend to make those two separate things, and the user has the ability to choose an editor theme separate from the UI theme.

UI themes will require more maintenance, because we can't assume that the DOM is frozen.

To do this right, I think we should restrict the themes we're landing right now as "editor themes" and peg them to #editor-holder. As we've discussed elsewhere, they should have the ability to express that they're "light" or "dark" so that Brackets itself can adapt the rest of the UI to be coherent.

That said, most of the themes that I saw that went beyond the editor area just applied colors to the sidebar and status bar. I wouldn't be opposed to an editor theme being able to provide suggested colors for the sidebar, status bar and modal bar/bottom panel in addition to the light and dark hint. Those would be overridden by a non-default UI theme when we offer UI themes. We don't need to add that capability initially though.

[mackenza]

in the brackets-dev thread on this I said:

scope of themes - I believe a theme should be limited to the editor window only. Perhaps if there was a desire to also theme the shell and other UI elements outside the editor window, we could have 2 types of themes... some editors call the editor colors "schemes" and the ui conversions "themes" but that's just semantics and not that important.

and

I do believe there are two distinct elements to this and I think, as I suggested above, that there actually be two different "types" of themes, 1 for the editor window and another for the main UI.

so yes, I do think the currently implemented theme feature should be limited to #editor-holder as @dangoor suggests above.

[Joe5]

I have a custom styled other ui elements of the editor with more than just colors and I cannot even think about going back to the default one. It gives me ui i want to have and it gives me more screen space for the editor. My theme suits me really well, it's exactly like I want it to be.

I think that the themes should be able to change other ui elements besides the main editor window. This is what makes brackets great. The ability to change everything.

I agree that the DOM changes would break the themes but so what? They will have to be updated just like regular extensions are. Themes will be versioned, it's not that big of the deal.

[dangoor]

@Joe5 We agree with you that it should be possible to apply custom styling to the rest of the UI. But, we're adopting a pattern that's used in other editors as well in which UI styling (which could break between Brackets versions) and editor syntax styling (which will be stable between releases) are two different things. That way someone can chose an editor style knowing that the rest of Brackets will consistently look good.

We're implementing editor theming right now and will have UI theming later on (in core). Extensions are still free to do what they want, with the potential for breakage.

(Closing this issue as we've already scoped theme styles to the editor area)