Re: [Skinning] CSS selector limit hit in IE

[Jeanne Waldman]

Hi there,
I've changed my mind and instead added this to FileSystemStyleCache. It 
is cleaner. I didn't do this in the first place
because I needed the RenderingContext, and I didn't think I had it. But 
then I noticed that I have it with the getCurrentInstance method.
   Map skinsStyleClassMap = context.getSkin().getStyleClassMap(
                               RenderingContext.getCurrentInstance());
   String disableContentCompression =
     FacesContext.getCurrentInstance().getExternalContext().
     getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
   boolean compressStyles = (skinsStyleClassMap == shortStyleClassMap) &&
                            !"true".equals(disableContentCompression);
Jeanne Waldman wrote:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I agree, only one version compressed or uncompressed should be
enough
>> >> for
>> >> a
>> >> while.
>> >>
>> >> On 1/31/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> >
>> >> >
>> >> > Simon Lessard wrote:
>> >> > > On 1/31/07, Matt Cooper <[EMAIL PROTECTED]> wrote:
>> >> > >>
>> >> > >> On 1/31/07, Jeanne Waldman <[EMAIL PROTECTED]> 
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
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>