Designers and Developers-
We've had some good discussion about this, t feels like the issue is
still unresolved. I would be more comfortable hearing additional
feedback, since, as Vangel earlier pointed out, the degree of comfort
in working with skins/UI design is critical to user acceptance.
Do people agree that the inconveniences of our current process are
acceptable and well justified by the advantages?
Thanks,
Jonathan
On Fri, Mar 27, 2009 at 2:30 PM, Jonathan Markow <[email protected]
<mailto:[email protected]>> wrote:
Well... A five minute find-and-replace makes the process sound a
lot less onerous in light of the rationale that Gary (and Jacob)
lay out for us. I'd be interested in hearing from more jasig-ue
subscribers about how they view this issue.
-JJM
On Fri, Mar 27, 2009 at 1:39 PM, Gary Thompson <[email protected]
<mailto:[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]
<mailto:[email protected]> as: [email protected]
<mailto:[email protected]>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/jasig-ue
--
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
