Do we need the skins to be scope per-skin, rather than just for uportal?
More specifically, would something like the following be enough?
fluid.theme.uportal.css
.fl-theme-uportal h2 {color:#5a95cf;}
Something like the above might allow us to mark our files and styles as
being for uPortal without requiring deployers to change the name on a
per-skin basis. I don't know enough about the Fluid UI Options to know what
the requirements for that integration might be. I also don't know what
plans we've made to integrate the UI Options, if any.
- Jen
On Fri, Mar 27, 2009 at 1:39 PM, Gary Thompson <[email protected]> wrote:
> I am all in favor of making skin development easy, as I skin uPortal on a
> regular basis. Therefore, I have great empathy (and sometimes sympathy) for
> others who have to skin uPortal, which is why a main aim in the 3.0/3.1
> theme and skin enhancements was to make theme customizations and skinning
> easier.
>
> One way to make skinning easier was to adopt the Fluid Skinning System <
> http://wiki.fluidproject.org/x/96M7> (FSS). As part of that adoption, the
> uportal3 skin was formatted as a FSS theme <
> http://wiki.fluidproject.org/x/egNS>. Which I know is a bit confusing as
> FSS labels a "theme" what uPortal calls a "skin".
>
> In following FSS theme best practices, the skin CSS file is given this
> name:
>
> fluid.theme.[theme_name].css
>
> Which is why the uportal3 main skin CSS file is named:
>
> fluid.theme.uportal3.css
>
> Continuing in the pattern of a FSS theme, many of the uportal3 CSS files
> follow this syntax:
>
> .fl-theme-uportal3 h2 {color:#5a95cf;}
>
> Which uses the theme name (e.g., ".fl-theme-uportal3") in all CSS
> declarations.
>
> So, to answer the question: "Is there a strong technical reason that the
> root CSS class name for a skin contains the skin name?"
>
> The most simple answer is, "that's how FSS does it". Which I know isn't
> very satisfying, and though I had some sense of why FSS chose to do it that
> way, I put the question to Jacob Farber (U of Toronto), Shepherd of the
> Fluid Skinning System. Here's what Jacob said:
>
> <Jacob>
>
> I hope I understood the question, which I took it to be: why should someone
> add a class name to all of their selectors?
>
> There are a few reasons why we namespace our css themes with a class name:
>
> Reduce collisions: we can work side by side with other themes if need be
> and don't need to worry about colliding
>
> Greater control: by adding a class name, we gain specificity in the
> selector and increase our chance of affecting the nodes we're interested in
>
> Ease of use: we only need to switch a class name to switch a theme, rather
> than load and manage non-namespaced CSS files
>
> In the end, one doesn't need to have any prefix to their theme - you would
> be working at the same level as a CSS reset file - however the uportal
> prefix enables you to load and control multiple themes on the page without
> worrying about messy collisions and cross-theming.
>
> The fewer selectors you use the weaker your hold on your desired effect is.
>
> Additionally, namespacing themes is how UI Options <
> http://wiki.fluidproject.org/x/B6E7> works with them, so if it needs to
> work with UI Options it needs to be namespaced.
>
> </Jacob>
>
> And for this question: "Can we find an alternate solution that doesn't
> require as much work for the deployer to create a new skin?"
>
> One truth we need to face is that the uPortal UI layer is (and probably
> will continue to become) more complex. This is not unique to uPortal, but
> is a trend across the Web, a la Web 2.0, rich user interfaces, etc.
>
> We are using 3rd party libraries like Fluid, jQuery, and Silk Icons
> We are using more and more JavaScript
> We have adopted the FSS
> We are supporting legacy uPortal CSS
> We are supporting the JSR-168 spec CSS
> We have to support older browsers (like IE6)
> We need to be accessible and must comply to accessibility law
>
> And all this must be performant (part of the whole user experience), so
>
> We are using a resource server for 3rd party resources
> We are minifying and caching CSS and JS files
>
> And as a portal (which is pointing to applications and content of various
> nature from varied sources), we take the approach that we are not the only
> player in the game, so
>
> We must practice namespacing
>
> I must admit, adding the namespace to all CSS selectors in the skin does
> add to the effort of maintenance, but I find that effort sufferable for the
> benefits. I have created a new skin from the 3.1 uportal3 skin a couple of
> times already, and I find that doing a find and replace in the CSS files
> takes less than 5 minutes.
>
> I re-quote Jacob:
>
> <Jacob>
> In the end, one doesn't need to have any prefix to their theme - you would
> be working at the same level as a CSS reset file - however the uportal
> prefix enables you to load and control multiple themes on the page without
> worrying about messy collisions and cross-theming.
> </Jacob>
>
> Personally, I would not consider this a blocker issue, but rather a
> reasonable and manageable effort to achieve a best practice. However, I
> also realize that there may be better ways and means, and I am all for
> thinking it through to get to the best result.
>
> -Gary
>
>
>
> Eric Dalquist wrote:
>
>> I'm working on our vendor branch merge for 3.1 and ran into what I
>> consider a blocker of an issue. What has been recommended in the past when
>> doing local skinning work for uPortal is to create a copy of the default
>> uportal3 skin with a new name. When doing so I realized that the new theme
>> uses the skin name as part of the base CSS class name. This means the skin
>> name is hardcoded in the skin CSS files ... 251 times. I realize a search
>> and replace can be used but this seems like a high-burden to place on
>> deployers doing skinning. I was already talking with folks about having the
>> main css file named for the skin as well. It would seem to make sense that
>> the skin name is only part of the path and beyond that is not used to avoid
>> problems like this.
>>
>> Is there a strong technical reason that the root CSS class name for a skin
>> contains the skin name? Can we find an alternate solution that doesn't
>> require as much work for the deployer to create a new skin?
>>
>> -Eric
>>
>
> --
> You are currently subscribed to [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>
--
Jen Bourey
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
