I just migrated our custom skin from an older 3.1 trunk version to
3.1.0-GA. In my opinion, the FSS style namespacing is one of the lesser
issues. It's easy to just global replace "fl-theme-uportal3". Granted
it did bite me a few times. For example, I forgot to replace uportal3
in the *portlet_content.css file and so those styles weren't taking
affect until I caught it.
I'm fairly happy with the styling and structure of the theme and uportal
skin overall. The only real difficulty I encountered was with single
column portal screens. In our skin the columns are surrounded by a top
gradient and two curved corners. In the CSS file the curves are within
the .left and .right columns. However, the single column doesn't have
this convention (because it's a single column). So I had to implement
these same features differently within the single column's inner
components. Even though it's not technically correct it would make
skinning easier if the single column had extra div elements with .left
and .right so you didn't have to worry about writing more CSS statements
to accommodate single portal columns.
Another issue is understanding the new .fl css. (fl-tabs, fl-listmenu,
etc) When I first looked at the new FSS skin for uportal3 I couldn't
understand how these were used. fl-tabs seemed to affect the navigation
tabs in some ways. I wasn't clear if the idea was that fl-tabs would
define colors and fonts and the navigation tabs would set the
background-images or what. If I want tabs in my portlets should I use
fl-tabs? Is their a JSR 168 standard for tabs?
The .fl-listmenu seems to only be used in sidebars. So I styled it to
look good on the dark background of the sidebar. However, I'm now
unsure if it might be used within portlets, where my color choices would
look bad against a white background.
An explanation of what these new CSS conventions are used for would be
helpful.
My next concerns are with portlet CSS. I'm still not clear what the
correct approach for styling portlets is. Should we try to use JSR 168
as much as possible or should we just use standard html structure except
where it's necessary to use some CSS classes.
For example, for a main heading in a portlet, should I just use an h1
tag? (Styled by fluid.theme.*.css .fl-theme-mycp3 h1)
Or should I use JSR168 (.portlet-section-header)
Looking at PLT.C.4 I'm a little confused how to use it. Should my
structure look something like this?
<div class="portlet-section-header">My Heading</div>
<div class="portlet-section-body">
<div class="portlet-section-subheader">Sub Section Heading</div>
<div class="portlet-section-footer" />
</div>
Looking at the jsr168.css file I see stuff like .portlet-menu. Should I
use this or .fl-listmenu?
I think it would make more sense to move all styles in fluid.theme.*.css
that affect portlet content to *_portlet_content.css. (The h1,h2,a
styles) Or else be more clear about what they're used for. For example:
/* This is the default h1,h2 styling for use in the theme, you should
use JSR168 standards for your portlets, e.g. portlet-section-header
instead of h1 */
I think people would really appreciate a broader overview of these
topics and good CSS practices as it relates to the portal. Maybe this
can be added to the uPortal 3 manual and a link could be put in the main
CSS file so people aren't so confused.
--
Arlo White
Application Management / ITS
[email protected]
Office (805) 756-5211
Jonathan Markow wrote:
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
--
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
