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:
<aggregations>
<!-- Create the shared Fluid Skinning System stylesheet -->
<aggregation>
<output>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css</output>
<includes>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css</include>
</includes>
</aggregation>
<!-- Create the uPortal3 skin stylesheet -->
<aggregation>
<output>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css</output>
<includes>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css</include>
</includes>
</aggregation>
<!-- More skins here . . . -->
</aggregations>
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 [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
