Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use variables for standardized CSS color schemes in css.php (Trac #952) #952

Closed
elgg-gitbot opened this issue Feb 16, 2013 · 9 comments
Closed

Use variables for standardized CSS color schemes in css.php (Trac #952) #952

elgg-gitbot opened this issue Feb 16, 2013 · 9 comments
Labels
ui wontfix

Comments

@elgg-gitbot
Copy link

Original ticket http://trac.elgg.org/ticket/952 on 39257002-06-28 by trac user twall, assigned to unknown.

Elgg version: 1.5

The core views/default/css.php file could make better use of abstraction. For example, the following usage is rampant:

#main_id { background: white; }
#some_id { background: #dedede; }
#other_id { background: #dedede; }

What could be done instead, which would provide some clarity to those who don't immediately visualize hex colors:

$css = $vars['config']->css; // or $CONFIG->css, or get_elgg_css($context) or whatever
$css['main_color'] = "white";
$css['highlight_color'] = "#dedede";
echo <<<END
#main_id { background: {$css['main_color']}; }
#some_id { background: {$css['highlight_color']}; }
#other_id { background: {$['highlight_color']}; }
END;

The abstracted values could be set from an input to the css view, from the DB, or some other source. Doing so would make it much easier for a theme plugin to tweak values by changing a few of the inputs, rather than painstakingly overriding dozens of CSS selectors.

Other plugins could then make use of these CSS settings in their CSS files, which would help make them automatically integrate with new themes, without the new themes having to know about other plugins' specific CSS settings and selectors.

Currently, any plugin which attempts to match core elgg in its components' appearance must hard-code CSS values, which then must be explicitly overridden by any theme plugin.
@elgg-gitbot
Copy link
Author

trac user twall wrote on 39257008-06-12

This could also help in custom sizing; a single "page width" setting could be used to calculate the desired settings for dozens more width and/or margin settings, rather than having to reverse-engineer the magic values scattered throughout views/default/css.php.

@elgg-gitbot
Copy link
Author

brettp wrote on 40089890-04-23

Closing in favor of the many other tickets concerning similar things.
Discussion at http://community.elgg.org/mod/groups/topicposts.php?topic=397103&group_guid=212846

@elgg-gitbot
Copy link
Author

brettp wrote on 40089892-11-16

Actually this is a slightly different subject and is one worth keeping.

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8 by brettp on 40089892-11-16

@elgg-gitbot
Copy link
Author

Title changed from Core css.php should abstract settings to Use variables for standardized CSS color schemes in css.php by brettp on 40089892-11-16

@elgg-gitbot
Copy link
Author

trac user twall wrote on 40779617-06-10

One other useful variable would be $css_scope, e.g.

{$css_scope} input[something-or-other] { ... }

I have several elgg views that may be brought up within a page that is not the original elgg environment. I want to be able to include the full elgg CSS to style those views, without affecting the host environment (ning, for example, would go crazy if the elgg default css file were included as-is).

By default the scope might be empty, or something like ".elgg", and the default page shells for elgg would put the css scope into the class of the html or body elements.

@elgg-gitbot
Copy link
Author

cash wrote on 40979459-04-10

To be useful, this has to have a lot more than just a few colors. You'd need colors for text in different contexts, backgrounds in different contexts, headings, links, etc. Then themers could mix and match.

I originally tried to create just a few color variables and I ran into two problems: choosing names and making the colors atomic enough to be useful.

We can keep this around in case someone gets inspired, but I don't see a good way to do this.

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.9 by cash on 40979459-04-10

@elgg-gitbot
Copy link
Author

ewinslow wrote on 41149240-03-18

Closing this.

  1. I'm not inspired
  2. It's usefulness is questionable in light of the significant refactor
  3. We can always reopen it if we really change our minds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ui wontfix
Milestone
No milestone
Development

No branches or pull requests
1 participant
@elgg-gitbot