That is a great idea, I hadn't thought about the contextual abilities of css for this manner. I have been working with Kevin on our css stuff and I(We) both agree that styling the portal should be a simple thing. Although we both have gotten into the details of working with jetspeed, our end goal is to have a web person be able to follow our class naming schema and create or integrate a portlet into our portal.
John On Monday 31 March 2003 12:38, Weaver, Scott wrote: > Hi Kevin, > > If you haven't already, check out bug id: > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18208 > > It's an update from my original post and I think it addressed a lot of your > concerns regarding images. > > > You have made great points concerning the current complexity of the skin > registry. I am all for eliminating the obscurity within the css class > naming definitions. Also, I think we should make greater use of the > contextual selector abilities within css: > > VERY simple example > > .TitleStyleClass { default stuff } > > (Different or same style sheet) > > .my-skin .TitleStyleClass { whatever} > > (Also, different or same style sheet) > > .another-skin .TitleStyleClass { something else } > > Then each portlet's content could be enclosed by : > <div class="$skin.Name"> > <span class="TitleStyleClass">Portlet Title</span> > > </div> > > > A very simplistic end page would be > > <div class="my-skin"> > <!-- I override all settings within .TitleStyleClass > - with the values from .my-skin .TitleStyleClass > - anything not overridden, cascades down from > - .TitleStyleClass. > --> > <span class="TitleStyleClass">Portlet Title</span> > > </div> > > <div class="another-skin"> > <!-- I override all settings within .TitleStyleClass > - with the values from .another-skin .TitleStyleClass > - anything not overridden, cascades down from > - .TitleStyleClass. > --> > <span class="TitleStyleClass">Portlet Title</span> > > </div> > > Using this approach, you can have multiple skins, each with individual > csses assigned to a single portlet page. If we used a standardized > directory structure, like you suggested, for skins, no entries should need > to be made to the registry. An event bigger plus is that you can have, for > the most part, HTML page designers whip up style sheets left and right with > out having worry about them needing to understand the subtleties of the > skin registry. Just educate them about the naming convention and directory > structure and everybody's happy ;) > > Backward compatibility is the only thing we would need to address before we > could move forward. > > > *===================================* > * Scott T Weaver * > * Jakarta Jetspeed Portal Project * > * [EMAIL PROTECTED] * > *===================================* > > > > -----Original Message----- > > From: Earl Shultz [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 31, 2003 2:38 PM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Jespeed Skins Alternatives > > > > I seldom post but this posting touched home on some development I have > > already addressed. I see a need to ensure that some aspects of style > > control be carried over or included in future revision. Specifically let > > me list my major concerns: > > > > First, Jetspeeds default.css includes a very cryptic list of class > > references for style control. Most are inherent to the control of the > > Jetspeed appearance but most of the existing classes are very obscure and > > it is not immediately apparent what they control. As a result I have been > > pruning existing classes and establishing a clearer hierarchy. Below is > > an example snippet however I realize this is completely up to the > > developer for control. I mention it simply so that you might consider > > establishing clearer naming conventions for Jetspeed specific classes. > > One important note however is that I am establishing individual CSS > > documents for each skin. > > > > ###### default.css SAMPLE > > > > .Portal { } > > .Portal-Header { > > background-color: #000000; > > } > > .Portal-Header-Logo { > > text-align: left; > > vertical-align: top; > > width: 100%; > > } > > .Portal-Header-Navbar { > > margin: 0px 0px 0px 0px; > > padding: 0px 0px 0px 0px; > > border: 0px; > > text-align: right; > > } > > .Portal-Header-Navbar-Button { > > border: none; > > text-align: right; > > } > > .Portal-Header-Buttonbar { > > padding: 5px 0px 0px 0px; > > border: none; > > text-align: right; > > } > > .Portal-Header-Buttonbar-Button { > > border: 0px; > > text-align: right; > > } > > .Portal-Header-Authentication { > > background-color: #87ACD6; > > text-align: right; > > } > > .Portal-Header-Authentication-Field { > > padding: 1px 1px 1px 1px; > > color: #000000; > > font-family: Arial, Verdana, Helvetica; > > font-size: 80%; > > font-weight: 600; > > text-align: right; > > } > > .Portal-Menu { } > > .Portal-Portlet-Titlebar > > { > > padding: 0px 0px 3px 3px; > > border: 1px 1px 1px 1px solid #000000; > > background-image: url(../../images/blue-gold/scanline_light.gif); > > background-repeat: repeat-x; > > color: #000000; > > font-weight: 900; > > } > > .Portal-Portlet-Titlebar-Actions > > { > > background-color: #CCCC99; > > padding: 2px 3px 1px 3px; > > border: 1px 0px 1px 1px solid #000000; > > } > > .Portal-Portlet { } > > .Portal-Footer { > > background-color: #87ACD6; > > color: #000000; > > font-family: Arial, Verdana, Helvetica; > > font-size: 90%; > > font-weight: 400; > > text-align: center; > > } > > > > Second, There has been a bit of discussion as to addressing only .gif > > images. Scott's proposal is far more ideal as it allows any web image > > format. I support that recommendation completely as jpgs are necessary > > for compressed photo quality images. I believe actions are a small part > > of image control in a skin. The ability to control the users complete > > experience through a skin is limitless. One difference to my > > implementation is that not only do I allow the skin to control the > > appearance of certain aspects of the portal but I have built beneath the > > images directory individual directories for each Skin theme. > > (images/gold-black/default.css or images/blue-gold/default.css). Inside > > each directory I can have a completely unique library of images so that > > even down to the logo, navigation, action images, etc... I can change the > > complete appearance of the site beyond just background colors, borders, > > etc... > > > > I have eliminated most references to style within the skins.xreg, instead > > we have established effective style through CSS documents and we refer to > > a library of class references to handle the page presentation from the vm > > or jsp pages. > > > > ###### Skin.xreg > > > > <skin-entry name="gold-black" hidden="false"> > > <property name="skin-name" value="gold-black" hidden="true"/> > > <property name="title-style-class" value="TitleStyleClass" > > hidden="false"/> > > <property name="highlight-title-style-class" > > value="HighlightTitleStyleClass" hidden="false"/> > > <property name="controller-style-class" > > value="ControllerStyleClass" hidden="false"/> > > <property name="portlet-style-class" value="PortletStyleClass" > > hidden="false"/> > > <property name="content-style-class" value="ContentStyleClass" > > hidden="false"/> > > <property name="tab-style-class" value="TabStyleClass" > > hidden="false"/> > > <property name="tab-title-style-class" > > value="TabTitleStyleClass" hidden="false"/> > > <property name="tab-content-style-class" > > value="TabContentStyleClass" hidden="false"/> > > </skin-entry> > > > > > > These CSS classes are then referenced by the associated VM documents such > > as top.vm or top.jsp... An example follows: > > > > ###### top.vm > > > > <div> > > #if ($!{data.profile.document.portlets.skin.name} != "null") > > #set ($skinName = "$!{data.profile.document.portlets.skin.name}") > > #else > > #set ($skinName = > > $config.getString("services.PortalToolkit.default.skin")) > > #end > > #if ($data.User.hasLoggedIn()) > > <TABLE> > > <TR> > > <TD class="Portal-Header-Logo"><IMG > > SRC="images/$skinName/fnmoc_home_banner_metoc.jpg" /></TD> > > <TD> > > <TABLE class="Portal-Header-Navbar" cellspacing="0" > > cellpadding="0"> > > <TR> > > <TD class="Portal-Header-Navbar-Button"> > > <!-- CUSTOMIZE HTML BUTTON --> > > <A > > HREF="$link.setAction("controls.Customize")?reset=on&level=top"> > > <IMG BORDER="0" ALT="Customize HTML" > > SRC="images/$skinName/edit_html.jpg" /> > > </A> > > </TD> > > > > > > Likewise the css can be unique for each skin as follows in the > > layouts\html\default.vm: > > > > ###### default.vm > > > > <HTML> > > <HEAD> > > <base href="$clink.External" /> > > #if ($!{data.profile.document.portlets.skin.name} != "null") > > #set ($skinName = "$!{data.profile.document.portlets.skin.name}") > > #else > > #set ($skinName = > > $config.getString("services.PortalToolkit.default.skin")) > > #end > > <link href="$clink.setURI("css/$skinName/default.css").Absolute" > > type="text/css" rel="stylesheet" /> > > #set ($titlePrefix = $config.getString("portalpage.title_prefix")) > > <title>#if ($titlePrefix)$titlePrefix > > #end$!{data.profile.document.portlets.getMetaInfo().title}</title> > > </HEAD> > > > > > > I am happy to see that Skins are an issue warranting futher development > > by the Jetspeed developers. The old addage "Better to Look Good than to > > Feel Good" has a great deal of merit to the public. People will always > > favor aesthics over functionality when it comes to end users. But > > Fuctionality coupled closely with aesthetics is always destined for a > > successful future. > > > > If you have any other questions regarding anything I have mentioned > > please feel free to contact me. Thank you for your consideration. > > > > V/R, > > > > > > Kevin Shultz > > > > "The difference between 'involvement' and 'commitment' is like an eggs- > > and-ham breakfast: > > the chicken was 'involved' - the pig was 'committed'." > > - unknown > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
