I think some of the other feedback points the the following as more important areas to focus effort:
-Clear documentation on how to create a new skin-A UI developer's mode for the portal, this would result in using non-minified CSS & JS as well as turn off all output and content caching
-Eric 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, JonathanOn 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
smime.p7s
Description: S/MIME Cryptographic Signature
