Re: [Skinning] CSS selector limit hit in IE

[Jeanne Waldman]

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
>
>