I've chatted about this quickly with both Jacine and ChrisB at one point but wanted to get the idea mocked up and out here in the open for discussion.

We've run into numerous occasions where having a class at the page (<body>) level would solve issues. A few use cases:
- changing page background colour/image
- changing style of page title
- alternate styles for menus/blocks in certain sections of the site (recently saw an ubercart thread where the left nav changed colour per sub-section)
- custom styles for header/banner image (eg. Acquia Slate), or different banner images per section
- an easier way than the theme settings API to add general theme options, like font size, to a theme

There are currently modules (http://drupal.org/project/themekey) that provide a robust way to change themes per section, for different values of "section", but this is a heavy-handed solution when you only need to change a few lines of CSS. I also heard some folks talking at BADcamp about things like OG-specific styles, which instead of creating a bunch of specific cases in Skinr, would also be handled just fine based on path.

UI wireframes

Attached are wireframes for the style UI. I took a major nod from the CSS Injector module, which does something similar to allow you to insert arbitrary CSS based on path: http://drupal.org/project/css_injector

The idea is to add a pre-defined style as usual to your theme, with a new skinr[skin_system_name][features][] = page feature restriction. This is then available in the general Skinr settings interface (via admin/settings/skinr?), where you are then presented with the option to add a style rule. The mockup has an alternate version of this showing when style rules have been added.

The next section is the adding screen itself, showing available styles and the UI for path-based rules. In combination with pathauto, doing the page styles as path-based gives you many common options available (front page, specific pages, path depth, content type, etc), and with the PHP option, the sky is the limit :)

Questions

- should we show available styles on the intial Skinr page settings screen?
- what do we think about the phrase "style rule"?
- what's the plan for the admin/settings/skinr page and is this the appropriate place for it?

We'll try to work on coding this but would love some feedback first.

CommentFileSizeAuthor
#6 css_injector_skinr.patch3.34 KBmoonray
#4 css-injector-skinr.zip14.61 KBjacine
skinr-page-ui.png81.19 KBstephthegeek

Comments

jacine’s picture

jacine
she/her
Location New York
commented

Funny, we were playing with css_injector and Skinr and had the two semi-working together earlier this week for the same page-level and UI reasons. I can post the code we have so far if you are interested. This is something I'd like to add in the Drupal 7 version.

The next thing we need is the same sort of UI for handling regions. I think something like this exists already but I haven't had time to research. Do you know of any modules off hand that handle region stuff in the UI?

stephthegeek’s picture

stephthegeek commented

That would be great, yes please!

Any comments on the proposed implementation?

And yes, actually there is... http://drupal.org/project/region_manager

The UI is a little crazy (it's not the same anymore as what's shown in the screenshots) but it's an interesting concept and works as advertised.

stephthegeek’s picture

stephthegeek commented

Hmm another question, do we want to have page and/or node templates available in the advanced options based on path here as well?

jacine’s picture

jacine
she/her
Location New York
commented
StatusFileSize
new css-injector-skinr.zip14.61 KB

Right now, we are all swamped and just don't have the time to go through and give a thoughtful response on actual implementation. Basically, we are likely looking at a feature-freeze with the exception of packaging for Drupal 6. Not trying to kill the discussion here, but just want you to know where we stand right now.

Our current priorities for Drupal 6 are:

  1. Bug fixes
  2. Packaging scripts

Then we are moving on to Drupal 7, where we'll need to:

  1. Get it working at it does for Drupal 6
  2. Discuss and agree on changes and new features. I expect those features to include: page-level (like CSS injector), region-level, possibly per node-level and certain theme functions.
  3. Implement those features
  4. Then figure out if any of those features are going to be back-ported to Drupal 6

I've attached the modified version of CSS injector. It is showing the Skins and saving skin information, but we haven't actually added the classes to $body_classes yet.

stephthegeek’s picture

stephthegeek commented

Thanks for the zip! Not a prob, I just wanted to get it out there before coding for some eyeballs on it :)

What do you mean by packaging scripts?

So you wouldn't currently accept a patch for this feature on D6?

Chris is currently porting Fusion Core to D7 as well so we'll have that available to help out and test soon too!

moonray’s picture

moonray commented
StatusFileSize
new css_injector_skinr.patch3.34 KB

Find attached an fully functional patch for the css_injector module to make it work with Skinr.
It allows for multiple rules to be applied to a page, and merges the array of returned classes. Newer rules override older rules if the same skin is applied in both rules.

moonray’s picture

moonray commented
Title: Discussion for proposed feature: page-level Skinr styles » Page-level Skinr styles: Skinr patch for CSS Injector module
ChrisBryant’s picture

ChrisBryant commented
Title: Page-level Skinr styles: Skinr patch for CSS Injector module » Add page-level Skinr styles support (similar to Skinr patch for CSS Injector module)
Status: Needs review » Needs work

Shouldn't we include this functionality directly into the Skinr module rather than relying on another external dependency? We could create another feature request issue for this but I think that's what this issue was originally about, no? I'm changing the title, but feel free to change it back if we're going to open another issue.

Thanks! :-)

stephthegeek’s picture

stephthegeek commented

I was just going to pipe in with the same thing as Chris above. Also, I was talking to Eaton about CSS Injector the other day and he is actually considering doing away with the visibility rules in CSS Injector in order to simplify it. He also pointed out this module: http://drupal.org/project/visibility_api

jacine’s picture

jacine
she/her
Location New York
commented
Version: 6.x-1.1 » 6.x-1.x-dev
Assigned: Unassigned » moonray
Category: feature » task

This is definitely high on my list of things I'd like to see finished.

Thank you for the link Steph.

I looked at visibility_api. I'm not sure I like having to depend on it, and I'm also concerned that it doesn't seem to have decent usage stats, but it's still worth looking at as it's a good portion of what we need for this.

moonray’s picture

moonray commented
Status: Needs work » Fixed

Pge level rules are now implemented in cvs.

I decided not to use visibilty_api to minimize dependencies and not add additional code overhead.

jacine’s picture

jacine
she/her
Location New York
commented
Version: 6.x-1.x-dev » 6.x-2.x-dev

Changing to correct version.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.