One more thing: what I really like about having
both the compressed and uncompressed style
classes is that when I see a class in the source,
I can figure out what the real .css style is.
Is there any way we could - at least in debug mode -
leave behind a .css comment with the original
class name?
-- Adam
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
>
>
