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 uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
