Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
I'd like to see: - Enable flawless rendering in all browsers But I don't think I am going to get that one. Otherwise, what you have listed would be my list as well (that's what I usually do manually when doing UI development). -Gary Eric Dalquist wrote: Are there any other settings you'd like to see toggled in a "UI Dev Mode"? Gary Thompson wrote: Can I +10 that idea? That would be fantastic. There are some workable means to get into a "groove" with the uPortal environment for UI development, but (as with all the Web) the UI layer is becoming more complex. Having an easy means to tell uPortal "I'm doing UI development" would be most beneficial. -Gary Eric Dalquist wrote: I think this is a great idea. One thing I'd like to see along with this work is figuring out a UI developer mode for the portal. This would likely need to be a configuration property somewhere that is set before the portal is deployed. It would need to control the following: - Use full JS/CSS files, no minification or aggregation. - Disable all JS/CSS/Image caching - Disable rendering pipeline caching - Enable logging of pipeline XSL output Not sure exactly how one configuration change would do all of that but it sure seems like a common need for uPortal deployers. -Eric Jen Bourey wrote: Hello all, I wanted to open up discussion about our options for decreasing the number of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently the portal's skins generally import some shared default resources from the new ResourceServingWebapp and from the theme's common area. These resources include the jQuery UI default theme, the Fluid Skinning System (FSS)'s standard resources, and a base uPortal-specific layout.css file. The skin then overrides and adds to these more general CSS styles, generally through including several more stylesheets. While I think the above works well from a development standpoint, we currently have 14 HTTP requests for CSS stylesheets just for the base uPortal content (i.e., this count doesn't include any stylesheets for portlets present on the page). I'd really like to get this number down as much as we can, while making sure we have a skin organization that's reasonable to work with. My current proposal is that we leave the existing structure as is, but make use of the maven yui-compressor plugin to aggregate the required files at build time. This would allow us to continue to have separate, appropriately named files, but only require the user's browser to download one or two CSS file per skin. For example, we might create aggregated files as follows: ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css One disadvantage of this approach is that it would likely be less transparent to adopters how the CSS is being assembled. I'd imagine that we'd at least want to have a README file in the skins/uportal3 directory that commented on the approach. Thoughts? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu To unsubscribe, change settings or access archives, see http:/
Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
Are there any other settings you'd like to see toggled in a "UI Dev Mode"? Gary Thompson wrote: Can I +10 that idea? That would be fantastic. There are some workable means to get into a "groove" with the uPortal environment for UI development, but (as with all the Web) the UI layer is becoming more complex. Having an easy means to tell uPortal "I'm doing UI development" would be most beneficial. -Gary Eric Dalquist wrote: I think this is a great idea. One thing I'd like to see along with this work is figuring out a UI developer mode for the portal. This would likely need to be a configuration property somewhere that is set before the portal is deployed. It would need to control the following: - Use full JS/CSS files, no minification or aggregation. - Disable all JS/CSS/Image caching - Disable rendering pipeline caching - Enable logging of pipeline XSL output Not sure exactly how one configuration change would do all of that but it sure seems like a common need for uPortal deployers. -Eric Jen Bourey wrote: Hello all, I wanted to open up discussion about our options for decreasing the number of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently the portal's skins generally import some shared default resources from the new ResourceServingWebapp and from the theme's common area. These resources include the jQuery UI default theme, the Fluid Skinning System (FSS)'s standard resources, and a base uPortal-specific layout.css file. The skin then overrides and adds to these more general CSS styles, generally through including several more stylesheets. While I think the above works well from a development standpoint, we currently have 14 HTTP requests for CSS stylesheets just for the base uPortal content (i.e., this count doesn't include any stylesheets for portlets present on the page). I'd really like to get this number down as much as we can, while making sure we have a skin organization that's reasonable to work with. My current proposal is that we leave the existing structure as is, but make use of the maven yui-compressor plugin to aggregate the required files at build time. This would allow us to continue to have separate, appropriately named files, but only require the user's browser to download one or two CSS file per skin. For example, we might create aggregated files as follows: ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css One disadvantage of this approach is that it would likely be less transparent to adopters how the CSS is being assembled. I'd imagine that we'd at least want to have a README file in the skins/uportal3 directory that commented on the approach. Thoughts? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu 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
Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
Can I +10 that idea? That would be fantastic. There are some workable means to get into a "groove" with the uPortal environment for UI development, but (as with all the Web) the UI layer is becoming more complex. Having an easy means to tell uPortal "I'm doing UI development" would be most beneficial. -Gary Eric Dalquist wrote: I think this is a great idea. One thing I'd like to see along with this work is figuring out a UI developer mode for the portal. This would likely need to be a configuration property somewhere that is set before the portal is deployed. It would need to control the following: - Use full JS/CSS files, no minification or aggregation. - Disable all JS/CSS/Image caching - Disable rendering pipeline caching - Enable logging of pipeline XSL output Not sure exactly how one configuration change would do all of that but it sure seems like a common need for uPortal deployers. -Eric Jen Bourey wrote: Hello all, I wanted to open up discussion about our options for decreasing the number of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently the portal's skins generally import some shared default resources from the new ResourceServingWebapp and from the theme's common area. These resources include the jQuery UI default theme, the Fluid Skinning System (FSS)'s standard resources, and a base uPortal-specific layout.css file. The skin then overrides and adds to these more general CSS styles, generally through including several more stylesheets. While I think the above works well from a development standpoint, we currently have 14 HTTP requests for CSS stylesheets just for the base uPortal content (i.e., this count doesn't include any stylesheets for portlets present on the page). I'd really like to get this number down as much as we can, while making sure we have a skin organization that's reasonable to work with. My current proposal is that we leave the existing structure as is, but make use of the maven yui-compressor plugin to aggregate the required files at build time. This would allow us to continue to have separate, appropriately named files, but only require the user's browser to download one or two CSS file per skin. For example, we might create aggregated files as follows: ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css One disadvantage of this approach is that it would likely be less transparent to adopters how the CSS is being assembled. I'd imagine that we'd at least want to have a README file in the skins/uportal3 directory that commented on the approach. Thoughts? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
I think this is a great idea. One thing I'd like to see along with this work is figuring out a UI developer mode for the portal. This would likely need to be a configuration property somewhere that is set before the portal is deployed. It would need to control the following: - Use full JS/CSS files, no minification or aggregation. - Disable all JS/CSS/Image caching - Disable rendering pipeline caching - Enable logging of pipeline XSL output Not sure exactly how one configuration change would do all of that but it sure seems like a common need for uPortal deployers. -Eric Jen Bourey wrote: Hello all, I wanted to open up discussion about our options for decreasing the number of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently the portal's skins generally import some shared default resources from the new ResourceServingWebapp and from the theme's common area. These resources include the jQuery UI default theme, the Fluid Skinning System (FSS)'s standard resources, and a base uPortal-specific layout.css file. The skin then overrides and adds to these more general CSS styles, generally through including several more stylesheets. While I think the above works well from a development standpoint, we currently have 14 HTTP requests for CSS stylesheets just for the base uPortal content (i.e., this count doesn't include any stylesheets for portlets present on the page). I'd really like to get this number down as much as we can, while making sure we have a skin organization that's reasonable to work with. My current proposal is that we leave the existing structure as is, but make use of the maven yui-compressor plugin to aggregate the required files at build time. This would allow us to continue to have separate, appropriately named files, but only require the user's browser to download one or two CSS file per skin. For example, we might create aggregated files as follows: ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css One disadvantage of this approach is that it would likely be less transparent to adopters how the CSS is being assembled. I'd imagine that we'd at least want to have a README file in the skins/uportal3 directory that commented on the approach. Thoughts? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu 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
Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
Hi Dustin, Yes, I think we could aggregate both the fluid and the core uPortal CSS into one file. I can't personally think of any reason they need to be separate, although I'm certainly open to input. The uPortal javascript could probably be aggregated as well. Right now javascript files are conditionally imported only if the related feature is being used, so we'd have to switch to just importing all of the javascript. However, the GZipping and minifcation we've done has dramatically cut down on the download sizes of our script files, so it probably does make sense to go ahead with the aggregation. I don't think we want to aggregate in the jQuery, jQuery UI, or Fluid javascript. We've intentionally kept those separated out on the resource server so that portlets can take advantage of browser-side caching due to consistent URLs. - Jen On Tue, Mar 24, 2009 at 10:51 PM, Dustin S. wrote: > +1 for me. Is there any reason it can't all be aggregate to one file (fluid > and core)? What about the jQuery as well? I know there are only 2 files > (core and ui)...can those be combine together as well -- for a total of 2 > requests ? > > On Tue, Mar 24, 2009 at 4:06 PM, Jen Bourey wrote: > >> Hello all, >> >> I wanted to open up discussion about our options for decreasing the number >> of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently >> the portal's skins generally import some shared default resources from the >> new ResourceServingWebapp and from the theme's common area. These resources >> include the jQuery UI default theme, the Fluid Skinning System (FSS)'s >> standard resources, and a base uPortal-specific layout.css file. The skin >> then overrides and adds to these more general CSS styles, generally through >> including several more stylesheets. >> >> While I think the above works well from a development standpoint, we >> currently have 14 HTTP requests for CSS stylesheets just for the base >> uPortal content (i.e., this count doesn't include any stylesheets for >> portlets present on the page). I'd really like to get this number down as >> much as we can, while making sure we have a skin organization that's >> reasonable to work with. >> >> My current proposal is that we leave the existing structure as is, but >> make use of the maven yui-compressor plugin to aggregate the required files >> at build time. This would allow us to continue to have separate, >> appropriately named files, but only require the user's browser to download >> one or two CSS file per skin. For example, we might create aggregated files >> as follows: >> >> >> >> >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css >> >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css >> >> >> >> >> >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css >> >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css >> >> ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css >> >> >> >> >> >> >> >> One disadvantage of this approach is that it would likely be less >> transparent to adopters how the CSS is being assembled. I'd imagine that >> we'd at least want to have a README file in the skins/uportal3 directory >> that commented on the approach. >> >> Thoughts? >> >> - Jen >> >> >> -- >> Jen Bourey >> >> -- >> >> You are currently subscribed to uportal-dev@lists.ja-sig.org as: >> icedou...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> > -- > > You are currently subscribed to uportal-dev@lists.ja-sig.org as: > jennifer.bou
Re: [uportal-dev] Stylesheet imports in uPortal 3.1.x
+1 for me. Is there any reason it can't all be aggregate to one file (fluid and core)? What about the jQuery as well? I know there are only 2 files (core and ui)...can those be combine together as well -- for a total of 2 requests ? On Tue, Mar 24, 2009 at 4:06 PM, Jen Bourey wrote: > Hello all, > > I wanted to open up discussion about our options for decreasing the number > of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently > the portal's skins generally import some shared default resources from the > new ResourceServingWebapp and from the theme's common area. These resources > include the jQuery UI default theme, the Fluid Skinning System (FSS)'s > standard resources, and a base uPortal-specific layout.css file. The skin > then overrides and adds to these more general CSS styles, generally through > including several more stylesheets. > > While I think the above works well from a development standpoint, we > currently have 14 HTTP requests for CSS stylesheets just for the base > uPortal content (i.e., this count doesn't include any stylesheets for > portlets present on the page). I'd really like to get this number down as > much as we can, while making sure we have a skin organization that's > reasonable to work with. > > My current proposal is that we leave the existing structure as is, but make > use of the maven yui-compressor plugin to aggregate the required files at > build time. This would allow us to continue to have separate, appropriately > named files, but only require the user's browser to download one or two CSS > file per skin. For example, we might create aggregated files as follows: > > > > > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css > > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css > > > > > > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css > > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css > > ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css > > > > > > > > One disadvantage of this approach is that it would likely be less > transparent to adopters how the CSS is being assembled. I'd imagine that > we'd at least want to have a README file in the skins/uportal3 directory > that commented on the approach. > > Thoughts? > > - Jen > > > -- > Jen Bourey > > -- > > You are currently subscribed to uportal-dev@lists.ja-sig.org as: > icedou...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Stylesheet imports in uPortal 3.1.x
Hello all, I wanted to open up discussion about our options for decreasing the number of HTTP requests for CSS stylesheets in the uPortal 3.1 branch. Currently the portal's skins generally import some shared default resources from the new ResourceServingWebapp and from the theme's common area. These resources include the jQuery UI default theme, the Fluid Skinning System (FSS)'s standard resources, and a base uPortal-specific layout.css file. The skin then overrides and adds to these more general CSS styles, generally through including several more stylesheets. While I think the above works well from a development standpoint, we currently have 14 HTTP requests for CSS stylesheets just for the base uPortal content (i.e., this count doesn't include any stylesheets for portlets present on the page). I'd really like to get this number down as much as we can, while making sure we have a skin organization that's reasonable to work with. My current proposal is that we leave the existing structure as is, but make use of the maven yui-compressor plugin to aggregate the required files at build time. This would allow us to continue to have separate, appropriately named files, but only require the user's browser to download one or two CSS file per skin. For example, we might create aggregated files as follows: ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css ${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css One disadvantage of this approach is that it would likely be less transparent to adopters how the CSS is being assembled. I'd imagine that we'd at least want to have a README file in the skins/uportal3 directory that commented on the approach. Thoughts? - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev