Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
MINOR Removed '.LeftAndMain' selector from rules in order to avoid DO…
…M hierarchy confusion (.LeftAndMain contains .cms-content vs .LeftAndMain equals .cms-content)
- Loading branch information
Showing
6 changed files
with
31 additions
and
31 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
a1b8698
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're going down the path of splitting the CMS / sapphire perhaps we should use a better class than cms throughout sapphire, Usage of cms is now all over the place in sapphire/admin, perhaps that should be changed sooner rather than later?
a1b8698
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sapphire/admin is a pseudo-sub-module, in preparation for spinning it off into a proper module and providing a leaner core without much UI stuff.
So in this light, the "CMS" semantics seem adequate. Sure, you could call it a "CMF" (Content Management Framework), with a "CMS" module, but we haven't done anything around this on a marketing side, and frankly I think it'd confuse users. Do you have any alternative suggestions?
a1b8698
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I was thinking more along the lines of just using 'ss' for the core styles. If the cms module is going to extend the built in ui then it would be useful to have a distinction between what is provided by the sapphire ui module and what is needed by cms. At the moment all styles for the cms are all going into sapphire/ui but I almost feel some at least should be in the CMS module and keep sapphire/ui lighter and more generic.
a1b8698
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that some styles should be in cms/scss rather than sapphire/admin/scss. A good example is the URLSegment field styling you've done recently, that could go in there. But it'd be the minority of styles - I'd rather have some styles in a less specific place (sapphire rather than cms), and have people actually find it and extend it in the right place (for core dev).
"ss-" vs "cms-": Yeah, that'd work for reusable UI components: I've started this with calling tabset styles "ss-tabset" rather than "cms-tabset", but its not 100% consistent - e.g. we have an "ss-loading-screen" thats only used in the CMS. My main intent for separating them is making it clear to core devs where certain styles are expected to be used - do you see any other important considerations?