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 19:46:27 GMT
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