Hello Jeanne,
On 1/31/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
Hi Simon, Adam,
Simon Lessard wrote:
> Wow, another IE nasticity...
>
> 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.
>
> As for not generating either compressed or uncompressed version
> depending on
> a context parameter value, I think it's a good idea as well.
Me, too. We could tie in debug mode to automatically not compress...
something I would
like to do anyway, because right now we have this 'internal' key to
disable compression,
although it is such a useful feature for people who are creating skins.
In the case where we don't compress, then we can't combined selectors.
Well, technically we can, but I'm sure you all already know that would
be too strange to do to
the skinning person.
>
> I would also encourage a major reduction of private selectors usage as
in
> real world you always have to overload them anyway.
What do you mean?
Mainly get rid of .OraLink classes and such, or at lease rename them and no
longer define them as private. In my last project I had to redefine
selectors like button.OraLink:active to prevent some really strange behavior
when clicking on a button. There's only about 10 of those selectors but if a
skinners has to override all combinations around those selectors (OraLink is
present in 6 selectors for my last skin mainly to make different behavior
between buttons and links) then the total amount of selectors present in the
final CSS might get higher than that.
> Finally, does that restriction applies to IE 7 as well?
yes, it does. I primarily use IE7 now at work. I did try this on my IE6
on my home machine, and it occurs there, too.
>
>
> Regards,
>
> ~ Simon
>
> On 1/31/07, Adam Winer <[EMAIL PROTECTED]> wrote:
>>
>> Having magic insider knowledge of the scenario where this
>> problem occurs :), one of the major causes of it is
>> using different keys for the same CSS rules. For example,
>> we use af|selectManyShuttle and af|selectOrderShuttle,
>> but they're basically the same thing. Merging the
>> compressed versions of those keys would be a major
>> win.
>>
>> This is tricky for classes that are used in complex
>> selectors, but for classes that only show up in simple
>> selectors, we could potentially detect the match,
>>
>> -- Adam
>>
>>
>>
>>
>> On 1/30/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > Well, it turns out that IE has a limit to the size of a CSS file.
It's
>> > not the actual size of the file, but rather it is the
>> > # of CSS selectors. I did a test and found out that the limit is 4095
>> > CSS selectors.
>> > Firefox doesn't appear to have a limit.
>> >
>> > As you may know, the CSS file we generate contains both compressed
and
>> > uncompressed styles, like this:
>> > .af_inputText_content, .x01 {background-color: blue}
>> >
>> > Our renderers render a shortened styleclass, unless
>> > the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml,
>> then it
>> > renders the long styleclass.
>> > <input class="x01...>
>> >
>> > Ok, that's the background.
>> >
>> > *The problem* is that because we have a lot of custom components that
>> > we've built on top of Trinidad, and our customers
>> > have built custom components, etc, and these all have skinning,
>> > we have bumped up against the 4095 selector limit in IE. All
selectors
>> > after the 4095th one are ignored.
>> >
>> > *A quick fix*, and probably a good one for a long time, is to
>> render the
>> > styles in compressed mode when compression is on,
>> > or in uncompressed mode when compression if off. That will reduce our
>> > style selectors by 1/2, and will help performance to boot. :)
>> > I can also add a warning if we go past 4095 selectors for IE.
>> >
>> > Another solution is to break up the file into multiple files when
I've
>> > reached the limit in one file, and include
>> > all the css files into the rendered page. I can do this in addition
to
>> > the quick fix when I have more time.
>> > Or, I'll be forced to do this solution if the above solution can't be
>> > done for some reason.
>> >
>> > Anyway, let me know what you think about the fixes. I'll start
>> > investigating it to make sure it is possible and won't break
>> > anything. My main concern was if people were using our public style
>> > classes, like styleClass=".AFInstructionText", but
>> > it looks like we compress these when we are in compressed mode.
>> >
>> > Let me know if there are other things I should check.
>> >
>> > Thanks,
>> > Jeanne
>> >
>> >
>>
>
