Skins question

[Glenn Golden <gg...@umich.edu>]

I'm not sure our default.css file is working well with skins for the portlet
content area.
 
It seems to me that the important skin attributes for portlet content are:
 
ContentStyleClass 
TextColor 
BackgroundColor
 
The rest of the skin attributes are for controls, controllers, and perhaps
navigations.
 
I see that the controls set up around the portlet HTML to select this class
and a style based on these colors.  One might think that there was nothing
further needed in the portlet HTML to be skinned.
 
One might be wrong.
 
If the portlet HTML has any elements, such as <p>, any style set on P will
override anything in the style or class set up by the control.  P, TR, TD,
I, TH, PRE, BLOCKQUOTE and A are all likely candidate tags for portlet html.
 
And all of these have styles set in the default.css!  And all of these
styles specify a color!  If they didn't specify color or background-color,
then they would not interfere with the skin, I believe.  But they do.
 
So we always get 00000000 text, which seems pretty black to me, no matter
what the skin.
 
To avoid this, each and every tag that has styles in the default.css that is
also needed by the portlet HTML needs to have a style="{}" with the skin
colors!  This is, in my humble opinion, a *mess* of HTML, and likely not
being done.
 
So, what to do?
 
Why do we have colors, or even P, TR, TD, etc. stuff in the .css?  Might we
reserve "color" and "background-color" for the skin style, and not use it in
any other css elements?  Even if we can live with this, which I'm not sure
of, if the skin's ContentStyleClass has stuff that is overridden by these P,
TR, TD, etc. tags, that would be the same problem again.
 
If we want to allow the P, TR, etc, statements of style in the css, and we
want to support skins, then it would be nice if the $skin had a method:
getPortletContentStyle().  Then, in every P, TR, TD, etc, the HTML would
have:
 
<p $!skin.PortletContentStyle()>.
 
getPortletContentStyle() would return: "style={...}", with enough in the {}
to fully specify the colors and styles from the class of and colors of the
skin.  If nothing were needed, it would just return NULL, and no style=
would get encoded.
 
I like this less, as it's still lots of work to remember for every portlet
and every portlet developer, and for almost every HTML tag (!), but it's
cleaner than now and gives each site the ability to specify a fully
inclusive .css file to meet their needs - just letting the skin, which is
the user's choice, win out at the end.
 
We would then have to make sure that all the Jetspeed HTML, the controllers,
controls, screens, layouts, navigations, (did I miss anything?) followed the
same idea; putting styles in each tag to make sure the (other attributes of
the skin) win over the css definitions.  This may already be how they are
done, as these seem to respond well to skin changes.  But we probably should
check.
 
What do you think?
 
- Glenn 
 
--------------------------------------------
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
ggolden@umich.edu <ma...@umich.edu>                734-615-1419
http://www-personal.si.umich.edu/~ggolden/
<http://www-personal.si.umich.edu/~ggolden/> 
--------------------------------------------