incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanne Waldman <jeanne.wald...@oracle.com>
Subject Re: [Skinning] CSS selector limit hit in IE
Date Thu, 01 Feb 2007 22:07:34 GMT
This is what I've done:
Added a getSkin() on the StyleContext object which I think is a fine 
thing to do, since the StyleContext
gives us information we need to be able to output the stylesheet.

Then I can do this to see if I need to output the compressed 
styleclasses or the uncompressed styleclasses:
     String disableContentCompression =
       FacesContext.getCurrentInstance().getExternalContext().
       getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
     // we do not compress if it is a portlet skin
     boolean isPortletSkin =
     
CoreRenderKit.OUTPUT_MODE_PORTLET.equals(context.getSkin().getRenderKitId());

     boolean compressStyles = (!"true".equals(disableContentCompression)) &&
                                              !isPortletSkin;

Simon Lessard wrote:
> That works, true.
>
> On 2/1/07, Jeanne Waldman <jeanne.waldman@oracle.com> wrote:
>>
>>
>>
>>
>> Simon Lessard wrote:
>> > Hello Jeanne,
>> >
>> > I thought about skinning and portlet before and I came upon pretty
>> > much the
>> > same conclusion. However in my idea it was more like a predefined skin
>> > family, like "containerProvided" maybe. Then renderer would always 
>> uses
>> > uncompressed selectors and would leave <style/> tag generation to the
>> > container. Then again the container would need a way to produce the
>> > CSS, but
>> > I was not yet to that point.
>> >
>> > I guess a flag in the skin definition works as well, but it seems a 
>> bit
>> > strange to have a skin specific for a portlet environment, I would 
>> have
>> > preferred to be able to use any skin.
>> Like we have desktop skins,
>> pda skins, we can now also have portlet skins.
>> This way we don't change the skin-family.
>> We we have a SimpleDesktop skin, a SimplePda skin, we
>> now also have a SimplePortlet skin.
>> >
>> >
>> > Regards,
>> >
>> > ~ Simon
>> >
>> > On 2/1/07, Jeanne Waldman <jeanne.waldman@oracle.com> wrote:
>> >>
>> >> I just thought of a reason why I can't simply compress or uncompress
>> >> based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
>> >> portal skin we've introduced in the portal branch. We don't compress
>> our
>> >> styleclasses when using the portal skin.
>> >>
>> >> The way the skinning works now in the portal branch is:
>> >> 1. It assumes we write out both full and compressed styleclasses 
>> in our
>> >> generated css file.
>> >> 2. The Skin has a getStyleClassMap method. For all skins except 
>> portal
>> >> skins, it returns our styleclass compression map if we aren't 
>> disabling
>> >> content compression, else null; for portal skins it returns a 
>> Trinidad
>> >> styleclass to portal styleclass map.
>> >>
>> >> I can see upon writing out the css file I look to see if it is a
>> portal,
>> >> etc.
>> >> Or what do people think about a flag in the Skin that tells me if the
>> >> StyleClassMap is the compression map that we use to generate the css?
>> >> Or maybe in our css generation code we can look at the skin's
>> styleclass
>> >> map and glean information from it? Maybe see if it is the same
>> >> compression map that we are using to generate the css file and if so,
>> >> then it's ok to just write out compression, and if not, then we
>> don't???
>> >>
>> >> I'll see what I can do, but I'll want a code review to make sure 
>> it is
>> >> the best solution.
>> >>
>> >> Thanks,
>> >> Jeanne
>> >>
>> >> Matt Cooper wrote:
>> >> > That sounds like a reasonable first step to me since that would
>> reduce
>> >> > the
>> >> > size the most.
>> >> >
>> >> > Thanks
>> >> >
>> >> > On 1/31/07, Simon Lessard <simon.lessard.3@gmail.com> wrote:
>> >> >>
>> >> >> I agree, only one version compressed or uncompressed should be
>> enough
>> >> >> for
>> >> >> a
>> >> >> while.
>> >> >>
>> >> >> On 1/31/07, Jeanne Waldman <jeanne.waldman@oracle.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Simon Lessard wrote:
>> >> >> > > On 1/31/07, Matt Cooper <matt.faces@gmail.com>
wrote:
>> >> >> > >>
>> >> >> > >> On 1/31/07, Jeanne Waldman <jeanne.waldman@oracle.com>
wrote:
>> >> >> > >> >
>> >> >> > >> > > As Adam suggest, we could do some runtime
evaluation 
>> during
>> >> CSS
>> >> >> > >> > > generation
>> >> >> > >> > > and have many selector uses the same compressed
selector,
>> >> this
>> >> >> > would
>> >> >> > >> be
>> >> >> > >> > a
>> >> >> > >> > > 50% gain or so.
>> >> >> > >> > I can do this, too, if we feel we have to. The
logic flow
>> will
>> >> >> have
>> >> >> > to
>> >> >> > >> > change, of course.
>> >> >> > >> > Right now we build the shortened style class
map, then we
>> >> >> generate
>> >> >> > the
>> >> >> > >> > css file.
>> >> >> > >> > I'd have to either change the shortened style
class map 
>> as I
>> >> >> merge
>> >> >> > >> > styles, or create it a bit later.
>> >> >> > >> > It's no big deal, just more overhead when we
create the 
>> file.
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> Maybe this goes without saying but we have to be
careful when
>> >> doing
>> >> >> > this
>> >> >> > >> so
>> >> >> > >> that we only use the same selector when the containment
>> >> definitions
>> >> >> are
>> >> >> > >> also
>> >> >> > >> the same.
>> >> >> > >>
>> >> >> > >> If we just have:
>> >> >> > >>
>> >> >> > >> .Foo,
>> >> >> > >> .Bar {
>> >> >> > >>   color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> then this could be compressed down to:
>> >> >> > >>
>> >> >> > >> .x1 {
>> >> >> > >>   color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> But if we have:
>> >> >> > >>
>> >> >> > >> .Foo,
>> >> >> > >> .Bar {
>> >> >> > >>   color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .Foo .Joe {
>> >> >> > >>   color: green;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .Bar .Joe {
>> >> >> > >>   color: blue;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> then we cannot use the same compressed name for Foo
and Bar,
>> >> we'd
>> >> >> > >> compress
>> >> >> > >> to:
>> >> >> > >>
>> >> >> > >> .x1,
>> >> >> > >> .x2 {
>> >> >> > >>   color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .x1 .x3 {
>> >> >> > >>   color: green;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .x2 .x3 {
>> >> >> > >>   color: blue;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> If we had:
>> >> >> > >>
>> >> >> > >> .Foo,
>> >> >> > >> .Bar {
>> >> >> > >>   color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .Foo .Joe,
>> >> >> > >> .Bar .Joe {
>> >> >> > >>   color: green;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> then we could compress down to:
>> >> >> > >>
>> >> >> > >> .x1 {
>> >> >> > >>   color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .x1 .x2 {
>> >> >> > >>   color: green;
>> >> >> > >> }
>> >> >> > >
>> >> >> > >
>> >> >> > > Yeah that would require quite a lot of evaluation after
>> >> parsing, if
>> >> >> > > that's
>> >> >> > > done maybe we should consider generating the CSS files
at app.
>> >> >> startup
>> >> >> > > rather than at first request because that kind of processing
>> >> would
>> >> >> > > most like
>> >> >> > > be O(n!) or O(x^n).
>> >> >> > I was thinking if a style is used anywhere else, period, we

>> do not
>> >> >> merge
>> >> >> > that with another style. That is less processing, at least.
>> >> >> > Personally, I think doing the only-generated-compressed-styles
>> >> >> solution
>> >> >> > or (only-non-uncompressed) is enough to solve this problem
for a
>> >> >> while.
>> >> >> > I think this merging solution is lower priority, and more
of a
>> >> >> > nice-to-have. What does everyone else think?
>> >> >> > If there is another reason to do this, like performance, and
we
>> >> >> know the
>> >> >> > impact, then that's another thing, but I'd like
>> >> >> > to focus on this issue and the solution right now -- especially
>> >> since
>> >> >> > we've hit this limit.
>> >> >> > - Jeanne
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>


Mime
View raw message